Sandbox y Datos de Prueba

El sandbox es una copia completa del pipeline de verificación con sus propias credenciales y sus propios datos. Úselo para construir y validar su integración antes de que un cliente real la utilice.

Acceso

Las credenciales de sandbox y de producción nunca son intercambiables, y una verificación en sandbox nunca es una base válida para una decisión real de onboarding.

El Sandbox Ejecuta Verificación Real

El sandbox realiza análisis real de documentos — el mismo pipeline de extracción, autenticidad, prueba de vida y coincidencia facial que producción. Ningún número de documento de prueba produce un resultado de verificación predefinido como ocurre con los números de tarjeta de prueba en pagos: aprobación, rechazo y revisión provienen todos de las imágenes que usted envía.

La única excepción es la verificación de formato del número de documento, que sí acepta valores reservados — consulte Números de Documento de Prueba Reservados. Verifica la forma de un número declarado y nunca mira una imagen, por lo que es una superficie separada del pipeline de verificación descrito aquí.

La consecuencia práctica: pruebe con documentos reales que usted controle personalmente, o con documentos emitidos para pruebas. Una verificación fallará genuinamente si la imagen está borrosa, el documento está vencido o la selfie no coincide — que es exactamente lo que hace útil al sandbox para probar su manejo de errores.

Cada resultado incluye un campo provider. "inyo" significa que lo produjo un análisis real. "inyo-mock" significa que lo produjo un simulador — lo cual nunca ocurre en producción, y le indica sin ambigüedad que un resultado no provino de una verificación real.

Cómo Generar Cada Resultado

Solicite un tenant de sandbox adicional si necesita configuraciones en conflicto. El enrutamiento a revisión y los rechazos retenidos son configuraciones a nivel de tenant, por lo que ejercitar tanto un rechazo normal como un rechazo retenido implica cambiar la configuración entre ejecuciones — o tener dos tenants de sandbox.

Pruebas Sin Cámara

El validador de formato de número de documento no necesita imágenes y no consume ninguna verificación, lo que lo convierte en lo más rápido para integrar primero:

curl --request POST \
  --url https://{FQDN}/v1/validators/document-number \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"documentType": "drivers_license", "number": "not-a-number", "issuingCountry": "USA", "issuingState": "PA"}'

{
  "documentType": "drivers_license",
  "issuingCountry": "USA",
  "issuingState": "PA",
  "valid": false,
  "rule": "dl:USA:PA",
  "detail": "document number does not match the PA license format"
}

Úselo para confirmar su manejo de los tres estados — true, false y null para una jurisdicción desconocida. Consulte Validador de Número de Documento.

Números de Documento de Prueba Reservados

La verificación de formato del número de documento acepta un pequeño conjunto de valores reservados que devuelven el veredicto elegido bajo demanda. Úselos cuando necesite un resultado valid específico — habitualmente desde la creación de remitente de remesas, que ejecuta esta verificación sobre todo documento declarado — sin tener que aprender antes el formato real de numeración de una jurisdicción.

Solo en sandbox. Estos valores se habilitan por entorno; si los valores de abajo devuelven un veredicto ordinario, pida a su contacto de Inyo que los habilite en su tenant de sandbox.

Todo tipo capturable publica los tres estados de valid, así que puede ejercitar su propio manejo por tipo sin aprender el formato real de numeración de una jurisdicción. ssn e itin traen solo un valor de aprobación — vea más abajo.

Las filas de identity_card son mexicanas porque no existe una regla para cédulas de identidad de EE. UU. — un valor estadounidense sería un caso de prueba para una verificación que no existe. La CURP codifica el nombre y la fecha de nacimiento del titular, así que el campo de nombre todo en X es estructuralmente válido y no puede colisionar con una persona real.

Envíe cada número con el issuingCountry y el issuingState indicados. Un valor reservado se reconoce por ese par exacto, por lo que el mismo número bajo cualquier otra jurisdicción se valida con las reglas ordinarias.

curl --request POST \
  --url https://{FQDN}/v1/validators/document-number \
  --header "Authorization: Bearer $ACCESS_TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{"documentType": "drivers_license", "number": "99900002", "issuingCountry": "USA", "issuingState": "PA"}'

{
  "documentType": "drivers_license",
  "issuingCountry": "USA",
  "issuingState": "PA",
  "valid": false,
  "rule": "reserved:drivers_license:PA:invalid",
  "detail": "reserved sandbox test value — simulated invalid verdict"
}

Un resultado simulado lleva la cabecera de respuesta X-Inyo-Simulated: true. Está presente solo cuando un valor reservado produjo el resultado, y ausente en caso contrario — incluso en producción, donde nunca aparece.

Los valores reservados son números reales y válidos en el formato de su jurisdicción. Esto es deliberado: significa que una regla de formato previa — como la que la creación de remitente de remesas aplica antes de llamar a esta verificación — deja pasar el valor en lugar de rechazarlo antes, que es justamente lo que permite que 99900002 llegue hasta nosotros y vuelva como false.

La consecuencia es que donde los valores reservados no están habilitados, devuelven el veredicto que les dan las reglas reales de formato — valid: true para todos los valores excepto el ITIN, que devuelve false. Un valor reservado nunca produce un resultado más estricto que un número ordinario, así que dejar uno en el código no es un riesgo de seguridad — pero deja de simular en silencio, así que no lleve ninguno a producción.

912891234 es el único valor que devuelve false con la simulación desactivada. No existe un espécimen de ITIN anulado como lo es 078-05-1120 para los SSN, así que proviene de un grupo que el IRS reserva para otros programas — la única forma de garantizar que nunca pertenecerá a una persona real. El costo es que una regla de formato previa más estricta puede rechazarlo antes de que llegue a esta verificación. Si eso ocurre de su lado, úselo directamente contra este endpoint en lugar de pasar por un llamador que pre-valida.

Pruebas de Entrega de Resultados

La entrega merece probarse por sí sola, independientemente de los resultados de verificación:

1. Verificación de firma — capture el cuerpo de un webhook real de sandbox y su X-Inyo-Signature, luego pruebe unitariamente su verificador contra esos bytes exactos. Agregue un caso que mute un byte del cuerpo y verifique el rechazo, y un caso que re-serialice el JSON parseado y verifique el rechazo. Esos dos casos detectan el error que rompe la mayoría de las integraciones. Después agregue tres que detectan los que solo encontrará más adelante: un t= vencido, fuera de su tolerancia; un encabezado que trae un v2= extra que su código no implementa (debe validar igual con v1); y un encabezado que repite v1= dos veces (debe rechazarse de plano, no resolverse eligiendo uno).
2. Comportamiento de reintentos — devuelva 500 desde su endpoint y confirme que ve hasta tres intentos, y luego nada.
3. Ordenamiento — reproduzca dos notificaciones almacenadas de una sesión fuera de orden y verifique que su handler conserva la que tiene el notifiedAt más alto.
4. Idempotencia — entregue el mismo resultado dos veces y verifique que su sistema no lo procesa por duplicado.

Los pasos 1, 3 y 4 no requieren ninguna llamada al sandbox una vez que haya capturado un payload real.

Antes de Salir a Producción

Próximos Pasos

• Primeros Pasos — el recorrido de extremo a extremo
• Recepción de Resultados — firmas, reintentos y ordenamiento