Skip to main content

El recorrido completo

1

Verifique conectividad y credenciales

/version no exige api-key, así que separa un problema de red (falla /version) de uno de credenciales (falla solo /front con 401). Evalúe el código de estado, no el cuerpo.
2

Prepare la imagen del frente

Foto del documento completo, apoyado, sin reflejos, en base64 sin prefijo y de al menos 480 × 480 píxeles.
3

Llame a POST /front y guarde el uuid

El uuid de la respuesta es el enganche con el dorso y el dato que soporte necesita. Guárdelo siempre.
4

Si hasBackSide es true, llame a POST /back

Con la foto del dorso y el uuid del frente como relatedUuid.
5

Aplique la regla de decisión

200 + "Operation end successfully." + id identificado — y en el dorso, frontBackTemplateValidation === true.

Cuerpo de la solicitud

Nunca envíe relatedUuid en /front. Ese campo es exclusivo de /back; incluirlo en /front produce un error 500 del servicio, no un 4xx descriptivo. Y a pesar de lo que sugiere el mensaje de error de /back, lo único que satisface el requisito es el uuid de un /front previo — documentId no lo reemplaza.

Requisitos de la imagen

Convertir a base64

El enganche frente → dorso

Si el dorso viaja inmediatamente después del frente, un 400 Bad relatedUuid ocasional puede significar que el registro del frente aún no estaba disponible. Espere unos segundos y reintente una sola vez antes de tratarlo como error definitivo.

El catálogo de templates

Los campos que trae viz varían por tipo de documento. La referencia autoritativa es el propio catálogo del servicio:
Consulte /details en tiempo de integración para saber qué campos programar por documento, y pruebe con las imágenes de /images antes de usar documentos reales. Si su flujo es «DNI argentino», envíe documentId o possibleCountries: acota la inferencia, la acelera y elimina falsas identificaciones.

Timeouts y reintentos

Las respuestas son pesadas — alrededor de 1 MB. La imagen normalizada del documento y el recorte del rostro viajan siempre en los 200. Dimensione buffers y no persista respuestas completas sin necesidad.

Antes de salir a producción

Una integración está lista cuando puede responder que sí a todo esto:
  1. La decisión está escrita en positivo: 200 y message: "Operation end successfully." y id !== "unknown" — y en el dorso, frontBackTemplateValidation === true.
  2. Probó la foto sin documento y su sistema pide otra captura en vez de aceptar campos vacíos.
  3. Probó el dorso de otro documento y su sistema lo rechaza.
  4. relatedUuid solo se envía en /back, y siempre con el uuid de un 200 de /front — nunca el de un cuerpo de error.
  5. Las capturas cumplen 480 × 480 y el base64 va sin prefijo data: y sin saltos de línea.
  6. Los logs no persisten cuerpos de error crudos —el detail de los 422 contiene la solicitud completa, imagen incluida— ni respuestas completas con imágenes.
  7. El timeout está en 30 s y los reintentos limitados a 2, solo para 5xx esporádicos.
  8. El uuid de cada transacción queda en su log, junto con el ambiente y la marca de tiempo.
  9. La api-key vive solo en el backend y está en un gestor de secretos, no en el código.
  10. El equipo sabe que 200 Cant get document fields es un problema de captura, no un bug.

Respuestas

El siguiente paso: la estructura de front y back, las validaciones cruzadas y los dos 200 que no aprueban.
Última modificación el 9 de septiembre de 2026