Ein Softwarehaus betreibt viele Betriebe auf einem Zugang

Ein Softwarehaus integriert die API in seine Warenwirtschaft und schaltet sie für vierzig Betriebe frei. Mit einem gemeinsamen Schlüssel entstehen sofort zwei Probleme: Ein Betrieb, der einen Stapelimport startet, bremst die anderen aus, und am Monatsende lässt sich nicht sagen, wer welchen Verbrauch verursacht hat.

Die Verwaltungsaufrufe des Hubs lösen das getrennt nach Zuständigkeit: Der Master-Client legt Zugänge an, setzt je Zugang Limits, liest je Zugang die Nutzung und kann Kosten ausdrücklich übernehmen. Die fünf Zweige sind unabhängig — man braucht nicht alle.

Was dieser Fall voraussetzt

• Ein Master-Client. Die Verwaltungsaufrufe setzen voraus, dass Ihr Zugang Unter-Nutzer führen darf.
• Eine Zuordnung im eigenen System. Die zurückgegebene clientId muss bei Ihnen auf den Betrieb zeigen, sonst ist die Nutzungsauswertung wertlos.
• Eine Entscheidung über das Abrechnungsmodell. Zahlt der Betrieb selbst, oder springen Sie ein? Unter einer Kostenübernahme wird zuerst aus Plan und Guthaben des Betriebs bezahlt; erst wenn beide die Anfrage nicht tragen, springt der Sponsor ein — es sei denn, Sie geben mit partnerTermsAllowed die Wahl frei und der Betrieb entscheidet sich für Ihre Konditionen.
• Getrennte Aufbewahrung der Schlüssel. Ein Schlüssel je Betrieb nützt nur, wenn er nicht in einer gemeinsamen Konfiguration landet.

Der Ablauf

Die Tabelle nennt je Stufe den zuständigen Aufruf und das, was danach vorliegt. Die Begründung, warum die Stufe nicht übersprungen werden kann, steht darunter.

Warum jede Stufe nötig ist

1. Einen Partner freischalten. POST /client/partner-workspaces legt einen Arbeitsbereich mit Schlüssel und ausgewählten Freischaltungen an. Das ist der Weg, wenn ein Partner eigenständig arbeiten soll, statt nur ein Unterkonto zu sein.
2. Einen Unter-Nutzer anlegen. POST /client/users erzeugt je Betrieb einen Zugang mit initialem Schlüssel. Weitere Schlüssel für denselben Zugang legt POST /client/users/{clientId}/keys an; einen Aufruf zum Widerruf einzelner Schlüssel legt der Vertrag nicht fest.
3. Die Limits setzen. PUT /client/users/{clientId}/rate-limits ersetzt die Limits eines Zugangs. Diese Stufe ist der eigentliche Grund für getrennte Zugänge: Sie verhindert, dass ein einzelner Stapellauf das Kontingent aller aufbraucht.
4. Die Nutzung ablesen. GET /client/users/{clientId}/usage gibt Verbrauch und Guthaben je Betrieb. Das ist die Grundlage jeder Weiterverrechnung — und der einzige belastbare Weg, einem Kunden seinen Verbrauch zu erklären.
5. Kosten übernehmen. PUT /client/sponsorship-grants/{grantReference} erteilt eine Kostenübernahme aktiv. Sie geschieht nie stillschweigend: Wer sie erteilt, tut es mit einem Aufruf, und der Empfänger sieht sie.

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'

Was am Ende vorliegt

Am Ende steht eine Integration, die einmal gebaut ist und sich pro Betrieb verantworten lässt: eigener Schlüssel, eigenes Limit, ablesbarer Verbrauch. Der Betrieb, der den Stapelimport startet, bremst niemanden mehr aus.

Wo das in der Dokumentation steht

Die verbindlichen Feldlisten, Fehlercodes und Beispielantworten stehen im OpenAPI-Vertrag dieser Fläche unter docs.tapinomahub.com (tapinoma-hub). Alle Anwendungsfälle nach Fläche und Rolle geordnet: Übersicht der Anwendungsfälle.