Zum Hauptinhalt springen
Liste aktive menschliche Mitglieder, ändere einen Plan und setze das Extra-Nutzungslimit. Beträge sind Euro. Die Aufrufe laufen über den BILLING_API Scope des Workspace-API-Schlüssels. Schreibzugriffe laufen als der Service Account, dem der Schlüssel gehört. Diese API lädt niemanden ein und deaktiviert niemanden. Dafür nutzt du die User Management API.
Diese Routen gelten, wenn GET /billing/v1/mode den Modus ai-models-included liefert. Ein Dedicated Deployment liefert immer bring-your-own-keys, auch wenn Langdock die Modellschlüssel verwaltet. Der andere Modus antwortet mit 409 und code BILLING_MODE_MISMATCH.

​
Basis-URL

​
Voraussetzungen

  • API-Schlüssel mit dem Scope BILLING_API
  • Der Besitzer ist ein Service Account, der nicht gelöscht ist und eine aktive Admin-Mitgliedschaft hat
  • USER_MANAGEMENT_API am selben Schlüssel, wenn du email, name oder einen E-Mail-Filter brauchst

​
Plan ändern

PUT /users/{userId}/plan nimmt den Plan direkt entgegen.
business ist der andere Wert. Den Plan zu setzen, den das Mitglied schon hat, ändert nichts. Ein Wechsel auf business_max schließt die offene Nutzungslimit-Anfrage, die zu diesem Upgrade gehört. Ein Wechsel auf business schließt keine. Eine Anfrage, die nach dem Upgrade entsteht, bleibt offen. business_max erneut zu setzen wiederholt eine verknüpfte Anfrage, die beim ersten Mal nicht geschlossen wurde, schließt aber diese neuere Anfrage nicht. Ohne usageRequestId wird der Plan gespeichert, auch wenn das Schließen der Anfrage fehlschlägt. Der Wechsel fügt einen berechneten Seat hinzu, wenn der Zielplan keinen freien Seat mehr hat. Die Seat-Änderung wird gespeichert, bevor das Abo-Update an Stripe geht. Die Zahlen stehen unter Seats abrufen. Übergib usageRequestId in der Query, um genau diese Anfrage im selben Schreibzugriff zu beantworten. Der Plan wird nur gespeichert, wenn die Anfrage zu diesem Mitglied gehört, noch offen ist und der Wechsel auf business_max geht. Sonst wird nichts geschrieben. Fehlt die Anfrage oder gehört sie nicht zu diesem Mitglied, kommt 404 mit code NOT_FOUND. Ist sie nicht mehr offen, kommt 409 mit code USAGE_REQUEST_NOT_PENDING. Der aktuelle Status steht in details.status. Ein Wechsel, der das Kontingent nicht erhöht, gibt 409 mit code USAGE_REQUEST_NOT_ANSWERED. Die Anfrage bleibt offen. Die Antwort ist das Mitgliedsobjekt mit extraUsagePeriodSpend auf null.
Langdock blockiert bewusst Browser-basierte Anfragen, um deinen API-Schlüssel zu schützen und die Sicherheit deiner Anwendungen zu gewährleisten. Weitere Informationen findest du in unserem Guide zu Best Practices für API-Schlüssel.