A software vendor operates many businesses on one access

A software vendor integrates the API into its ERP and enables it for forty businesses. With a shared key two problems appear at once: one business starting a bulk import slows everyone else down, and at month end nobody can say who caused which consumption.

The Hub’s administrative calls solve this by responsibility: the master client creates accesses, sets limits per access, reads usage per access and can explicitly sponsor costs. The five branches are independent — you do not need all of them.

What this case requires

• A master client. The administrative calls require that your access may hold sub-users.
• A mapping in your own system. The returned clientId has to point to the business on your side, otherwise the usage analysis is worthless.
• A decision on the billing model. Does the business pay itself, or do you step in? Under a sponsorship the business’s own plan and balance pay first; only when neither carries the request does the sponsor step in — unless you release the choice with partnerTermsAllowed and the business opts for your terms.
• Separate storage of the keys. One key per business only helps if it does not end up in a shared configuration.

The sequence

The table names the responsible call per stage and what exists afterwards. The reasoning for why a stage cannot be skipped follows below it.

Why each stage is needed

1. Enable a partner. POST /client/partner-workspaces creates a workspace with its key and a selected set of entitlements. That is the route when a partner is to work independently rather than merely be a sub-account.
2. Create a sub-user. POST /client/users creates one access per business with an initial key. Further keys for the same access are created by POST /client/users/{clientId}/keys; the contract does not define a call for revoking an individual key.
3. Set the limits. PUT /client/users/{clientId}/rate-limits replaces an access’s limits. This stage is the actual reason for separate accesses: it stops a single bulk run from consuming everyone’s quota.
4. Read the usage. GET /client/users/{clientId}/usage returns consumption and balance per business. That is the basis of any on-charging — and the only reliable way to explain consumption to a customer.
5. Sponsor the costs. PUT /client/sponsorship-grants/{grantReference} grants a sponsorship actively. It never happens silently: whoever grants it does so with a call, and the recipient sees it.

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'

What you end up with

What remains is an integration built once and accountable per business: its own key, its own limit, readable consumption. The business starting the bulk import no longer slows anyone down.

Where to find this in the documentation

The binding field lists, error codes and sample responses live in this surface’s OpenAPI contract at docs.tapinomahub.com (tapinoma-hub). All use cases arranged by surface and role: overview of the use cases.