URL de base
app.famulor.io est la plateforme hébergée. Si vous vous connectez sur un domaine locataire en marque blanche, utilisez ce domaine : l’API s’y exécute avec l’image de marque du locataire et les mêmes chemins s’appliquent.
Authentification
Toutes les requêtes nécessitent un jeton Bearer dans l’en-têteAuthorization. Deux types de jetons sont acceptés :
- Clés API (
fam_...) — créez-les depuis Paramètres → Clés API. La clé complète ne s’affiche qu’une seule fois, au moment de la création ; seul un hachage est conservé ensuite. Vous pouvez éventuellement restreindre une clé à certaines portées (par exempleassistants:read,calls:write,campaigns:write,dashboards:read,dashboards:write,leads:write,phone_numbers:write,sip_trunks:write,knowledge:write,voices:read,billing:read) et lui définir une date d’expiration. Une clé sans restriction de portée dispose d’un accès complet ; une portée*:writeinclut automatiquement le*:readcorrespondant. Idéal pour les intégrations serveur à serveur. Les endpoints du tableau de bord acceptent aussicalls:read/write, si bien que les clients OAuth utilisant les quatre portées standards restent compatibles. - Jetons d’accès OAuth 2.0 (
fam_at_...) — émis via le flux OAuth de la plateforme (authorization code + PKCE, enregistrement dynamique des clients). Portée limitée et durée de vie courte (1 heure, avec jetons de rafraîchissement). Idéal pour les applications tierces agissant pour le compte d’un utilisateur.
Enveloppe de réponse
Chaque endpoint renvoie une enveloppe JSON cohérente. Les réponses réussies enveloppent la charge utile dansdata (avec un meta optionnel) :
Ce que l’API renvoie — et ce qu’elle ne renvoie pas
L’API REST et le point de terminaison MCP renvoient la même vue délibérément sélectionnée des données de votre espace de travail : tout ce dont vous avez besoin pour développer, rien sur le fonctionnement interne de la plateforme. Absent de toutes les réponses :- Identifiants d’infrastructure — identifiants de session média, de salle, de trunk, de routage et d’opérateur de la couche téléphonie sous-jacente.
- Chemins de stockage internes — les enregistrements sont fournis via une URL signée à durée limitée (
GET /calls/{id}/recording), jamais sous forme de chemin de bucket. - Coûts de la plateforme et détails de facturation — coûts des fournisseurs, compteurs de tokens/caractères/secondes et suivi des débits. Votre propre consommation est exprimée dans les unités facturées : minutes et crédits (
GET /balance,GET /transactions). - Détails internes des modèles — quel modèle a évalué un appel ou rédigé le résumé. Le verdict, le score et le résumé sont renvoyés ; le moteur qui les produit ne l’est pas.
- Secrets — mots de passe, jetons et identifiants d’opérateur ne sont jamais relisibles après enregistrement ; vous obtenez au mieux un indice masqué.
- Diagnostics d’exploitation — les événements d’appel internes (bascules de composants, erreurs de session, écritures de consommation) sont filtrés des événements de
GET /calls/{id}.
Pagination
Les endpoints de liste se paginent avec les paramètres de requêtelimit et offset :
Le
meta.pagination.total de la réponse indique le nombre total de résultats (indépendamment de limit/offset), ce qui vous permet de paginer jusqu’à ce que offset + limit >= total :
Erreurs
Les échecs renvoient une enveloppe d’erreur avec uncode stable et lisible par une machine, ainsi qu’un message lisible par un humain :
Limites de débit
Des limites de débit d’utilisation équitable s’appliquent par compte. Si vous les dépassez, l’API répond429 Too Many Requests ; patientez puis réessayez avec un backoff exponentiel. Les limites par plan seront documentées ici dès leur publication.