Skip to main content
Voici des recettes pour la poignée de problèmes que rencontrent la plupart des intégrations, construites à partir des formes réelles de requêtes et de réponses de l’introduction à l’API. Adaptez le point de terminaison, les champs et les portées à la ressource avec laquelle vous travaillez — ce sont les modèles eux-mêmes (et non les payloads exacts) qui valent la peine d’être réutilisés.

Garder la clé API hors du client

N’appelez jamais l’API directement depuis du code navigateur ou mobile — cela expose votre clé à quiconque ouvre les outils de développement. Placez plutôt un proxy léger devant l’API : votre frontend appelle votre propre backend, et seul votre backend détient la clé Famulor.
Le frontend ne voit jamais FAMULOR_API_KEY — il ne communique qu’avec /api/trigger-call sur votre propre domaine.

Réessayer avec un backoff

Un 429 ou un 5xx mérite généralement d’être réessayé plutôt que de faire échouer immédiatement la requête. Espacez les tentatives au lieu de marteler l’API :
Chaque tentative échouée double approximativement le temps d’attente (500 ms, 1 s, 2 s…) avec un peu de gigue aléatoire, afin que les appelants parallèles ne réessaient pas tous en même temps.

Recevoir des webhooks

Les webhooks de réservation sont signés : définissez une URL sur un type d’événement de réservation, et chaque envoi porte X-Famulor-Signature: sha256=<hex digest> — un HMAC-SHA256 du corps de la requête brut, calculé avec le secret affiché une seule fois lors de l’enregistrement de l’URL. Les webhooks de variables utilisent le même mécanisme avec leur propre secret, tandis que les webhooks post-appel au niveau de l’assistant ne sont pas signés. Vérifiez la signature avant de faire confiance au payload :
Vérifiez la signature à partir des octets bruts, avant tout traitement JSON. Reformater le corps au préalable peut modifier les espaces ou l’ordre des clés et casser silencieusement la vérification de signature.

Appeler un CSV en lot

Pour composer une liste plutôt qu’un seul numéro, limitez le nombre d’appels déclenchés simultanément — l’API rejette les requêtes dès que votre réserve de crédits ou votre limite de concurrence est atteinte, si bien qu’une boucle non bornée ne fait que produire un mur d’erreurs au lieu de terminer plus vite.
famulorRequest est ici l’utilitaire de réessai avec backoff vu plus haut — le traitement par lot vous donne une concurrence maîtrisée, et cet utilitaire absorbe les 429 occasionnels sans faire échouer l’ensemble de l’exécution. Pour un volume dépassant un script ponctuel, une campagne ou une automatisation déclenchée par des données CRM demande généralement moins de code personnalisé à maintenir qu’un script de traitement par lot qu’il faut garder en fonctionnement.