Utiliser la prise en charge de l’éditeur — ou délibérément non

Un atelier utilise les fonctions tapinomahub via son logiciel d’atelier. L’éditeur a proposé de prendre en charge les requêtes véhicule. Mais l’atelier a aussi son solde et ses conditions — et ne veut pas découvrir sur la facture qui a payé quelle requête.

Dans le Hub, la prise en charge est une relation explicite à deux côtés : le sponsor l’accorde et peut autoriser le choix des conditions, le bénéficiaire la voit et décide. Rien ne se fait en silence — aux conditions partenaire, pas même quand une requête sort de la prise en charge.

Ce que ce cas suppose

• Une prise en charge accordée. Elle naît chez le sponsor ; le bénéficiaire ne peut pas la créer.
• L’autorisation des conditions partenaire, si elles doivent être choisies. Sans partnerTermsAllowed, choisir partner renvoie 403.
• Un regard sur les endpoints couverts. endpointKeys indique à quoi s’applique la prise en charge — toute requête n’y figure pas.
• Une décision pour les requêtes hors prise en charge. Sous partner, une requête non couverte est refusée, non payée sur votre solde.

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. Consulter les prises en charge. GET /client/sponsorship-grants/received liste par prise en charge reference, sponsor, endpointKeys, startsAt, endsAt, active, partnerTermsAllowed et partnerTermsChosen. On y voit ce qui est couvert et si le choix est ouvert.
2. Choisir les conditions. PUT /client/sponsorship-grants/received/{grantReference}/billing-mode prend mode avec own ou partner. Sous partner, votre solde reste intact ; sans autorisation du sponsor, l’appel renvoie 403. Si le sponsor retire l’autorisation, le choix tombe avec elle.
3. Lire le solde. GET /client/credits renvoie balanceCents, creditLimitCents et availableCents. Si l’entreprise travaille aux conditions partenaire, billingMode vaut partner et les montants sont null — son solde n’est pas débité, donc pas affiché.
4. Lire la consommation. GET /client/usage indique la période, par plan used, includedMonthlyQuantity et remaining, et par endpoint used et chargedCents. On vérifie ainsi que les requêtes sont allées là où le choix devait les envoyer.

curl -X PUT \
  -H 'X-Api-Key: <API_KEY>' \
  -H 'Content-Type: application/json' \
  -d '{"mode":"partner"}' \
  'https://api.tapinomahub.com/client/sponsorship-grants/received/<grantReference>/billing-mode'

Ce que l’on obtient

Au final, l’entreprise sait pour chaque requête qui paie : aux conditions partenaire, le sponsor pour les endpoints couverts ; à ses propres conditions, la facturation porte d’abord sur son propre forfait et son propre solde, et le sponsor n’intervient qu’en recours. Et aux conditions partenaire, une requête hors prise en charge est refusée visiblement, au lieu de coûter du solde en silence.

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.