Cada capacidad del framework está pensada para resolver un punto concreto del flujo de verificación. No son piezas decorativas: son componentes que se conectan a tu esquema de datos y responden en el tiempo que exige tu operación.
El SDK expone un parámetro de tolerancia que ajustas según el riesgo de tu contexto. Para un acceso administrativo usas un umbral estricto; para validación de clientes, uno más permisivo. La decisión queda en tu código, no en una caja negra.
El módulo compara la imagen capturada contra el registro en la base de datos del emisor. El resultado incluye el nivel de confianza por campo, de modo que sepas si falló el número, la fecha o la foto antes de decidir el siguiente paso.
Cuando necesitas depurar una base existente, el API procesa listas de registros y devuelve duplicados probables con su puntaje. Útil para limpiar datos heredados o detectar cuentas duplicadas sin bloquear el alta en tiempo real.
El framework registra cada llamada con un identificador de traza. Si un operador reporta una falla, el log te lleva al request exacto y al motivo del rechazo, sin revisar miles de líneas.
Para ver el detalle de implementación por escenario, revisa los casos de uso o la guía de inicio.
Elegí el nivel de control que necesita tu equipo. Los tres esquemas comparten el mismo núcleo de verificación; cambia la profundidad de personalización y el soporte operativo.
Acceso directo a los endpoints de verificación de identidad. Pensado para equipos que ya tienen su propia capa de orquestación y solo necesitan el motor de reconocimiento.
Librerías para cliente que capturan y preprocesan la imagen antes de enviarla al servidor. Reduce la carga de tu backend y mejora la tasa de éxito en dispositivos de gama media.
El motor completo corre en tu infraestructura. Los datos biométricos no salen de tu red; la comunicación con el servicio central se limita a actualizaciones de modelos.
¿No sabés cuál se adapta a tu stack? La decisión depende del volumen de verificaciones y de dónde querés que viva el dato biométrico. Revisá los casos de uso típicos para orientarte.
Las notas que siguen provienen de ingenieros que trabajaron con la API de identificación en entornos de producción. No son promesas comerciales, sino observaciones concretas sobre tiempos de respuesta, manejo de errores y comportamiento bajo carga.
El equipo de una plataforma de servicios financieros ajustó los umbrales de similitud para su caso de uso y pasó de un 4,2 % a un 1,1 % de falsos rechazos. El cambio se hizo desde el panel de configuración, sin tocar el código del cliente.
Un cliente que verifica identidades en una app de movilidad urbana midió una latencia p95 de 280 ms durante tres semanas consecutivas. El dato más útil fue la distribución de tiempos por región, que permitió decidir dónde ubicar el siguiente nodo de caché.
La documentación sobre idempotencia fue lo que destrabó la integración en un sistema de reservas. Con el header de solicitud repetida, el backend dejó de registrar verificaciones duplicadas cuando el cliente perdía la conexión a mitad de la petición.