Autenticación y permisos

Todos los endpoints de verificación (REST y SOAP) requieren una API key por institución.

Cómo enviar tu API key

Protocolo	Cómo se envía
REST	Header `X-API-Key: TU_API_KEY`
SOAP	Elemento `<apiKey>` dentro del body, o header HTTP `X-API-Key`

Si la key es inválida o falta:

REST responde 403 Forbidden.
SOAP responde un <soap:Fault> con faultcode = soap:Client.AuthenticationFailed.

Permisos por institución (entitlements)

Cada institución tiene una configuración que controla qué puede hacer su API key:


{
  "allowed_protocols": ["rest", "soap"],
  "blockchain_enabled": true,
  "allowed_document_types": ["*"]
}

allowed_protocols — rest, soap, o ambos. Si tu key solo tiene habilitado SOAP, una llamada REST responde 403 (y viceversa, un fault Client.Forbidden en SOAP).
blockchain_enabled — si es false, tus verificaciones no se registran en blockchain. El resto del pipeline (OCR, verificadores, detección de fraude) no cambia.
allowed_document_types — ["*"] habilita todos los tipos, o puedes restringir a una lista específica (ej. ["ine", "curp"]). Esto aplica también cuando usas verificación automática (auto): si el tipo detectado no está en tu lista, la verificación se rechaza.

Las instituciones nuevas empiezan con la configuración permisiva por default (todos los protocolos, todos los tipos de documento, blockchain habilitado). Contáctanos si necesitas restringir algo para tu integración.

Buenas prácticas

No incluyas tu API key en código de cliente/frontend — solo en tu backend.
Usa una API key distinta por ambiente (pruebas vs. producción) si tu integración lo permite.
Registra el verificationId/folio de cada respuesta junto con tu propio identificador (clientReferenceId) para poder darle seguimiento.