Test-Betrieb

Was ein Test-Betrieb ist#

Ein Test-Betrieb ist ein Restaurant auf Flavoso, das es nur für die Schnittstelle gibt. Er kostet nichts, braucht kein Abo und ist von Haus aus rund um die Uhr geöffnet. Für die Schnittstelle gilt er als Tarif Pro: alle Routen stehen offen, auch Reservierungen.

Jedes Konto hat höchstens einen Test-Betrieb, und alle deine Apps teilen ihn. Er bringt eine Beispiel-Speisekarte mit Kategorien, Gerichten und einer Optionsgruppe mit, dazu Tische. Du führst ihn in der Konsole unter Test-Betrieb, in fünf Reitern: Betrieb, Bestellungen, Reservierungen, Speisekarte und Ereignisse.

Anlegen und benutzen#

1. 1

   Anlegen

   „Test-Betrieb anlegen“: ein Klick, und er steht. Im Einrichtungs-Assistenten ist das der zweite Schritt.

   Konsole › Test-Betrieb

2. 2

   App verbinden

   Mit einem Test-Token oder über den OAuth-Ablauf, mit dem Test-Betrieb als Auswahl. Erst dann entstehen Ereignisse: ohne verbundene App mit dem passenden Recht hört niemand zu.

3. 3

   Ausprobieren

   Als Gast bestellen und reservieren, als Betrieb antworten: weiterschalten, pausieren, Zeiten ändern, Gerichte ausverkauft melden. Jede Änderung geht als Ereignis an deine verbundenen Apps.

   Konsole › Test-Betrieb

Wie ein echter Betrieb#

Für deine App verhält sich der Test-Betrieb wie ein echter Betrieb: dieselben Routen, dieselben Ereignisse, dieselben Fehler. Testbestellungen und Testreservierungen nehmen denselben Weg wie die eines Gastes, und wer in der Konsole eine Bestellung weiterschaltet, tut dasselbe wie die Küche. Jede Änderung kommt als Ereignis bei deiner App an, per Webhook oder über GET /events. Drei Dinge sind anders:

• livemode ist false, in GET /me und in jedem Ereignis. Ein Test-Betrieb kann nie live gehen.
• Online-Zahlungen sind simuliert: eine Testbestellung, die du als online bezahlt anlegst, löst order.created und gleich danach order.paid aus, ohne Zahlungsanbieter und ohne Geld.
• Aus image_url behält er höchstens 50 Bilder. Darüber lädt PUT /menu keine weiteren und warnt mit images_capped; Zurücksetzen löscht sie.

Die Werkzeuge#

Die Reiter des Test-Betriebs in der Konsole übernehmen, was sonst Gäste, Küche, Empfang und Dashboard tun. Sie aktualisieren sich von selbst, sobald sich im Test-Betrieb etwas ändert, auch wenn deine App die Änderung über die Schnittstelle macht.

Mehr zu den Werkzeugen deiner App unter Werkzeuge.

Speisekarte und Abgleich#

Der Reiter Speisekarte zeigt die Karte des Test-Betriebs genau so, wie GET /menu sie einer verbundenen App zurückgibt, mit deren Kennungen (external_id). Markiert ist, was keine Kennung dieser App trägt: ein Abgleich fasst es nie an.

1. 1

   Kennungen vergeben

   Trägt für jedes Objekt ohne Kennung einen Vorschlag als external_id deiner App ein, etwa demo-pizza-margherita. Gerichte, Preise und Optionen bleiben, wie sie sind, und es entsteht kein Ereignis.

   Konsole › Test-Betrieb › Speisekarte

2. 2

   Beispiel-Abgleich

   Ein fertiger Rumpf für PUT /menu mit der Karte, wie sie gerade ist, mit merge oder replace und immer mit dry_run. Zum Kopieren oder direkt im API-Explorer.

   Konsole › Test-Betrieb › Speisekarte

3. 3

   Abgleichen

   Deine App schickt ihre Karte. Mit vergebenen Kennungen ändert der Abgleich nur, was sich unterscheidet; ein Probelauf zeigt es vorher.

4. 4

   Nachsehen

   „Letzte Abgleiche“ zeigt jeden PUT /menu deiner Apps mit Modus und Zusammenfassung, daneben die Ereignisse menu.synced. Die entstehen nur, wenn ein Abgleich wirklich etwas ändert.

   Konsole › Test-Betrieb › Speisekarte

„Karte zurücksetzen“ leert die Karte oder legt die Beispielkarte neu an; Bestellungen, Zeiten und Verbindungen bleiben, die über image_url geladenen Bilder gehen mit. Jede gelöschte Kategorie, jedes Gericht und jede Gruppe meldet ein menu.*.deleted (Optionen gehen mit ihrer Gruppe), jedes neue Objekt ein menu.*.created, auch jede Option. Die Konsole nennt die Zahl vorher. Wie der Abgleich rechnet, steht unter Speisekarte abgleichen.

Ereignisse verfolgen#

Der Reiter Ereignisse zeigt die letzten 30 Ereignisse des Test-Betriebs. Je verbundene App steht daneben, was ihr Webhook damit gemacht hat (zugestellt, wartet auf den nächsten Versuch, fehlgeschlagen oder übersprungen, mit Grund) und ob sie es über GET /events schon abgeholt hat.

• Umschlag: eine Zeile klappt auf und zeigt das Ereignis genau so, wie die gewählte App es bekommt.
• Erneut senden: eine Zustellung noch einmal schicken, mit derselben Ereignis-Kennung.
• An Webhook senden: ein Ereignis ohne Zustellung an den Webhook einer App schicken, etwa eins von vor der Einrichtung des Webhooks oder eine Art, die er nicht abonniert hat.
• Ab hier abholen: den Aufruf GET /events kopieren, dessen Antwort mit genau diesem Ereignis beginnt.

Gesendet wird höchstens zehnmal je Minute und App, zusammen mit „Erneut senden“ und „Test-Ereignis senden“ unter Webhooks. Testereignisse und ping stehen nie in GET /events; der Reiter sagt das an der Stelle dazu.

Zurücksetzen#

„Test-Betrieb zurücksetzen“ löscht alle Bestellungen und Reservierungen, legt die Beispielkarte neu an, beendet eine Pause, löscht Sondertage und stellt Öffnungszeiten, Bestellarten, Vorlauf, Vorbestellung, Mindestbestellwert, Trinkgeld, Lieferzone und Reservierungen wie beim Anlegen ein. Die über image_url geladenen Bilder werden gelöscht. Tische und Verbindungen bleiben.

• Die Speisekarte meldet dieselben Ereignisse wie bei „Karte zurücksetzen“: jedes gelöschte Objekt mit menu.*.deleted, jedes neue mit menu.*.created. Eine Kasse, die die Karte spiegelt, sieht so, dass die Gerichte mit ihren Kennungen weg sind.
• Ändern sich Zeiten, Sondertage, Vorlauf, Bestellarten, Vorbestellung oder Mindestbestellwert, kommt store.updated, bei einer laufenden Pause store.resumed.
• Gelöschte Bestellungen und Reservierungen melden nichts.

Zurücksetzen geht höchstens fünfmal in zehn Minuten, „Karte zurücksetzen“ mitgezählt.

Test und echt auseinanderhalten#

livemode steht in GET /me und in jedem Ereignis. Im Test-Betrieb ist es false, in jedem echten Betrieb true. Prüf es an der Stelle, an der deine App etwas Echtes tut: eine Testbestellung gehört in keine echte Kasse.

// Test and live share one API, one address and one token format. livemode tells them apart.
const me = await fetch("https://api.flavoso.com/v1/me", {
  headers: { Authorization: `Bearer ${accessToken}` },
}).then((r) => r.json());
if (!me.livemode) console.log(`Connected to the test restaurant "${me.tenant.name}"`);

// In the webhook handler: never book a test order into a real till
export function handleEvent(event) {
  if (!event.livemode) return handleTestEvent(event);
  return handleLiveEvent(event);
}

Mit einem echten Betrieb testen#

Schon vor der Freigabe verbindet sich deine App auch mit Betrieben, in denen du selbst Inhaber bist. Das ist für den letzten Test mit echter Karte gedacht.