Skip to main content

​
Autenticación

Orbit autentica las solicitudes de API de dos maneras: una clave de API para llamadas de servidor a servidor, y un token Bearer de sesión para los usuarios del panel. Las organizaciones empresariales pueden, además, iniciar sesión de sus usuarios mediante el inicio de sesión único SAML y aprovisionarlos mediante SCIM. Elige el método que se ajuste a cómo se realiza la solicitud.

​
Clave de API (servidor a servidor)

Incluye tu clave de API en el encabezado X-API-Key:

​
Token Bearer (usuarios del panel)

Para los usuarios del panel, utiliza tokens Bearer JWT:
También puedes pasar una clave de API mediante Authorization: Bearer dv_live_pk_... (cualquier clave dv_ — dv_live_sk_, dv_test_sk_, dv_live_pk_, dv_test_pk_) en entornos donde el encabezado personalizado X-API-Key está bloqueado por CORS. El servidor acepta ambas formas: lee primero X-API-Key y luego recurre a un token Bearer que lleva un prefijo dv_. Un JWT (que comienza con eyJ) sigue tratándose como un token de sesión del panel, de modo que ambos nunca entran en conflicto.

​
Formato de las claves de API

Una clave pública (dv_live_pk_ / dv_test_pk_) está pensada para integrarse en código del lado del cliente, por lo que está restringida a alcances de solo lectura al crearse. Los alcances de escritura y administrativos — messages:write, contacts:write, admin, el comodín * y las lecturas sensibles de la cuenta billing:read / settings:read — se rechazan para una clave pública con un 422. Usa una clave secreta (dv_live_sk_) para cualquier operación que envíe o modifique datos.Aun así, trata cualquier clave que envíes a un navegador o a un paquete móvil como visible públicamente y limítala a las lecturas mínimas que necesite.

​
Inicio de sesión único (SAML)

Las organizaciones empresariales pueden iniciar sesión de los usuarios del panel a través de un proveedor de identidad SAML 2.0 — Okta, Microsoft Entra ID (anteriormente Azure AD), OneLogin, Google Workspace o PingFederate. El SSO autentica a las personas en el panel; no genera claves de API, por lo que las llamadas de servidor a servidor siguen usando los métodos anteriores. Un propietario configura la conexión en Configuración → Inicio de sesión único dentro del panel (o mediante PATCH /api/v1/settings/saml): define la URL de SSO, el ID de entidad y el certificado de firma de tu IdP y, a continuación, usa Probar conexión antes de activarla. Cada organización obtiene su propio conjunto de endpoints, identificados por el slug de tu organización (orgSlug). Se encuentran en la raíz de la API, no bajo /api/v1: Apunta tu IdP al endpoint de metadatos, por ejemplo https://api.orbit.devotel.io/auth/saml/acme/metadata para la organización acme.

​
Aprovisionamiento de directorio (SCIM)

Aprovisiona y desaprovisiona usuarios del panel automáticamente desde tu proveedor de identidad a través de SCIM 2.0. Genera un token de aprovisionamiento en Configuración → SCIM (o mediante POST /api/v1/settings/scim/generate-token): el token se muestra solo una vez, así que cópialo en tu IdP de inmediato. Tu IdP envía el token como una credencial Bearer en cada solicitud:
Los endpoints siguen la especificación SCIM 2.0 y devuelven application/scim+json. Se identifican por el slug de tu organización y se encuentran en la raíz de la API, no bajo /api/v1:
SAML y SCIM son independientes: el SSO controla cómo inician sesión los usuarios, SCIM controla qué usuarios existen. Puedes activar cualquiera de ellos por separado, aunque la mayoría de los IdP configuran ambos juntos.
Para la guía completa de aprovisionamiento — construcción de la URL base, asignación de roles, comprobaciones de estado del IdP y pasos para Okta / Entra / cliente genérico — consulta la guía de aprovisionamiento SCIM 2.0.