Un éditeur exploite plusieurs entreprises sur un seul accès

Un éditeur intègre l’API à son ERP et l’active pour quarante entreprises. Avec une clé partagée, deux problèmes surgissent aussitôt : une entreprise lançant un import en lot ralentit les autres, et en fin de mois on ne peut dire qui a consommé quoi.

Les appels d’administration du Hub résolvent cela par responsabilité : le client maître crée des accès, fixe des limites par accès, lit la consommation par accès et peut prendre en charge des coûts explicitement. Les cinq branches sont indépendantes — toutes ne sont pas nécessaires.

Ce que ce cas suppose

• Un client maître. Les appels d’administration supposent que votre accès puisse détenir des sous-utilisateurs.
• Une correspondance dans votre système. Le clientId renvoyé doit pointer vers l’entreprise chez vous, sinon l’analyse de consommation est sans valeur.
• Une décision sur le modèle de facturation. L’entreprise paie-t-elle elle-même, ou intervenez-vous ? Sous une prise en charge, le plan et le solde de l’entreprise paient d’abord ; le sponsor n’intervient que si aucun des deux ne supporte la requête — sauf si vous ouvrez le choix avec partnerTermsAllowed et que l’entreprise opte pour vos conditions.
• Une conservation séparée des clés. Une clé par entreprise ne sert que si elle n’aboutit pas dans une configuration commune.

Le déroulement

Le tableau indique pour chaque étape l’appel compétent et ce qui existe ensuite. La justification de l’étape figure en dessous.

Pourquoi chaque étape est nécessaire

1. Activer un partenaire. POST /client/partner-workspaces crée un espace avec sa clé et des activations choisies. C’est la voie si un partenaire doit travailler de façon autonome plutôt qu’être un simple sous-compte.
2. Créer un sous-utilisateur. POST /client/users crée un accès par entreprise avec une clé initiale. D’autres clés pour le même accès sont créées par POST /client/users/{clientId}/keys ; le contrat ne définit pas d’appel pour révoquer une clé individuelle.
3. Fixer les limites. PUT /client/users/{clientId}/rate-limits remplace les limites d’un accès. Cette étape est la vraie raison d’accès séparés : elle empêche un seul traitement en lot de consommer le quota de tous.
4. Lire la consommation. GET /client/users/{clientId}/usage renvoie consommation et solde par entreprise. C’est la base de toute refacturation — et la seule voie fiable pour expliquer sa consommation à un client.
5. Prendre en charge les coûts. PUT /client/sponsorship-grants/{grantReference} accorde activement une prise en charge. Jamais tacitement : celui qui l’accorde le fait par un appel, et le bénéficiaire la voit.

curl -X POST \
  -H 'X-Api-Key: <MASTER_API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"name":"Autoverwertung Beispiel GmbH","applicationLabel":"erp-connector","rateLimits":[{"endpointKey":"vin.vehicle","windowSeconds":60,"maxRequests":120,"isActive":true}]}' \
  'https://api.tapinomahub.com/client/users'

Ce que l’on obtient

Il reste une intégration construite une fois et justifiable par entreprise : clé propre, limite propre, consommation lisible. L’entreprise qui lance l’import en lot ne ralentit plus personne.

Où cela figure dans la documentation

Les listes de champs contractuelles, les codes d’erreur et les réponses d’exemple se trouvent dans le contrat OpenAPI de cette surface, à l’adresse docs.tapinomahub.com (tapinoma-hub). Tous les cas d’usage classés par surface et par rôle : aperçu des cas d’usage.