Autenticación
Toda petición, salvo la verificación pública de sellos, lleva una llave de API en la cabecera Authorization:
Authorization: Bearer dtr_live_XXXXXXXXXXXXXXXXXXXXXXXXXXXXDónde se crea
En la consola, en Integraciones › API, o por la propia API con POST /api-keys. El secreto se muestra una sola vez, al crear y al rotar; nosotros guardamos sólo su huella. Si lo pierdes, rota la llave: el secreto anterior deja de servir en el acto.
Los dos tipos de llave
| Prefijo | Ambiente | Vence | Puede |
|---|---|---|---|
dtr_live_ | Producción | A los 90 días por defecto; se puede fijar entre 1 y 365 días, o nunca. | Leer y escribir según sus permisos. |
dtr_test_ | Prueba | Nunca. | Leer todo. Escribir sólo donde existe un modo de prueba; en el resto responde 403 not_available_in_test_mode. |
Sobre el sandbox. Hoy no hay un ambiente de pruebas aparte: las llaves de prueba leen datos reales de tu empresa y no escriben. El sandbox con su propia base llega con la migración de infraestructura; hasta entonces, prueba las escrituras con una llave de producción sobre una empresa de pruebas.
Qué pasa cuando falla
401 unauthorized: falta la cabecera, la llave no tiene la formadtr_live_…/dtr_test_…, fue revocada o venció.403 forbidden: la llave existe pero no tiene el permiso que pide la operación. Ver permisos.403 module_disabled: tu empresa no tiene habilitada la plataforma de cumplimiento.
Buenas prácticas
- Una llave por integración, con el nombre del sistema que la usa. Así la bitácora dice quién hizo qué.
- Guarda la llave en tu gestor de secretos, nunca en el código ni en el repositorio.
- Programa la rotación antes del vencimiento:
POST /api-keys/{id}/rotatedevuelve el secreto nuevo y la fecha.