Construya una integración multi-tenant con OAuth 2.1
Permita que sus usuarios conecten su propio negocio de Crisphive a su producto — OAuth 2.1 con pantalla de consentimiento, sin copiar nunca una clave de API.
Las claves de API autentican su propio negocio. Cuando construye un producto al que se conectan otros negocios de Crisphive — una sincronización con CRM, un widget de reservas, un conector de agentes de IA — use en su lugar el servidor de autorización OAuth 2.1 integrado: cada propietario aprueba su aplicación en una pantalla de consentimiento, y su aplicación recibe tokens vinculados a su tenant.
/v1 y el endpoint /mcp. Envíe Authorization: Bearer <access_token> exactamente igual que una clave de API.El flujo
El servidor implementa el borrador actual de OAuth 2.1: PKCE (S256) es obligatorio y el registro es dinámico — sin revisión manual de aplicaciones. Los clientes autorregistrados son públicos (sin secreto); las plataformas asociadas como Zapier y Make usan un client id y un secreto emitidos por Crisphive, y solo esas se muestran como Verified en la pantalla de consentimiento:
| Paso | Solicitud |
|---|---|
| 1. Descubrir el AS | GET /.well-known/oauth-authorization-server (RFC 8414) → URL de los endpoints, grants soportados |
| 2. Registrarse | POST /oauth/register (RFC 7591 Dynamic Client Registration) → client_id |
| 3. Autorizar | GET /oauth/authorize?… — el propietario inicia sesión en Crisphive y da su consentimiento |
| 4. Intercambiar | POST /oauth/token (grant_type=authorization_code, code, code_verifier) → { access_token, refresh_token, expires_in } |
| 5. Refrescar | POST /oauth/token (grant_type=refresh_token) → un par de tokens rotado (el refresh token anterior es de un solo uso) |
Tokens
El token está vinculado al negocio, la región y el entorno del propietario que dio su consentimiento — nunca puede alcanzar otro tenant ni cambiar entre live↔sandbox. El token actúa como la persona que lo aprobó: cada llamada se verifica contra el rol actual de ese miembro, de modo que la aplicación nunca puede hacer más de lo que esa persona podría hacer en el panel, y deja de funcionar si se la elimina o suspende. Solicite un scope más restringido (códigos de permiso separados por espacios, p. ej. customers_view job_view) para limitarlo aún más; omitirlo significa todo lo que ese miembro puede hacer. Un scope que el miembro no tiene se rechaza en el consentimiento. Los access tokens duran ~1 hora; refresque con el refresh token de un solo uso para seguir conectado.
Duración de la conexión
Una conexión se rige por dos relojes independientes. Una integración en uso diario nunca se desconecta de forma programada; una que queda olvidada expira por sí sola.
- Ventana de inactividad — 30 días. Cada refresco de token emite un nuevo refresh token válido por otros 30 días. Siga usando la conexión y se prorroga indefinidamente; permanezca inactivo 30 días y caduca.
- Tope absoluto — 90 días. Independientemente de la actividad, una conexión termina 90 días después de que el propietario del negocio la aprobó. El negocio puede fijarlo en cualquier valor de 1 a 365 días por conexión en Developers → MCP connections; la cuenta atrás se mide desde la aprobación original, no desde el cambio.
Cuando cualquiera de los dos relojes se agota, el refresco falla (OAUTH_GRANT_EXPIRED) y el propietario debe aprobar la aplicación de nuevo desde la pantalla de consentimiento. Trate cualquier refresco fallido como «reiniciar el flujo de autorización», nunca como un error reintentable. Los Propietarios y Administradores del negocio reciben un correo 14 días antes de que una conexión expire — volver a aprobar requiere al propietario en un navegador, por lo que el aviso llega antes que en el caso de las claves.
Llamar a la API
curl "https://api.crisphive.com/v1/customers" \ -H "Authorization: Bearer <access_token>"
¿Está construyendo un conector de agentes de IA? El servidor MCP usa exactamente este flujo — los clientes MCP conformes lo ejecutan automáticamente, así que normalmente no escribe ningún código OAuth.