Webhooks

Delieta ruft Ihren Server nicht auf, wenn eine Bestellung den Status ändert. Das veröffentlichte OpenAPI hat keine Webhook-Operation für Partner. Es gibt ein signiertes Signal an einen Shop, der auf @delieta/shop-runtime läuft, und eine Meldung in der Gegenrichtung.

Aktualisierungssignal: POST /api/revalidate

Ändert der Inhaber das Menü, die Shop-Einstellungen oder den Raumplan, ruft Delieta POST {Adresse-des-Shop-Deployments}/api/revalidate auf. Der Shop lässt seinen Cache verfallen, und die nächste Anfrage holt frische Daten. Der Body ist {"reason":"menu"|"shop-config"|"floor-plan","at":"…ISO…"}.

POST /api/revalidate
x-delieta-signature: 9f2c…
Content-Type: application/json

{"reason":"menu","at":"2026-11-05T12:00:00.000Z"}

Die Signatur ist der Header x-delieta-signature: ein Hex-HMAC-SHA256 über den rohen Body, mit dem Aktualisierungsgeheimnis dieses Shops als Schlüssel (DELIETA_REVALIDATE_SECRET auf Shop-Seite). Der Handler aus @delieta/shop-runtime prüft die Signatur in konstanter Zeit. Falsche Signatur → 401, kein Geheimnis im Shop → 503, schlechter Body → 400, Erfolg → 204. Delieta wartet bis zu 5 Sekunden auf die Antwort und ignoriert einen Fehler: Eine Aktualisierung ist eine Annehmlichkeit, keine Transaktion. Der Shop liest Delieta ohnehin ungecacht, der schlimmste Fall ist also eine Verzögerung.

Diese Adresse wird durch die Signatur bedient, nicht durch einen API-Schlüssel. Es steckt kein veröffentlichbarer Schlüssel und kein Partnergeheimnis darin.

Shop-Heartbeat

In der Gegenrichtung meldet ein ausgerollter Shop, mit welcher Runtime er gebaut wurde: POST /api/v1/shop-heartbeat. delieta-shop-assert sendet das nach next build, einmal pro Build. Delieta speichert Runtime- und Vertragsversion in der Shop-Zeile und sieht so, welche Shops aktualisiert werden müssen. Immer 204; es gibt nichts zu behandeln.

Bestellstatus: per GET lesen

Nach POST /api/v1/orders kann eine Bestellung pending_acceptance sein. Sie verlässt diesen Zustand, wenn jemand in der Küche annimmt oder ablehnt oder wenn das Timeout abläuft. Nichts davon verursacht Ihr Backend, also lesen Sie: GET /api/v1/orders/{id} mit einem geheimen Schlüssel oder GET /api/v1/orders/{id}/status über den Kurzcode, auch mit einem veröffentlichbaren Schlüssel. Das Abfragen zählt zum Leselimit und verbraucht nicht das Limit zum Anlegen von Bestellungen.

404 not_found heißt „keine solche Bestellung für diesen Schlüssel“. Eine Bestellung einer anderen Firma antwortet gleich.

Was es nicht gibt

Es gibt keinen signierten POST zu einer Statusänderung an https://ihr-shop/hooks/orders. Es gibt kein Partner-Webhook-Geheimnis und keine Wiederholungen auf unserer Seite. Die Zahlung Ihrer Firma für Delieta läuft über Stripe und ist Sache des Panels, nicht der Partner-API. Kommen Partner-Webhooks, erscheinen sie als neue Operation in GET /api/v1/openapi und auf der Seite Partner-API.