Für Entwickler

Agenten-Checkout in vier Aufrufen.

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.

Die Integration

Discover, Quote, Reserve, Confirm.

Ein Anfragepfad. Jeder Schritt ein normaler REST-Aufruf mit einem Bearer-Token.

checkout.sh Sandbox · keine Karte nötig
# 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_…" }
discover quote reserve confirm Das Geld wird vom Händler zum Zahlungsdienstleister des Händlers abgerechnet. Alyte bewegt nur Instruktionen, niemals Gelder.
Auth

Ein Bearer-Token, mit Scope und Mandantenbindung.

Der wichtige Teil: Das Ausgabelimit wird serverseitig aus dem Agenten-Datensatz aufgelöst, niemals aus dem Token gelesen.

Was Sie senden

Ein Header. Scopes steuern jede Route.

Authorization: Bearer <jwt>
scope: catalog:read payments:write agent:run
Was Alyte durchsetzt

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.

cap → serverseitig, aus dem Agenten-Datensatz
Oberflächen

Drei Wege hinein. Ein Regelwerk.

REST, MCP und A2A laufen alle durch denselben Orchestrator, dieselbe Auth, Scopes, Mandantentrennung, Idempotenz und Prüfungen.

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.

Garantien für den Geldpfad

Idempotent per Vertrag. Typisiert bei Fehlern.

Idempotency-Key

Wird atomar beansprucht, bevor irgendeine Belastung erfolgt, pro Mandant. Zwei gleichzeitige Anfragen mit demselben Schlüssel autorisieren niemals beide. Beliebig oft wiederholbar.

Idempotency-Key: 3b1c-…-9f
Stabile Fehlertaxonomie

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.

{ "error": { "code": "validation_error", "message": … } }
Angebotsseite

Bringen Sie Ihr Inventar und Ihren Zahlungsdienstleister mit.

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.

real · Konsole
PSP-Verknüpfung

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.

credential_ref → aufgelöst bei Belastung
real · Konsole
Katalog

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.

events · tiers · availableCount

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.

Die vollständige Dokumentation lesen.

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.

Sprechen Sie mit uns Sandbox ausprobieren