Eine Multi-Tenant-Integration mit OAuth 2.1 bauen
Lassen Sie Ihre Nutzer ihr eigenes Crisphive-Unternehmen mit Ihrem Produkt verbinden — OAuth 2.1 mit Consent-Screen, ohne dass je ein API-Schlüssel kopiert wird.
API-Schlüssel authentifizieren Ihr eigenes Unternehmen. Wenn Sie ein Produkt bauen, an das andere Crisphive-Unternehmen andocken — eine CRM-Synchronisation, ein Buchungs-Widget, ein KI-Agent-Connector — nutzen Sie stattdessen den eingebauten OAuth 2.1 Authorization Server: Jeder Unternehmensinhaber genehmigt Ihre App auf einem Consent-Screen, und Ihre App erhält Tokens, die an dessen Mandanten gebunden sind.
/v1 und dem /mcp-Endpunkt. Senden Sie Authorization: Bearer <access_token> genau wie einen API-Schlüssel.Der Ablauf
Der Server implementiert den aktuellen OAuth-2.1-Entwurf: PKCE (S256) ist Pflicht, und die Registrierung ist dynamisch — kein manueller App-Review. Selbst registrierte Clients sind öffentlich (kein Secret); Partnerplattformen wie Zapier und Make verwenden eine von Crisphive ausgestellte Client-ID samt Secret, und nur diese werden auf dem Consent-Screen als Verified angezeigt:
| Schritt | Request |
|---|---|
| 1. AS entdecken | GET /.well-known/oauth-authorization-server (RFC 8414) → Endpoint-URLs, unterstützte Grants |
| 2. Registrieren | POST /oauth/register (RFC 7591 Dynamic Client Registration) → client_id |
| 3. Autorisieren | GET /oauth/authorize?… — der Unternehmensinhaber meldet sich bei Crisphive an und stimmt zu |
| 4. Einlösen | POST /oauth/token (grant_type=authorization_code, code, code_verifier) → { access_token, refresh_token, expires_in } |
| 5. Erneuern | POST /oauth/token (grant_type=refresh_token) → ein rotiertes Token-Paar (das alte Refresh-Token ist einmalig verwendbar) |
Tokens
Das Token ist an Unternehmen, Region und Umgebung des zustimmenden Inhabers gebunden — es kann nie einen anderen Mandanten erreichen oder zwischen Live↔Sandbox wechseln. Das Token handelt als die Person, die es genehmigt hat: Jeder Aufruf wird gegen die aktuelle Rolle dieses Mitglieds geprüft, sodass die App nie mehr tun kann als die Person im Dashboard, und es funktioniert nicht mehr, wenn die Person entfernt oder gesperrt wird. Fordern Sie einen engeren scope an (durch Leerzeichen getrennte Berechtigungscodes, z. B. customers_view job_view), um es weiter einzuschränken; lassen Sie ihn weg, gilt alles, was dieses Mitglied tun darf. Ein Scope, den das Mitglied nicht besitzt, wird bei der Zustimmung abgelehnt. Access-Tokens leben ~1 Stunde; erneuern Sie mit dem einmalig verwendbaren Refresh-Token, um verbunden zu bleiben.
Verbindungslaufzeit
Eine Verbindung wird von zwei unabhängigen Uhren bestimmt. Eine täglich genutzte Integration wird nie planmäßig getrennt; eine vergessene läuft von selbst ab.
- Inaktivitätsfenster — 30 Tage. Jede Token-Erneuerung stellt ein neues Refresh-Token aus, das weitere 30 Tage gilt. Nutzen Sie die Verbindung weiter, verlängert sie sich unbegrenzt; bleiben Sie 30 Tage inaktiv, erlischt sie.
- Absolute Obergrenze — 90 Tage. Unabhängig von der Aktivität endet eine Verbindung 90 Tage, nachdem der Unternehmensinhaber sie genehmigt hat. Das Unternehmen kann dies pro Verbindung unter Developers → MCP connections auf einen Wert von 1 bis 365 Tagen setzen; der Countdown wird ab der ursprünglichen Genehmigung gemessen, nicht ab der Änderung.
Läuft eine der beiden Uhren ab, schlägt das Erneuern fehl (OAUTH_GRANT_EXPIRED), und der Inhaber muss die App erneut über den Consent-Screen genehmigen. Behandeln Sie jede fehlgeschlagene Erneuerung als „Autorisierungsablauf neu starten“, niemals als wiederholbaren Fehler. Die Inhaber und Administratoren des Unternehmens werden 14 Tage bevor eine Verbindung abläuft per E-Mail benachrichtigt — die erneute Genehmigung erfordert den Inhaber im Browser, daher kommt die Warnung früher als bei Schlüsseln.
Die API aufrufen
curl "https://api.crisphive.com/v1/customers" \ -H "Authorization: Bearer <access_token>"
Sie bauen stattdessen einen KI-Agent-Connector? Der MCP-Server nutzt genau diesen Ablauf — konforme MCP-Clients führen ihn automatisch aus, Sie schreiben normalerweise gar keinen OAuth-Code.