Alyte ist die Vertrauensschicht, die ein Agent durchläuft, bevor er kaufen kann. Sie integrieren gegen eine gehostete API, keine PSP-Migration, kein Geld berührt uns. Derselbe Anfragepfad führt jede Prüfung serverseitig aus, sodass ein Agent sein Mandat nicht überschreiten kann, egal was in seinem Prompt steht.
Ein Anfragepfad. Jeder Schritt ein normaler REST-Aufruf mit einem Bearer-Token.
# 1 · discover, Inventar für die Veranstaltung eines Händlers GET /v1/merchants/mrc_42/events Authorization: Bearer $TOKEN # 2 · quote, Preis fixieren (liefert eine quote_id) POST /v1/quotes { "tier_id": "tier_ga", "qty": 2 } # 3 · reserve, eine atomare, überverkaufssichere Reservierung POST /v1/holds { "quote_id": "qt_9f3" } Idempotency-Key: 3b1c… # 4 · confirm, der eigene Zahlungsdienstleister des Händlers rechnet die Belastung ab POST /v1/holds/hd_7c/confirm { "instrument": "inst_tok_…" }
Der wichtige Teil: Das Ausgabelimit wird serverseitig aus dem Agenten-Datensatz aufgelöst, niemals aus dem Token gelesen.
Ein Header. Scopes steuern jede Route.
Limit, Scope, Eigentümerschaft und Überverkaufsprüfungen laufen alle im Orchestrator. Das Modell kann sein eigenes Ausgabelimit nicht anheben; diese Berechtigung wird serverseitig aus dem Agenten-Datensatz aufgelöst.
REST, MCP und A2A laufen alle durch denselben Orchestrator, dieselbe Auth, Scopes, Mandantentrennung, Idempotenz und Prüfungen.
/v1/payments. Scope-gesichert, OpenAPI-beschrieben.agent:run Scope.Das Limit liegt auf dem Server, nicht im Prompt, das Modell kann es nicht anheben. Die Ausgabeberechtigung wird serverseitig aus dem Agenten-Datensatz aufgelöst. Das Geld wird vom Händler zum Zahlungsdienstleister des Händlers abgerechnet; Alyte bewegt nur Instruktionen, niemals Gelder.
Welche Oberfläche ein Agent auch nutzt, der Kauf durchläuft denselben serverseitigen Prüflauf, bekannter Agent, innerhalb des Mandats, Platz frei, Preis gesperrt, bevor sich Geld bewegt.
Ehrlich zur Reife: Oberflächen und Richtlinienprüfungen sind live und getestet. Schema-Attestierungsadapter (TAP, Visa Intelligent Commerce) sind verdrahtet und in ihrer Struktur durchgesetzt, aber die Live-Signaturprüfung und der Produktions-Agent sind Roadmap. Der Sandbox-Agent läuft als deterministisches Skript. Wir kennzeichnen real, mock oder stub ehrlich.
Wird atomar beansprucht, bevor irgendeine Belastung erfolgt, pro Mandant. Zwei gleichzeitige Anfragen mit demselben Schlüssel autorisieren niemals beide. Beliebig oft wiederholbar.
Typisierte Codes, stabile Form. Ein mehrdeutiges PSP-Ergebnis hält zur Klärung an, niemals eine stille Ablehnung, die Sie in eine Doppelbelastung hinein wiederholen würden.
Die vier Aufrufe oben sind die Kaufseite. Damit die Tickets eines Händlers für Agenten verfügbar werden, werden zwei Dinge verbunden, beide heute real, über die Händlerkonsole.
Registrieren Sie Ihre PSP-Schienen und speichern Sie Zugangsdaten als undurchsichtige Referenz, niemals das Geheimnis, aufgelöst zum Zeitpunkt der Belastung. Belastungen rechnen auf Ihr eigenes PSP-Konto ab. Alyte ist niemals Zahlungsempfänger.
Erstellen Sie Veranstaltungen und Tarifstufen, legen Sie Preis und Verfügbarkeit fest. Das veränderliche Inventar, gegen das Angebote den Preis fixieren und das Reservierungen atomar verringern, die Quelle der überverkaufssicheren Garantie.
Ehrlich zur Angebots-API: PSP-Verknüpfung und Katalogverwaltung sind heute live in der Händlerkonsole, einer Admin-Oberfläche, die Sie selbst bedienen. Eine Server-zu-Server-Inventarsynchronisierungs-API, für Händler mit eigenem Ticketingsystem, die Inventar programmatisch übertragen möchten, sowie ausgehende Webhooks (payment.succeeded, hold.expired), sind Roadmap, nicht ausgeliefert. Wenn Sie eine eigene Inventarquelle haben, ist dieser Adapter das, was wir als Nächstes mit Design-Partnern bauen.
Der Schnellstart, die maschinenlesbare OpenAPI-Spezifikation, das Vorschau-SDK sowie die vollständige Endpunkt- und Fehlerreferenz kommen auf eine gehostete Doku-Seite. Sprechen Sie in der Zwischenzeit mit uns, wir führen Sie direkt durch die API.