Aislamiento por empresa
La empresa la determina la clave, no la petición. No hay forma de pedir datos de otra.
Cómo se resuelve la empresa
Cada clave pertenece a una empresa. Cuando llega una petición, la plataforma busca la clave por su hash, obtiene la empresa a la que pertenece y ejecuta la consulta acotada a esa empresa. Ese identificador nunca viene de la petición.
Por eso no encontrarás un parámetro tenantId en ningún endpoint. Si lo envías, se ignora: aceptarlo sería exactamente el agujero que este diseño evita.
http
POST /api/tx-monitor/ingest
x-tenant-api-key: grc_... ← de aquí sale la empresa
{ "tenantId": "otra-empresa" } ← esto no hace nadaQué pasa si pides un recurso de otra empresa
Devuelve 404, no 403. Un 403 confirmaría que ese identificador existe en alguna parte, y eso ya es información sobre datos ajenos. Desde fuera, un recurso de otra empresa y un recurso inexistente son indistinguibles.
Cómo está implementado hoy
Cada consulta se ejecuta dentro de una transacción que fija la empresa en la sesión de base de datos, y además lleva el filtro por empresa escrito de forma explícita en la consulta.
El aislamiento lo impone el código, todavía no la base
La plataforma deja preparada la variable de sesión que usarían las políticas de seguridad a nivel de fila de PostgreSQL, pero esas políticas aún no están activadas. Es decir: hoy el aislamiento depende de que cada consulta lleve su filtro, y hay pruebas automáticas que lo comprueban, no de que el motor lo impida por su cuenta.
Se dice aquí porque cambia el perfil de riesgo que tu organización tiene que evaluar, y porque cuando esas políticas se activen esta página dirá otra cosa.
Permisos dentro de tu propia empresa
Estar en la empresa correcta no basta. Cada endpoint comprueba además el permiso concreto de la operación —leer contrapartes no es lo mismo que aprobarlas—, y una clave de API opera con los permisos del usuario que la creó.
Consecuencia práctica: si creas la clave con un usuario de permisos limitados, la integración hereda ese límite. Es la forma recomendada de crearlas.
Datos de salud
Los exámenes ocupacionales, las restricciones médicas y los casos de convivencia laboral son datos sensibles bajo la Ley 1581/2012. Exigen un permiso propio y específico, que no se concede por tener un rol amplio, y cada lectura queda registrada con quién la hizo. Una clave de API creada por un usuario sin ese permiso no los alcanza.
Lo que tu integración debe hacer por su lado
La plataforma te entrega solo tus datos; qué haces con ellos después ya no lo controla. Si los replicas en un almacén tuyo, el aislamiento entre empresas dentro de ese almacén es responsabilidad de tu organización, y sigue siendo tu empresa quien responde ante el titular de esos datos.
Ver también Seguridad.