Un nouvel endpoint est disponible en production : GET /me. Il décrit la clé
d’API qui l’appelle — le plan qui lui est attaché, ce qu’elle a déjà consommé
sur la période en cours, son plafond, et la liste des services que son plan
autorise.
Il ne consomme aucun crédit et n’est soumis à aucun contrôle de quota.
L’appel
curl -s https://api.trustydata.app/services/v1/me \
-H "Authorization: Bearer VOTRE_CLE"
{
"plan": "GROWTH",
"consumption_count": 1284,
"quota_limit": 5000,
"services": [
"LOCALITY_AUTOCOMPLETE", "LOCALITY_SEARCH",
"ADDRESS_AUTOCOMPLETE", "ADDRESS_VIEW", "ADDRESS_GEOLOCATION",
"ADDRESS_GEOCODING", "ADDRESS_VERIFY", "ADDRESS_PROXIMITY",
"ROUTE_MATRIX",
"COMPANY_SEARCH", "COMPANY_VIEW", "COMPANY_GEOLOCATION",
"COMPANY_ENRICHMENT", "COMPANY_PROXIMITY"
]
}
Ce que renvoient les quatre champs
plan— le plan attaché à la clé (DISCOVERY,STARTER,GROWTH,
BUSINESS).consumption_count— les appels déjà décomptés sur la période de quota
en cours.quota_limit— le plafond appliqué à cette clé. Le solde restant se
calcule par soustraction. Attention : ce champ vautnullquand aucun
plafond dur n’est appliqué à la clé —nullveut dire « pas de plafond »,
pas « zéro ».services— les identifiants des services que le plan ouvre. C’est la
matrice des plans telle que le service l’applique réellement, pas une copie
de la grille tarifaire.
À quoi ça sert
Tester une connexion. Un outil d’intégration — un scénario Zapier ou Make,
un connecteur maison — a besoin de valider une clé au moment où l’utilisateur
la saisit. Jusqu’ici il fallait appeler un endpoint de données, donc décompter
un crédit à chaque test de configuration. Ce n’est plus le cas.
Savoir avant d’appeler. Tester l’appartenance à services permet
d’afficher un message utile — « cette fonction demande le plan Growth » —
plutôt que de laisser passer l’appel et de récupérer un 403 opaque. Vos
intégrations n’ont plus à dupliquer la matrice des plans de leur côté ni à la
maintenir quand elle évolue.
Suivre la consommation. Les deux compteurs permettent d’afficher un
indicateur dans votre propre interface, ou de déclencher une alerte avant
d’arriver au plafond.
Deux détails qui comptent
Une clé dont le quota est épuisé reçoit quand même une réponse 200 sur cet
endpoint. Elle reste une clé valide : seuls les endpoints facturés lui sont
refusés. Vous pouvez donc continuer à lire l’état d’une clé au moment précis
où vous en avez le plus besoin.
L’appel exige une clé valide : sans en-tête Authorization, la réponse est un
401.
Disponible depuis la version 1.4 de la plateforme (GET /version, champ
platform).
Dites-nous
- Est-ce que le format de
services(des identifiants techniques) vous
convient pour piloter votre logique côté intégration, ou préféreriez-vous
autre chose ? - Y a-t-il une information sur votre compte que vous aimeriez lire par API et
qui manque ici — date de fin de période, historique, autre ?
Vos retours en réponse 