Format des erreurs
Les handlers métier retournent l’enveloppe suivante. Exemple de validation :details dépend de l’erreur et peut être absent. Conservez request_id, la
route, le statut HTTP et l’heure pour le support, sans jeton ni données client
inutiles. Une erreur avant le handler, notamment 429, peut avoir un autre
format et ne pas fournir de request_id. Vérifiez le statut HTTP avant de lire
le JSON.
Une vérification de créneau négative renvoie
200 avec data.available: false.
À la création, un créneau non réservable produit 422, pas 409. Un appel
manqué traité avec 201 et un résultat SKIPPED_* n’est pas une erreur.
Débit et reprise
La règle des routes partenaires est configurée à 600 requêtes par minute par IP cliente, sans quota par clé. Lorsque présents, les en-têtes sontx-ratelimit-limit, x-ratelimit-remaining et x-ratelimit-reset ; ce dernier
contient un instant Unix en millisecondes. Ils ne sont pas garantis sur
chaque réponse. En cas de 429, réduisez la cadence et espacez les nouvelles
tentatives.
Ne répétez pas une écriture à l’aveugle après un timeout ou une erreur serveur :
elle peut avoir été enregistrée. Pour une réservation, utilisez la recherche par
external_id décrite dans le parcours. Pour
un appel manqué, réutilisez external_call_id et consultez les résultats de
l’endpoint. Les délais et reprises des webhooks ont un
contrat distinct.
Pour un appel manqué en échec, une ligne déjà enregistrée peut faire retourner
SKIPPED_DUPLICATE à la reprise avec le même external_call_id, sans relancer
l’envoi WhatsApp. Contactez le support pour vérifier cet échec ; ne changez pas
l’identifiant pour forcer un nouvel envoi. SENT signifie que la tâche WhatsApp
a été programmée, pas que le client a reçu le message.