White-Label-API

Wenn du einen White-Label-Reseller-Workspace betreibst, kannst du deine eigenen Endkunden mit der White-Label-API programmatisch verwalten statt über das Dashboard – baue eine eigene Admin-Konsole, automatisiere das Onboarding, betreibe eigene Auth-Flows auf deiner eigenen Domain oder verknüpfe Guthaben-Aufladungen mit deinem Abrechnungssystem.

Jeder Endpunkt auf dieser Seite erfordert API Access sowie einen API-Schlüssel aus deinem White-Label-Workspace mit dem Scope platform:read oder platform:write und eine Owner- oder Admin-Rolle. Ergebnisse sind immer auf deine eigenen Kunden-Workspaces begrenzt. Ein für einen Kunden ausgestellter Schlüssel kann die REST-API nur verwenden, solange auch dessen Workspace API Access hat; das Ausstellen oder Widerrufen eines Schlüssels vergibt diese Funktion nicht.

Plattform-Nutzer auflisten

GET /api/v1/platform/users listet deine Kunden, neueste zuerst. Paginiere mit limit / offset (siehe Pagination) und suche per Name oder E-Mail mit q.

curl "https://your-domain.example/api/v1/platform/users?limit=20&q=jane" \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX"

Plattform-Nutzer registrieren

POST /api/v1/platform/users legt in deinem Auftrag ein neues Kundenkonto samt Workspace an. Zwei Modi:

invite (Standard) – kein Passwort nötig. Das Konto wird ohne Zugangsdaten angelegt; kombiniere es mit einem Login- oder Token-Aufruf weiter unten, um den Kunden (oder dein eigenes Frontend) tatsächlich hineinzubekommen.
password – du legst direkt ein initiales Passwort (mind. 8 Zeichen) für den Kunden fest.

curl https://your-domain.example/api/v1/platform/users \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"name": "Jane Doe", "email": "jane@customer.example", "mode": "invite"}'

Eine bereits irgendwo auf der Plattform registrierte E-Mail scheitert mit 409 – die Meldung verrät nie, ob dieses Konto innerhalb oder außerhalb deines eigenen Scopes liegt. Die Registrierungsantwort enthält welcome_credit mit status, requested_credits und granted_credits. Damit kann dein Onboarding anzeigen, ob die einmaligen Willkommens-Credits vergeben wurden oder später manuell übertragen werden müssen. Dies ist eine berechtigte Operator-Aktion. Sie bleibt verfügbar, wenn die Self-Service-Registrierung auf der gehosteten Login-Seite deaktiviert ist.

Registrierung und Prepaid-Standardwerte konfigurieren

GET /api/v1/platform/default-limits liefert die voneinander unabhängigen Schalter für Self-Service-Registrierung und Prepaid-Zugang, den Prepaid-Minutenpreis in EUR sowie die Standardlimits für Prepaid-Kundenkonten. Mit PATCH änderst du eine beliebige Teilmenge dieser Einstellungen.

curl https://your-domain.example/api/v1/platform/default-limits \
  -X PATCH \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"self_service_registration_enabled":false,"prepaid_accounts_enabled":true,"prepaid_extra_minute_price_eur":0.49}'

Die Self-Service-Registrierung betrifft nur die Kontoerstellung auf der gehosteten Login-Seite deiner verifizierten Custom-Domain. Bestehende Kunden können sich weiter anmelden und Operatoren können weiterhin Kunden erstellen. Der Prepaid-Zugang bestimmt separat, ob Kunden ohne bezahlten Plan Prepaid-Credits verwenden dürfen; ist er aus, müssen registrierte Kunden vor der Nutzung einen bezahlten Plan wählen. Die entsprechenden MCP-Tools heißen get_platform_default_limits und update_platform_default_limits im Toolset platform.

Willkommens-Credits konfigurieren

GET /api/v1/platform/welcome-credits liefert den einmaligen Betrag, den Status der Prepaid-Konten und automatischer Vergaben, dein aktuelles Wallet-Guthaben und die geschätzte Anzahl derzeit finanzierbarer Neukunden. Mit PATCH änderst du den Betrag für zukünftige Kunden; 800 Credits ist der empfohlene Startwert, 0 deaktiviert automatische Vergaben.

curl https://your-domain.example/api/v1/platform/welcome-credits \
  -X PATCH \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"welcome_credits": 800}'

Du kannst die Einstellung auch speichern, wenn sie dein aktuelles Wallet-Guthaben übersteigt. Kann das Wallet die vollständige Vergabe nicht decken, funktioniert die Registrierung mit 0 Willkommens-Credits weiter. Sie wird nicht automatisch nachgeholt; nutze nach dem Aufladen die Guthabenübertragung. Bestehende Kunden erhalten keine rückwirkenden Credits und spätere Änderungen gelten nur für zukünftige Kunden.

Plattform-Nutzer einloggen

POST /api/v1/platform/users/login authentifiziert einen Kunden mit dessen E-Mail und Passwort und stellt bei Erfolg ein Zugriffstoken aus. Damit kannst du ein eigenes Login-Formular auf deiner White-Label-Plattform bauen. Fehlgeschlagene Anmeldungen liefern dieselbe allgemeine 401-Antwort und verraten nicht, ob ein Konto existiert.

curl https://your-domain.example/api/v1/platform/users/login \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"email": "jane@customer.example", "password": "correct horse battery staple"}'

Dies ist die einzige White-Label-API-Operation ohne MCP-Pendant – Zugangsdaten sollten nie über einen MCP-Tool-Aufruf laufen.

Nutzer-Token erstellen

POST /api/v1/platform/users/{user_id}/token stellt für einen Kunden einen API-Schlüssel aus, ohne dessen Passwort zu benötigen – geeignet für ein Dashboard, einen Onboarding-Ablauf oder eine autorisierte Automatisierung im Auftrag des Kunden.

curl https://your-domain.example/api/v1/platform/users/USER_ID/token \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"name": "Onboarding token", "expires_in_days": 90}'

Der Klartext-Schlüssel wird genau einmal zurückgegeben – speichere ihn sofort, er lässt sich nicht erneut abrufen. Er gehört dem Kunden, nicht dir: ein weggelassenes scopes gewährt vollen Zugriff für diesen Kunden, nicht nur die Scopes, die dein eigenes Operator-Credential zufällig hat.

Plattform-Nutzer ausloggen

POST /api/v1/platform/users/{user_id}/logout widerruft die aktiven API-Schlüssel und OAuth-Tokens des Kunden in deinem Kundenbereich. Nutze den Endpunkt, um nach einer Kompromittierung oder am Ende einer Kundenbeziehung eine Abmeldung zu erzwingen. Wiederholte Aufrufe sind sicher.

curl https://your-domain.example/api/v1/platform/users/USER_ID/logout \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX"

Guthaben übertragen

POST /api/v1/platform/users/{user_id}/balance verschiebt Credits zwischen dem Guthaben deines Workspace und dem eines Kunden:

Positives credits – vergibt Credits aus deinem Wallet an den Kunden (der Standardweg, um ein Kundenkonto auszustatten).
Negatives credits – holt Credits vom Kunden zurück in dein Wallet.

Beide Richtungen erfordern, dass das Quell-Wallet den Betrag deckt – ein Wallet-Guthaben geht nie unter null, und ein Rückhol-Versuch, der das Kundenguthaben übersteigt, scheitert komplett statt teilweise angewendet zu werden.

curl https://your-domain.example/api/v1/platform/users/USER_ID/balance \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"credits": 50, "note": "Onboarding credit"}'

Individuelle Zahlungen (Custom Payments)

Mit individuellen Zahlungen kannst du einen deiner Kunden außerhalb seines regulären Plans belasten – eine einmalige Einrichtungsgebühr, eine Support-Rechnung oder ein maßgeschneidertes wiederkehrendes Add-on, das du nicht als Plan abbilden willst. Zwei Typen:

Einmalig – eine einzelne Belastung über einen festen Betrag.
Abo – eine wiederkehrende Belastung in einem von dir gewählten Intervall (Tag/Woche/Monat/Jahr), optional mit Testphase.

Jede Zahlung wird über einen von drei Kanälen zugestellt:

charge_saved_method – belastet sofort die hinterlegte Karte des Kunden. Schlägt fehl, wenn keine Karte hinterlegt ist oder die Karte einen Authentifizierungsschritt erfordert, den der Kunde selbst durchführen muss (in diesem Fall stattdessen invoice oder payment_link verwenden).
invoice – erstellt eine gehostete Rechnung, fällig in days_until_due Tagen (Standard 14), und schickt dem Kunden eine E-Mail mit Zahlungslink.
payment_link – erstellt einen Zahlungslink und liefert dessen URL zurück. Der Link ist Einmalgebrauch (er nimmt nach einer abgeschlossenen Zahlung keine weiteren mehr an), läuft aber nicht von selbst ab – teile ihn, sobald du bereit bist.

curl https://your-domain.example/api/v1/platform/users/USER_ID/custom-payments \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"kind": "one_time", "channel": "invoice", "description": "Custom integration setup", "amount_minor": 25000, "currency": "EUR"}'

amount_minor ist der Einzelpreis in der kleinsten Einheit der Währung (z. B. Cent); der Gesamtbetrag ist amount_minor * quantity. Automatische Steuerberechnung wird angewendet, sobald sie für dein Zahlungskonto verfügbar ist – das setzt voraus, dass für den Kunden bereits eine Rechnungsadresse hinterlegt ist; andernfalls schlägt die Anfrage mit einem Hinweis fehl, zuerst eine Adresse zu hinterlegen (oder automatic_tax: false übergeben, um die Steuerberechnung für diese Zahlung zu überspringen). Die Währung muss der eigenen Anzeigewährung des Kunden-Workspace entsprechen, sobald diese festgelegt ist – ein bestehender Kunde kann nicht in einer zweiten Währung belastet werden. GET /api/v1/platform/users/{user_id}/custom-payments listet die Zahlungen eines Kunden plus Kontext für die Erstellung (aufgelöster Workspace, verfügbare Währungen, hinterlegte Zahlungsmethoden, Verfügbarkeit automatischer Steuerberechnung). GET /api/v1/platform/custom-payments listet über alle Kunden in deinem Scope, filterbar nach status, kind, channel und einer Suche (q), die sowohl auf die Zahlungsbeschreibung als auch auf die E-Mail-Adresse des Kunden zutrifft.

curl "https://your-domain.example/api/v1/platform/custom-payments?status=open&limit=20" \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX"

Standardmäßig erhält der Kunde eine Benachrichtigungs-E-Mail für die Kanäle invoice und payment_link (bei charge_saved_method standardmäßig aus, da eine Kartenzahlung ohnehin einen Beleg erhält) – überschreibbar mit notify_customer. Die E-Mail nutzt deinen eigenen Absender und dein Branding, genau wie jede andere kundenseitige E-Mail auf deiner Plattform. Eine Zahlung durchläuft Status wie pending, open, paid, active / trialing (Abos), past_due, canceled, void, uncollectible und expired. GET /api/v1/platform/custom-payments/{payment_id} liefert den aktuellen Status, die Beträge und den gehosteten Link. Mit POST auf denselben Endpunkt führst du eine Aktion aus:

curl https://your-domain.example/api/v1/platform/custom-payments/PAYMENT_ID \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"action": "cancel"}'

Aktion	Wirkung
`refresh`	Synchronisiert Status und Beträge erneut vom Zahlungsanbieter.
`resend_notification`	Sendet die Benachrichtigungs-E-Mail an den Kunden erneut.
`cancel`	Storniert eine offene Rechnung oder deaktiviert einen Zahlungslink sofort. Bei einem Abo: plant die Kündigung zum Ende der laufenden Periode, außer `immediately: true` wird übergeben — dann wird sofort gekündigt.
`cancel_at_period_end`	Nur Abos: plant die Kündigung zum Ende der laufenden Periode (gleiche Wirkung wie `cancel` ohne `immediately`).
`mark_uncollectible`	Bucht eine offene Rechnung als uneinbringlich aus.
`deactivate_link`	Deaktiviert einen Zahlungslink, ohne bereits darüber bezahlte Beträge zu beeinflussen.

immediately (boolean, optional) wirkt sich nur auf die cancel-Aktion bei einem Abo aus: true kündigt sofort, false/weggelassen kündigt zum Ende der laufenden Periode. Bei einmaligen Rechnungen/Zahlungslinks oder anderen Aktionen hat es keine Wirkung. Eine Stornierung oder Ausbuchung ist über diese API nicht rückgängig zu machen. Einschränkungen: Es gibt keine Rückerstattungs-Aktion – Rückerstattungen direkt über dein Zahlungskonto-Dashboard vornehmen. Jede Zahlung ist eine einzelne Position (keine Rabatte, Gutscheine oder mehrere Positionen), und der Preis eines bestehenden Abos kann nicht nachträglich geändert werden – stattdessen kündigen und ein neues erstellen. Die entsprechenden MCP-Tools sind list_custom_payments, get_custom_payment, create_custom_payment und run_custom_payment_action im Toolset platform – siehe MCP weiter unten.

API-Schlüssel verwalten

Öffne im Reseller-Workspace Settings → API & MCP. Scrolle unter den MCP-Verbindungen zu Create a new API key, gib einen Namen ein und wähle Create key. Dafür brauchst du API Access und die Rolle Owner oder Admin.

API & MCP — Einstieg in die Einstellungen; API-Schlüssel folgen weiter unten

Jeder Workspace – auch Kunden-Workspaces aus dieser API – kann seine eigenen API-Schlüssel über /api/v1/api-keys oder Settings → API & MCP im Dashboard verwalten. Ein nutzergebundenes Credential kann außerdem direkt über /api/v1/workspaces/{workspace_id}/api-keys einen Key für einen anderen Workspace derselben Brand erstellen, wenn der Nutzer dort aktuell Owner oder Admin ist. Dieser verschachtelte Endpoint ist eine allgemeine Multi-Workspace-Funktion und benötigt keinen White-Label-Zugang.

curl https://your-domain.example/api/v1/api-keys \
  -X POST \
  -H "Authorization: Bearer fam_XXXXXXXXXXXX" \
  -H "Content-Type: application/json" \
  -d '{"name": "CRM integration", "scopes": ["calls:read", "leads:write"]}'

Ein Schlüssel kann keinen anderen Schlüssel mit weiterreichenden Rechten erzeugen: scopes eines neuen Schlüssels müssen eine Teilmenge der Scopes des aufrufenden Schlüssels sein. GET /api/v1/api-keys listet Schlüssel ohne ihre Secrets; DELETE /api/v1/api-keys/{id} widerruft einen Schlüssel.

MCP

Alles oben ist auch als MCP-Tools verfügbar, gruppiert im Toolset platform (dazu list_api_keys / create_api_key / revoke_api_key im Toolset settings). Verbinde dich mit dem Toolset-Selektor:

https://your-domain.example/mcp?toolsets=platform

Tool	Entspricht
`list_platform_users`	`GET /api/v1/platform/users`
`get_platform_user`	`GET /api/v1/platform/users/{user_id}`
`register_platform_user`	`POST /api/v1/platform/users`
`get_platform_default_limits`	`GET /api/v1/platform/default-limits`
`update_platform_default_limits`	`PATCH /api/v1/platform/default-limits`
`get_platform_welcome_credit_settings`	`GET /api/v1/platform/welcome-credits`
`update_platform_welcome_credit_settings`	`PATCH /api/v1/platform/welcome-credits`
`create_platform_user_token`	`POST /api/v1/platform/users/{user_id}/token`
`logout_platform_user`	`POST /api/v1/platform/users/{user_id}/logout`
`transfer_platform_credits`	`POST /api/v1/platform/users/{user_id}/balance`
`list_custom_payments`	`GET /api/v1/platform/custom-payments` (oder `GET /api/v1/platform/users/{user_id}/custom-payments` mit `user_id`)
`get_custom_payment`	`GET /api/v1/platform/custom-payments/{payment_id}`
`create_custom_payment`	`POST /api/v1/platform/users/{user_id}/custom-payments`
`run_custom_payment_action`	`POST /api/v1/platform/custom-payments/{payment_id}`

Ein login_platform_user-Tool gibt es nicht – der Login bleibt aus dem oben genannten Grund REST-only. Die MCP-Tools akzeptieren zur Identifikation des Ziel-Kunden entweder eine user_id oder eine email; REST nimmt user_id immer aus dem URL-Pfad.

Leistungen in einen Kundenplan aufnehmen

Wähle unter Plans die Funktionen und zusätzliche Kapazität für den wiederkehrenden Planpreis aus. Kunden sehen diese als Im Plan enthalten. Zusätzlich gekaufte Kapazität kommt zum enthaltenen Umfang hinzu; eine enthaltene Funktion wird nicht nochmals als Add-on berechnet. Einmalige Leistungen bleiben separate Käufe. Der Editor zeigt Plattformgebühr, deren Steuer, eine geschätzte Reserve für Zahlungskosten und deinen verbleibenden Beitrag pro Kunde. Eigene Betriebskosten und Steuern sind darin noch nicht berücksichtigt. Jahresangebote verwenden vorhandene Jahrespreise; andernfalls weist der Editor ausdrücklich zwölf monatliche Kostenperioden aus. Enthaltene Credits werden bei beiden Zahlungsintervallen monatlich bereitgestellt. Die Zahlungsbestätigung aktiviert die gebuchten Leistungen. Bei vorgemerkter Kündigung bleibt der Zugang bis zum Ende des bezahlten Zeitraums bestehen. Eine fehlgeschlagene Verlängerung sperrt bezahlte Leistungen; erfolgreiche Zahlung stellt den gebuchten Vertrag wieder her. Gekauftes Guthaben bleibt getrennt. Nach Kündigung gilt deine bestehende Regel für Free-Accounts. Dupliziere einen Plan mit bestehenden Abonnements, bevor du Preis oder Inklusivleistungen änderst. Die Kopie startet inaktiv und kann vor Veröffentlichung geprüft werden.

Inklusivleistungen über die API verwalten

GET /api/v1/reseller/plans mit settings:read liefert deine Pläne und verfügbare Leistungscodes. PUT /api/v1/reseller/plans/{id}/inclusions mit settings:write ersetzt die Inklusivleistungen eines berechtigten Plans. Beide Vorgänge verlangen Owner- oder Admin-Rechte im Whitelabel-Workspace. Die MCP-Tools heißen list_reseller_plans und update_reseller_plan_inclusions. Sie konfigurieren das Angebot und lösen keine Kundenzahlung oder kostenpflichtige Buchung aus.

Kundenpasswörter und Konto-E-Mails

Unter Nutzer → Kunde auswählen → Kontozugang kannst du eine Reset-E-Mail senden oder ein neues Passwort festlegen. Direktes Setzen ist nur möglich, wenn das Kundenkonto ausschließlich zu deiner Marke gehört. Bei Konten mit Zugriff auf andere Marken oder Plattform-Workspaces sende eine Reset-E-Mail, damit der Kunde seinen globalen Login selbst kontrolliert. Konto-E-Mails verwenden deine verifizierte Domain, dein Branding und deinen konfigurierten SMTP-Absender. Dazu gehören Einladungen, Passwort-Resets, Bestätigungen von E-Mail-Änderungen, Bestätigungscodes und aktivierte Sicherheitsbenachrichtigungen. E-Mail-Änderungen können eine Bestätigung von der bisherigen und der neuen Adresse erfordern. Bei Versandfehlern wird nicht auf eine andere Marke gewechselt. Prüfe dann deine SMTP-Einstellungen. Mit GET /api/v1/platform/users/{user_id}/password?workspace_id=... prüfst du die Berechtigungen. POST an denselben Endpoint akzeptiert den Workspace, die Aktion reset oder set und bei set ein Passwort. Die MCP-Tools get_platform_user_password_access und manage_platform_user_password prüfen dieselben Kundengrenzen. Die Reset-Aktion verwendet deinen SMTP-Absender. Passwörter dürfen nie geloggt werden.

Zahlungskonto und Finanzaktivität

Vor der Aktivierung führt Zahlungen verbinden durch die Verifizierung. Danach bietet Zahlungen & Auszahlungen eine Übersicht, Kundenzahlungen, Bankauszahlungen, den Tab Kontoguthaben-Bericht und Checkout-Einstellungen. Das Dashboard zeigt das Guthaben deines Zahlungskontos. Beträge behalten ihre tatsächliche Abrechnungswährung. Die externe Dashboard-Aktion öffnet das vom verbundenen Konto unterstützte Dashboard. Der Kontoguthaben-Bericht unterstützt Filter für Zeitraum, Währung und Zeitzone sowie CSV-Exporte. Wenn verfügbar, zeigt die Übersicht auch ein Angebot für Sofortauszahlungen und einen Chart zum Zahlungsvolumen. Sofortauszahlungen erscheinen nur bei geeignetem Guthaben. Finanzierung erscheint nach Checkout, wenn Unternehmensfinanzierung für dein Konto verfügbar ist. Auszahlungen und Finanzierungsanträge erfordern deinen eigenen authentifizierten Workspace-Zugang und gegebenenfalls eine zusätzliche Verifizierung des Zahlungskontos. Verwende GET /api/v1/reseller/billing oder das MCP-Tool get_reseller_billing im Toolset billing mit billing:read. Voraussetzung sind Owner- oder Admin-Rechte in deinem Whitelabel-Workspace und API Access. Die Standardübersicht liefert den Status sowie verfügbares und ausstehendes Guthaben. Mit view=payments oder view=payouts erhältst du Aktivitäten; limit liegt zwischen 1 und 100 (Standard 25). Übergib den zurückgegebenen next_cursor innerhalb von 24 Stunden als cursor für die nächste Seite; null bedeutet das Ende. Cursor sind an Konto und Ansicht gebunden. Vor der Aktivierung bleibt das Guthaben-Array leer und Aktivitätsabfragen liefern 409. Diese Funktionen lesen ausschließlich Daten: Sie erstatten keine Zahlungen, lösen keine Auszahlungen aus, ändern keine Bankkonten und erstellen keine Dashboard-Anmeldesitzungen. Mit view=transactions liest du die Guthabenbuchungen für den Abgleich: Beträge mit Vorzeichen, Nettoänderungen, öffentliche Transaktionskategorien und Verfügbarkeitsdaten. Lade weitere Seiten mit next_cursor. Berichtsexporte und Finanzierungsanträge sind interaktive Kontovorgänge; Public API und MCP bieten Lesezugriff und reichen keine Anträge ein oder lösen Auszahlungen aus. Ein Kontohinweis zeigt nach dem Onboarding offene Verifizierungsaufgaben an, auch wenn diese Zahlungen vorübergehend einschränken. Ohne Hinweise bleibt der Banner ausgeblendet. Der Steuerbereich unter Checkout enthält Steuereinstellungen und Steuerregistrierungen. Registrierungsdetails sind über view=tax auch schreibgeschützt verfügbar; interaktive Änderungen sind in der authentifizierten Oberfläche des Zahlungskontos möglich. Die Steuerverwaltung ist auch per API und MCP mit billing:write und Owner-/Admin-Zugriff verfügbar: PUT /api/v1/reseller/tax/settings aktualisiert Vorgaben und Unternehmensadresse; POST /api/v1/reseller/tax/registrations erstellt oder plant die Steuererhebung; PATCH /api/v1/reseller/tax/registrations ändert Beginn oder Ablauf. Einstellungen liest du mit GET /api/v1/reseller/tax/settings. Die Tools heißen get_reseller_tax_settings, update_reseller_tax_settings, create_reseller_tax_registration und update_reseller_tax_registration. Nutze die undurchsichtige Registrierungsreferenz aus der Steueransicht (24 Stunden gültig) und einen eindeutigen Anfrageschlüssel für wiederholte Erstellungsanfragen. Registrierungen können nicht gelöscht werden und melden dein Unternehmen nicht bei Steuerbehörden an. Änderungen müssen den ausdrücklichen steuerlichen Anweisungen des Unternehmensinhabers entsprechen.

Zugriff auf Wissensquellen

Whitelabel-Anbieter können Website-Crawl, Cloud-Speicher-Synchronisierung und Auto-Synchronisierung separat in Kundentarifen und Prepaid-Standardwerten aktivieren. Die Auto-Synchronisierung steuert die geplante Aktualisierung beider Quelltypen; die jeweilige Quellfunktion muss ebenfalls freigeschaltet sein. Der eigene Workspace des Anbieters folgt unabhängig davon seinem eigenen Tarif. Cloud-Speicher-Quellen benötigen zusätzlich Einstellungen → Workspace → Beta-Funktionen im jeweiligen Kunden-Workspace. Neue oder geänderte Inhalte verbrauchen weiterhin Credits; die Freigabe enthält keine kostenlose Verarbeitung. Tarifberechtigungen liest du mit GET /api/v1/reseller/plans und änderst sie mit PATCH /api/v1/reseller/plans/{id}/knowledge-sources (settings:write). Das passende MCP-Tool heißt update_reseller_plan_knowledge_sources. Änderungen gelten für Kunden, die diesen Tarif nutzen. Prepaid-Standardwerte verwenden die oben beschriebenen API-Endpunkte und MCP-Tools für Standardlimits.

White-Label-Programm

White-Label-Einrichtung

Prompt-Vorlagen

Abrechnung & Zahlungen

Tarife & Preise

Kundenlimits verwalten

Datenmigration

White-Label-API

White-Label-API

Plattform-Nutzer auflisten

Plattform-Nutzer registrieren

Registrierung und Prepaid-Standardwerte konfigurieren

Willkommens-Credits konfigurieren

Plattform-Nutzer einloggen

Nutzer-Token erstellen

Plattform-Nutzer ausloggen

Guthaben übertragen

Individuelle Zahlungen (Custom Payments)

API-Schlüssel verwalten

MCP

Leistungen in einen Kundenplan aufnehmen

Inklusivleistungen über die API verwalten

Kundenpasswörter und Konto-E-Mails

Zahlungskonto und Finanzaktivität

Zugriff auf Wissensquellen

​Plattform-Nutzer auflisten

​Plattform-Nutzer registrieren

​Registrierung und Prepaid-Standardwerte konfigurieren

​Willkommens-Credits konfigurieren

​Plattform-Nutzer einloggen

​Nutzer-Token erstellen

​Plattform-Nutzer ausloggen

​Guthaben übertragen

​Individuelle Zahlungen (Custom Payments)

​API-Schlüssel verwalten

​MCP

​Leistungen in einen Kundenplan aufnehmen

​Inklusivleistungen über die API verwalten

​Kundenpasswörter und Konto-E-Mails

​Zahlungskonto und Finanzaktivität

​Zugriff auf Wissensquellen

Plattform-Nutzer auflisten

Plattform-Nutzer registrieren

Registrierung und Prepaid-Standardwerte konfigurieren

Willkommens-Credits konfigurieren

Plattform-Nutzer einloggen

Nutzer-Token erstellen

Plattform-Nutzer ausloggen

Guthaben übertragen

Individuelle Zahlungen (Custom Payments)

API-Schlüssel verwalten

MCP

Leistungen in einen Kundenplan aufnehmen

Inklusivleistungen über die API verwalten

Kundenpasswörter und Konto-E-Mails

Zahlungskonto und Finanzaktivität

Zugriff auf Wissensquellen