Démarrer
Authentification
Choisir le bon type de jeton et gérer son cycle de vie.
Mise à jour : 2026-09-09
L'API utilise OAuth 2.0 en client credentials : vous échangez un couple client_id / client_secret contre un jeton Bearer rattaché à un établissement et à son abonnement.
Les trois types de jeton
| Jeton | Usage | Portée |
|---|---|---|
| Clé API d'établissement | Automatisations, scripts, tableaux de bord internes | Tous les outils autorisés pour l'établissement, sans utilisateur nommé |
| Jeton employé (Jarvis) | Agents vocaux et applications employé | Limitée aux permissions du salarié, avec un badge « propriétaire » le cas échéant |
| OAuth 2.0 utilisateur | Une application tierce agissant au nom d'un utilisateur | Fixée par les périmètres acceptés à la connexion |
Cycle de vie
- Le secret n'est affiché qu'une fois, à la création du client API.
- Le jeton expire au bout de 24 heures : redemandez-en un plutôt que de le prolonger.
- Un 401 signifie jeton absent, expiré ou invalide — reprenez à l'étape du token.
- Révoquez un client API depuis « Mon profil → API Clients » dès qu'un secret a fuité.
Cloisonnement par établissement
Chaque appel est résolu dans le périmètre de l'établissement du jeton. Un groupe multi-sites utilise un client API par établissement ; il n'existe pas de jeton qui verrait plusieurs restaurants à la fois.
Vérifier avant d'écrire
Avant tout appel d'écriture dans une automatisation, appelez GET /api/me : si l'établissement renvoyé n'est pas celui attendu, arrêtez le scénario.