Für Entwickler

Ein Entwickler verdrahtet Shop oder Kasse mit Delieta über Partner-API v1. Der Mandant kommt aus dem Schlüssel. Die Anfrage sendet nie companyId oder tenantSlug. Geld sind ganze Groszy; die einzige v1-Währung ist PLN.

Schlüssel ausstellen

Im Panel: Einstellungen → Integrationen. Der Klartextschlüssel wird einmal gezeigt. Format: dlt_live_… oder dlt_test_….

• Ein geheimer Schlüssel (orders:write, eta:quote) lebt auf dem Server. Nie im Browser, nie als NEXT_PUBLIC_.
• Ein veröffentlichbarer Schlüssel hat nur catalog:read. Er darf in einen statischen Shop, weil er nichts Privates liest.

Ein Testschlüssel liest denselben Katalog wie live, legt aber keine Bestellung an (test_key_readonly). POST /api/v1/orders braucht dlt_live_….

Menü lesen, dann Quote, dann Bestellung

Drei Aufrufe in dieser Reihenfolge schließen die Shop-Schleife:

1. GET /api/v1/menu — Katalog der Schlüsselfirma. Scope catalog:read.
2. POST /api/v1/quotes — Minutenfenster zur Adresse. Scope eta:quote. Immer Spanne, nie Garantie.
3. POST /api/v1/orders — Ticket in die Küche. Scope orders:write. Header Idempotency-Key ist Pflicht.

Die 201-Antwort trägt order.trackingUrl. Das ist der Link für den Kunden — die /o/…-Seite. Erfinde keine zweite Tracking-URL.

Lesen, ob die Küche angenommen hat

Wenn die Firma Annahme verlangt, startet ein neues Ticket in pending_acceptance. Den Zustand ändert ein Mensch oder ein Zeitlimit — nicht dein Backend. Deshalb gibt es GET /api/v1/orders/{id}: es verbraucht das Lese-Budget, nicht das Anlege-Budget.

Shop-Vertrag, kein Webhook

Ein statischer Shop (Next-Export) bäckt das Menü beim Build und hält einen Warenkorb { itemId, quantity }. Das ist der Shop-Vertrag. Delieta hostet diesen Shop nicht.

Es gibt keine Bestellstatus-Webhooks. Poll GET.

Vollständige Referenz, passend zu GET /api/v1/openapi: Partner-API.