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, los clientes son públicos (sin secreto) y el registro es dinámico — sin revisión manual de aplicaciones:
| 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. Solicite un scope más restringido (códigos de permiso separados por espacios, p. ej. customers_view job_requests_view) para limitar el acceso; omítalo para acceso completo al negocio. 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.