Établissement de test

Ce qu'est un établissement de test#

Un établissement de test est un restaurant sur Flavoso qui n'existe que pour l'API. Il ne coûte rien, ne nécessite aucun abonnement et est ouvert jour et nuit par défaut. Pour l'API, il est traité comme un établissement en offre Pro : toutes les routes sont ouvertes, réservations incluses.

Chaque compte a au plus un établissement de test, et toutes vos applications le partagent. Il est livré avec une carte d'exemple (catégories, plats et un groupe d'options) et des tables. Vous le gérez dans la console, sous Établissement de test, dans cinq onglets : Établissement, Commandes, Réservations, Carte et Événements.

Créer et utiliser#

1. 1

   Créer

   « Créer l'établissement de test » : un clic, et il est prêt. Dans l'assistant de configuration, c'est la deuxième étape.

   Console › Établissement de test

2. 2

   Connecter votre application

   Avec un jeton de test ou via le parcours OAuth, en choisissant l'établissement de test. Avant cela, aucun événement n'est créé : sans application connectée disposant du droit correspondant, personne n'écoute.

3. 3

   Essayer

   Commander et réserver en tant que client, répondre en tant qu'établissement : faire avancer les commandes, mettre en pause, changer les horaires, marquer des plats comme épuisés. Chaque changement parvient à vos applications connectées sous forme d'événement.

   Console › Établissement de test

Comme un vrai établissement#

Pour votre application, l'établissement de test se comporte comme un vrai établissement : mêmes routes, mêmes événements, mêmes erreurs. Les commandes et réservations test suivent le même chemin que celles d'un client, et quand vous faites avancer une commande dans la console, vous faites exactement ce que fait la cuisine. Chaque changement parvient à votre application sous forme d'événement, par webhook ou via GET /events. Trois choses diffèrent :

• livemode vaut false, dans GET /me et dans chaque événement. Un établissement de test ne peut jamais passer en ligne.
• Les paiements en ligne sont simulés : une commande test que vous créez comme payée en ligne déclenche order.created puis aussitôt order.paid, sans prestataire de paiement et sans argent réel.
• Il conserve au plus 50 images provenant de image_url. Au-delà, PUT /menu n'en télécharge plus et avertit avec images_capped ; la réinitialisation les supprime.

Les outils#

Dans la console, les onglets de l'établissement de test tiennent le rôle des clients, de la cuisine, de l'accueil et du tableau de bord. Ils se mettent à jour d'eux-mêmes dès que quelque chose change dans l'établissement de test, y compris quand c'est votre application qui fait le changement via l'API.

Plus de détails sur les outils de votre application sous Outils.

Carte et synchronisation#

L'onglet Carte montre la carte de l'établissement de test exactement comme GET /menu la renvoie à une application connectée, avec les identifiants de cette application (external_id). Les éléments sans identifiant de cette application sont signalés : une synchronisation n'y touche jamais.

1. 1

   Attribuer des identifiants

   Enregistre pour chaque objet sans identifiant un external_id proposé pour votre application, par exemple demo-pizza-margherita. Plats, prix et options restent tels quels, et aucun événement n'est créé.

   Console › Établissement de test › Carte

2. 2

   Exemple de synchronisation

   Un corps prêt à l'emploi pour PUT /menu, avec la carte dans son état actuel, en merge ou en replace, toujours avec dry_run. À copier ou à ouvrir directement dans l'explorateur d'API.

   Console › Établissement de test › Carte

3. 3

   Synchroniser

   Votre application envoie sa carte. Une fois les identifiants attribués, la synchronisation ne modifie que ce qui diffère ; un essai à blanc le montre à l'avance.

4. 4

   Vérifier

   « Dernières synchronisations » montre chaque PUT /menu de vos applications avec le mode et le résumé, à côté des événements menu.synced. Ces derniers ne sont créés que si une synchronisation change réellement quelque chose.

   Console › Établissement de test › Carte

« Réinitialiser la carte » vide la carte ou recrée la carte d'exemple ; les commandes, les horaires et les connexions sont conservés, les images téléchargées depuis image_url sont supprimées avec la carte. Chaque catégorie, plat ou groupe supprimé génère un menu.*.deleted (les options disparaissent avec leur groupe), chaque nouvel objet un menu.*.created, y compris chaque option. La console en indique le nombre à l'avance. Le fonctionnement de la synchronisation est décrit sous Synchroniser la carte.

Suivre les événements#

L'onglet Événements montre les 30 derniers événements de l'établissement de test. Pour chaque application connectée, il indique ce que son webhook en a fait (livré, en attente de la prochaine tentative, échoué ou ignoré, avec le motif) et si elle l'a déjà récupéré via GET /events.

• Enveloppe : une ligne se déplie et montre l'événement exactement comme l'application choisie le reçoit.
• Renvoyer : relancer une livraison, avec le même identifiant d'événement.
• Envoyer au webhook : envoyer au webhook d'une application un événement sans livraison, par exemple un événement antérieur à la configuration du webhook ou d'un type auquel il n'est pas abonné.
• Récupérer à partir d'ici : copier l'appel GET /events dont la réponse commence exactement par cet événement.

Les envois sont limités à dix par minute et par application, « Renvoyer » et « Envoyer un événement de test » sous Webhooks compris. Les événements de test et ping ne figurent jamais dans GET /events ; l'onglet le précise à l'endroit concerné.

Réinitialiser#

« Réinitialiser l'établissement de test » supprime toutes les commandes et réservations, recrée la carte d'exemple, met fin à une éventuelle pause, efface les jours particuliers et remet dans leur état initial les horaires d'ouverture, les modes de commande, les délais de préparation, la précommande, le montant minimum, le pourboire, la zone de livraison et les réservations. Les images téléchargées depuis image_url sont supprimées. Les tables et les connexions sont conservées.

• Pour la carte, les événements sont les mêmes qu'avec « Réinitialiser la carte » : menu.*.deleted pour chaque objet supprimé, menu.*.created pour chaque nouvel objet. Une caisse qui reflète la carte voit ainsi que les plats portant ses identifiants ont disparu.
• Si les horaires, les jours particuliers, les délais de préparation, les modes de commande, la précommande ou le montant minimum changent, vous recevez store.updated, et store.resumed si une pause était en cours.
• La suppression des commandes et des réservations ne génère aucun événement.

Vous pouvez réinitialiser au plus cinq fois en dix minutes, « Réinitialiser la carte » compris.

Distinguer test et réel#

livemode figure dans GET /me et dans chaque événement. Il vaut false dans l'établissement de test et true dans tout établissement réel. Vérifiez-le là où votre application fait quelque chose de réel : une commande test n'a rien à faire dans une vraie caisse.

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

Tester avec un établissement réel#

Même avant la validation, votre application peut aussi se connecter aux établissements dont vous êtes vous-même propriétaire. C'est prévu pour un dernier test avec une vraie carte.