Support & Datenvollständigkeit

Der Vorbehalt zur Vollständigkeit, klar gesagt

Die Partner-API stellt Datensätze bereit, die erfasst wurden, nachdem die Funktion für dieses Restaurant freigeschaltet wurde — Lieferungen und Collections gleichermaßen. Sie beansprucht nicht, die vollständige Historie eines Restaurants zu halten, und sie wird auch keine nachtragen.

Das wiegt schwerer, als es klingt:

• Ein leeres Ergebnis ist kein Beleg dafür, dass nichts passiert ist. Es kann heißen, dass das Restaurant noch nicht freigeschaltet war oder dass ein Gerät noch nicht hochgeladen hat.
• Eine Anzahl aus dieser API ist keine Compliance-Kennzahl. Drucken Sie keine auf einen Bericht, der sich wie ein Audit liest.
• Wenn Sie das Freischaltdatum eines Restaurants wissen müssen, fragen Sie uns oder den Kunden. Es wird derzeit nicht über die API bereitgestellt — wenn Sie es als Feld brauchen, sagen Sie es uns, und es wird eines.

Collections sagen das in ihrer eigenen Antwort: stateKind ist received-shadow-snapshot, also der Zustand, den diese API empfangen hat, und nicht der Zustand, den die App des Restaurants hält. Beide stimmen im Normalfall überein und laufen genau dann auseinander, wenn ein Gerät noch nicht hochgeladen hat.

Sobald ein Restaurant freigeschaltet ist, treffen die Datensätze zuverlässig ein, auch die, die erfasst wurden, während ein Gerät offline war: Sie werden hochgeladen, wenn es sich wieder verbindet, und deshalb sollten sich inkrementelle Abfragen überlappen und deshalb trägt jeder Datensatz sowohl capturedAt als auch receivedAt.

Versionierung

Jeder Pfad trägt das Präfix /v1. Innerhalb dieser Version werden wir:

• Felder zu einer Antwort hinzufügen und
• Endpunkte und optionale Parameter hinzufügen.

Beides ist abwärtskompatibel, und keines davon wird als Breaking Change angekündigt — parsen Sie also nachsichtig: Ignorieren Sie Felder, die Sie nicht kennen, statt an ihnen zu scheitern.

Wir werden innerhalb von /v1 kein Feld entfernen oder umtypisieren, die Bedeutung eines bestehenden nicht ändern und keinen optionalen Parameter zur Pflicht machen. Alles, was das nötig hätte, käme als /v2, neben /v1, mit Vorankündigung.

Das OpenAPI-Dokument wird aus dem laufenden Dienst erzeugt und ist damit die maßgebliche Beschreibung dessen, was gerade ausgerollt ist. Wenn diese Dokumentation und jenes Dokument voneinander abweichen, hat das Dokument recht und wir haben eine Seite zu korrigieren — bitte sagen Sie es uns.

Health-Checks

Zwei öffentliche Endpunkte, ohne Authentifizierung:

/health/ready ist der, den Sie abfragen sollten, wenn Sie uns überwachen. Erfolgreiche Prüfungen werden nicht ins Audit-Log geschrieben, ein Monitor erzeugt also kein Rauschen.

Hilfe bekommen

Schreiben Sie an contact@backresto.com. Was eine Antwort schnell macht:

• die requestId aus dem Problemdokument oder die X-Request-ID, die Sie gesendet haben;
• das öffentliche Präfix Ihres Schlüssels — die brp_…-Hälfte vor dem Punkt, niemals das Secret;
• die Umgebung, den Endpunkt und ungefähr wann.

Senden Sie uns niemals das Secret eines Schlüssels — das öffentliche Präfix benennt ihn eindeutig. Ist ein Secret irgendwohin geraten, wo es nicht hingehört, schreiben Sie das in die Betreffzeile und senden Sie das Präfix: Der Widerruf wirkt sofort, und er ist die ganze Abhilfe. Der Rest des Schlüssel-Lebenszyklus steht unter Einen Schlüssel erhalten.

Mehr verlangen

Was es hier gibt, gibt es, weil jemand danach gefragt hat. Gar- und Kühltemperaturen, Reinigungspläne, Etiketten und ein gehosteter MCP-Endpunkt standen vor ein paar Monaten alle auf dieser Liste; sie sind heute Collections und ein Endpunkt.

Was noch darauf steht: Webhooks statt Abfragen, ein inkrementeller Cursor auf Collections, ein Freischaltdatum am Restaurant und eine OAuth-Anmeldung für die MCP-Clients, die keinen Schlüssel nehmen. Welches als Nächstes kommt, entscheidet, wer fragt. Also fragen Sie.