Test restaurant

What a test restaurant is#

A test restaurant is a restaurant on Flavoso that exists only for the API. It costs nothing, needs no subscription and is open around the clock out of the box. For the API it counts as the Pro plan: every route is open, reservations included.

Every account has at most one test restaurant, and all your apps share it. It comes with a sample menu of categories, dishes and an option group, plus tables. You run it from the console, under Test restaurant, in five tabs: Restaurant, Orders, Reservations, Menu and Events.

Create and use#

1. 1

   Create

   “Create test restaurant”: one click, and it is there. In the setup assistant this is the second step.

   Console › Test restaurant

2. 2

   Connect your app

   With a test token or through the OAuth flow, choosing the test restaurant. Only then are events created: without a connected app holding the matching scope, nobody is listening.

3. 3

   Try it out

   Order and book as a guest, respond as the restaurant: move orders along, pause, change the hours, mark dishes as sold out. Every change reaches your connected apps as an event.

   Console › Test restaurant

Like a real restaurant#

To your app, the test restaurant behaves like a real one: the same routes, the same events, the same errors. Test orders and test reservations take the same path as a guest's, and moving an order along in the console does exactly what the kitchen does. Every change reaches your app as an event, by webhook or through GET /events. Three things are different:

• livemode is false, in GET /me and in every event. A test restaurant can never go live.
• Online payments are simulated: a test order you create as paid online triggers order.created and straight after it order.paid, with no payment provider and no money involved.
• It keeps at most 50 images from image_url. Beyond that, PUT /menu downloads no more and warns with images_capped; resetting deletes them.

The tools#

The test restaurant's tabs in the console do what guests, the kitchen, the front desk and the dashboard would otherwise do. They refresh by themselves as soon as something changes in the test restaurant, even when your app makes the change through the API.

More about your app's tools under Tools.

Menu and sync#

The Menu tab shows the test restaurant's menu exactly as GET /menu returns it to a connected app, with that app's ids (external_id). Whatever carries no id of that app is marked: a sync never touches it.

1. 1

   Assign ids

   Stores a suggestion as your app's external_id for every object without one, such as demo-pizza-margherita. Dishes, prices and options stay as they are, and no event is created.

   Console › Test restaurant › Menu

2. 2

   Example sync

   A ready-made body for PUT /menu with the menu as it is right now, with merge or replace and always with dry_run. Copy it or open it straight in the API explorer.

   Console › Test restaurant › Menu

3. 3

   Sync

   Your app sends its menu. With ids assigned, the sync only changes what differs; a dry run shows it beforehand.

4. 4

   Check

   “Recent syncs” shows every PUT /menu of your apps with mode and summary, next to the menu.synced events. Those are only created when a sync actually changes something.

   Console › Test restaurant › Menu

“Reset menu” empties the menu or recreates the sample menu; orders, hours and connections stay, while images downloaded from image_url are removed with it. Every deleted category, dish and group reports a menu.*.deleted (options go with their group), every new object a menu.*.created, including every option. The console tells you the number beforehand. How the sync works is described under Menu sync.

Following events#

The Events tab shows the latest 30 events of the test restaurant. For every connected app it shows what its webhook did with them (delivered, waiting for the next attempt, failed or skipped, with the reason) and whether the app has fetched them through GET /events.

• Envelope: a row expands and shows the event exactly as the chosen app receives it.
• Resend: send a delivery once more, with the same event id.
• Send to webhook: send an event without a delivery to an app's webhook, for example one from before the webhook was set up or of a type it has not subscribed to.
• Fetch from here: copy the GET /events call whose response starts with exactly this event.

Sending is limited to ten per minute and app, together with “Resend” and “Send a test event” under Webhooks. Test events and ping never appear in GET /events; the tab says so where it applies.

Reset#

“Reset test restaurant” deletes all orders and reservations, recreates the sample menu, ends a pause, removes special days and sets opening hours, order types, lead times, pre-orders, minimum order, tipping, delivery zone and reservations as they were at creation. Images downloaded from image_url are deleted. Tables and connections stay.

• The menu reports the same events as with “Reset menu”: every deleted object with menu.*.deleted, every new one with menu.*.created. A POS that mirrors the menu sees that the dishes with its ids are gone.
• If hours, special days, lead times, order types, pre-orders or the minimum order change, store.updated arrives, and store.resumed if a pause was running.
• Deleted orders and reservations report nothing.

You can reset at most five times in ten minutes, “Reset menu” included.

Telling test and live apart#

livemode is in GET /me and in every event. In the test restaurant it is false, in every real restaurant true. Check it wherever your app does something real: a test order must never end up in a real till.

// 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);
}

Testing with a real restaurant#

Even before approval, your app also connects to restaurants you own yourself. This is meant for the last test with a real menu.