Basis-URL
app.famulor.io durch diese Domain. Die Pfade bleiben gleich.
API Access
REST-Anfragen benötigen API Access über den Workspace-Plan oder ein wiederkehrendes Add-on. Wird der Zugriff entfernt, bleiben bestehende API-Keys und OAuth-Zugangsdaten für Workspace-Administratoren zur Prüfung und zum Widerruf verfügbar; reguläre/api/v1-Anfragen liefern jedoch 403 api_access_required.
Nach einer fehlgeschlagenen Planzahlung bleiben POST /api/v1/billing/invoice-payment und POST /api/v1/billing/portal mit gültigen Zugangsdaten erreichbar, damit ein Owner die Abrechnung wiederherstellen kann. Authentifizierungs-, Rollen- und Scope-Prüfungen gelten weiterhin.
Authentifizierung
Sende ein Bearer-Token imAuthorization-Header:
- Workspace API keys (
fam_...) – erstelle sie unter Settings → API & MCP für Server-zu-Server-Integrationen. Der vollständige Key wird einmal angezeigt. Das Dashboard hat keine Scope-Auswahl, daher trägt ein dort erstellter Key immer alle Scopes. Um einen eingeschränkteren Key zu erzeugen, rufePOST /api/v1/api-keysoderPOST /api/v1/workspaces/{workspace_id}/api-keysmit einem explizitenscopes-Array auf – die Scopes des neuen Keys müssen eine Teilmenge der Zugangsdaten sein, die ihn erstellen. - OAuth 2.0 access tokens (
fam_at_...) – verwende Authorization Code mit PKCE-S256 für Anwendungen, die im Namen eines angemeldeten Nutzers handeln.
Umgang mit Keys
- Speichere Keys in Umgebungsvariablen oder einem Secrets-Manager, nie in der Versionskontrolle.
- Beschränke jeden Key auf das, was die Integration wirklich braucht – ein Key, der nur Anrufe liest, sollte nicht zusätzlich
assistants:writehaben. Im Dashboard erstellte Keys haben immer vollen Zugriff; nutze den API-Weg von oben, um einen eingeschränkten Key zu erzeugen. - Rotiere Keys regelmäßig und sofort, sobald jemand mit Zugriff auf einen Key das Team verlässt.
- Das Widerrufen eines Keys unter Settings → API & MCP wirkt sofort; bereits laufende Anfragen können trotzdem noch abgeschlossen werden.
Anforderungen an OAuth-Clients
Ein selbst gebauter Client steuert die Authorization- und Token-Endpunkte direkt an:127.0.0.1 verwenden. OAuth-Anfragen müssen PKCE-S256 nutzen und dürfen nur für den Client registrierte Scopes anfordern. Bei einer Ratenbegrenzung wartest du die in der Antwort angegebene Zeit und versuchst es erneut.
Der Client verwendet entweder für deinen Workspace vorab genehmigte Zugangsdaten oder registriert sich dynamisch selbst über POST /api/oauth/register – gib dabei zwischen 1 und 10 eindeutige redirect_uris an. Endpunkte, unterstützte Scopes und Grant-Typen lassen sich unter /.well-known/oauth-authorization-server ermitteln.
Access-Tokens werden über den refresh_token-Grant erneuert. Refresh-Tokens rotieren bei jeder Verwendung: Das Anfordern eines neuen Access-Tokens stellt auch ein neues Refresh-Token aus und macht das gesendete sofort ungültig.
Antwortformat
Erfolgreiche Antworten enthalten das Ergebnis indata und optional meta:
Pagination
Listen-Endpunkte verwendenlimit und offset:
Mit
meta.pagination.total erkennst du, ob weitere Seiten verfügbar sind.
Fehler
Fehlschläge liefern einen stabilen Code und eine lesbare Meldung:White-Label-Kundenverwaltung
Berechtigte Reseller können über dieplatform-Endpunkte ihre eigenen Endkunden verwalten, Kunden-API-Tokens ausstellen und widerrufen, Credits übertragen und ihre Custom Domain verwalten. Diese Endpunkte benötigen die Scopes platform:read oder platform:write; Custom-Domain-Aktionen verwenden den entsprechenden Settings-Scope.
Beispiele findest du im Leitfaden zur White-Label-API.