Credenciales

Toda request a la API de BehaviorOS requiere una API key. La genera tu propio equipo desde el Control Center — ver Configuración; esta página cubre cómo usarla desde tu código.

La URL del ambiente te la entrega tu administrador, junto con el acceso al Control Center donde se genera la key. Si todavía no la tenés, pedila antes de empezar.

Usar la key

Incluí la key en el header Authorization con el prefijo Bearer:

GET /some-endpoint
Host: <tu-url-de-sandbox>
Authorization: Bearer <YOUR_API_KEY>
Content-Type: application/json

Con curl:

curl https://<tu-url-de-sandbox>/some-endpoint \
  -H "Authorization: Bearer YOUR_API_KEY"

La key identifica a tu tenant: no hace falta enviar ningún identificador de cliente en los requests.

Verificar que funciona

La forma más rápida es desde el Playground:

Abrí el Playground y pegá tu key en la solapa de autenticación.
Ejecutá cualquier endpoint de lectura.
Si la respuesta es 200 con datos, estás listo. Si recibís 401 o 403, ver los dos 403.

Buenas prácticas

Práctica	Por qué
Una key por consumidor	Una rotación no obliga a cambiar todos los sistemas al mismo tiempo, y el uso queda atribuido.
Credenciales separadas por ambiente	Las de sandbox no operan en producción.
Nunca en la app	Una credencial distribuida en un binario móvil es una credencial pública. Si la app necesita leer el progreso, el llamado sale de tu backend.
Vigencia limitada	Cada credencial se puede emitir con fecha de expiración, que se valida en cada llamada.

Rotar sin corte

Como las keys son independientes entre sí, una rotación no requiere ventana de mantenimiento:

Generá la key nueva desde el Control Center.
Desplegá el cambio en el consumidor que corresponda.
Confirmado el tráfico con la key nueva, pausá la vieja — así verificás que nada quedó atrás sin perderla todavía.
Si nada se rompe, eliminala.

Tener una key por consumidor es lo que hace que este procedimiento afecte a un solo sistema por vez.

Capa opcional: TLS mutuo (mTLS)

Para organizaciones cuya política de seguridad lo exige, la API acepta TLS mutuo: además del cifrado del canal, presentás tu propio certificado durante el handshake y la plataforma lo valida antes de procesar el request.

Se habilita por organización y no reemplaza a la credencial: opera sobre ella, como segunda capa independiente.


Certificado anclado a la organización	UIN registra tu certificado y queda vinculado a tu tenant por huella SHA-256. Un certificado válido de otro cliente no habilita el acceso a tus datos.
Validación en cada request	Se verifica que esté registrado, habilitado, no revocado y dentro de su ventana de vigencia.
Rotación sin corte	El certificado nuevo se registra junto al vigente y ambos operan durante la ventana de solapamiento.
Revocación inmediata	Cortar el acceso es instantáneo, con independencia de la credencial de API.
Host dedicado	El tráfico con mTLS entra por un host propio, separado del que sirve el Control Center.

Si tu organización tiene mTLS activo, cualquier endpoint responde 403 mientras no presentes un certificado válido y anclado a tu tenant — no solo los endpoints sensibles.

El alta, la rotación y la revocación del certificado las hace UIN por el canal de soporte; a diferencia de las API keys, no se administran desde el Control Center.

Qué sigue

Con la key funcionando, podés conectar el asistente para que te acompañe en el resto: Conectar el asistente. Es opcional; si preferís seguir a mano, el paso siguiente es Identificar usuarios.