Práctica de envío, callbacks y búsqueda de registros con escenarios sintéticos de sandbox
Los ingenieros de backend que integran comprobaciones de onboarding de identidad o registro necesitan una forma de ejercitar la ruta del callback, persistir el estado pendiente y buscar el registro resultante antes de que cualquier persona real envíe documentos. El sandbox proporciona escenarios sintéticos que simulan el flujo completo sin crear una sesión de verificación en vivo. Este artículo recorre el flujo de trabajo documentado a partir de las instrucciones de operación publicadas: iniciar sesión como comerciante, enviar una comprobación sintética, manejar los diferentes comportamientos para escenarios de teléfono e identidad, simular resultados para comprobaciones de identidad y localizar el registro para inspeccionar el uso de prueba. Cada paso descrito aquí proviene del documento de ayuda oficial; no hay llamadas a proveedores en vivo, aprobaciones de identidad reales ni permisos de producción involucrados.
curl -I https://gridzen.ai/help/sandbox/Requisitos previos y punto de entrada
El flujo de trabajo documentado comienza con un único requisito previo: iniciar sesión como comerciante y utilizar solo los escenarios sintéticos suministrados. El punto de entrada es la ruta de consola /console/#/verify. No es una prueba genérica de onboarding; es un entorno de operación específico y publicado donde el contexto del comerciante y los filtros de entorno determinan si aparece un registro. Si no aparece ningún registro, la guía de solución de problemas indica comprobar el comerciante, el entorno y los filtros manteniendo el ID original. No se describe la creación de cuentas, el aprovisionamiento de claves API ni la activación de servicios en vivo en este documento. El sandbox es explícitamente un entorno de práctica, y el documento establece que un resultado simulado no es una aprobación de identidad en vivo.
Iniciar una verificación sintética
Desde el punto de entrada, elija Nueva verificación. Seleccione teléfono o identidad como tipo de comprobación, luego elija uno de los escenarios sintéticos suministrados y envíe una vez. El documento indica que aparece un registro con un ID inmediatamente después del envío. Para escenarios de teléfono, las señales sintéticas normalmente se devuelven directamente en esta etapa. Para escenarios de identidad, el estado inicial es pendiente y requiere un paso de simulación adicional. El ID que aparece es la referencia clave para el resto del flujo de trabajo; la sección de solución de problemas enfatiza mantener el ID original mientras se espera o investiga. No se documenta aquí ninguna configuración de endpoint de callback, registro de webhook ni solicitud de red a un proveedor. El envío es una acción de consola que crea un registro sintético.
Comportamiento del escenario de teléfono
Cuando se envía un escenario sintético de teléfono, el documento establece que las señales sintéticas normalmente se devuelven directamente. Esto significa que el registro pasa del envío a un estado sintético completado sin más interacción en la consola. El ID del registro sigue siendo el ancla para la búsqueda posterior. El documento no describe ninguna acción de simulación, sondeo o espera de callback para escenarios de teléfono. Tampoco especifica qué contienen las señales sintéticas, solo que se devuelven directamente. Este comportamiento contrasta con los escenarios de identidad, que requieren un paso de simulación explícito. Los ingenieros no deben asumir que los escenarios de teléfono ejercitan una ruta de callback; son una ruta sintética más simple que devuelve señales inmediatamente en el registro de la consola.
Simulación del escenario de identidad
Para escenarios sintéticos de identidad, el flujo de trabajo diverge. Después del envío, el registro muestra un estado pendiente. Los pasos documentados son: abrir el registro, usar su acción de simulación y luego actualizar el mismo registro. El resultado simulado seleccionado reemplaza el estado pendiente. El documento instruye mantener el ID mientras se espera. Esta acción de simulación es una operación de consola, no un callback de un proveedor externo. No se describe ninguna entrega de webhook, verificación de firma ni sondeo de proveedor. La simulación reemplaza pendiente con un resultado sintético como Aprobado o Rechazado, pero la declaración de finalización deja claro que este resultado simulado no es una aprobación de identidad en vivo. El registro ahora contiene un resultado sintético que puede inspeccionarse como cualquier otro registro.
Localización e inspección del registro
Después del envío (y simulación para identidad), el siguiente paso documentado es abrir Registros, localizar el ID y luego inspeccionar el uso de prueba en Uso y facturación. El documento establece que las vistas de lista y detalle muestran el mismo registro, etiquetado como sandbox o sintético. Este etiquetado es el indicador visual de que el registro pertenece a una ejecución de práctica. La inspección del uso de prueba en Uso y facturación es la comprobación de finalización documentada. No se describe ninguna llamada API para recuperar el registro, ningún filtrado programático ni función de exportación. El flujo de trabajo es completamente basado en consola: enviar, simular opcionalmente, luego encontrar el registro en la vista Registros y examinar sus metadatos de uso. El ID original mantenido desde el envío es la clave de búsqueda.
Comprensión de los resultados sintéticos
La declaración de finalización en el documento es explícita: reabra el registro y reconozca que un resultado simulado no es una aprobación de identidad en vivo. Este es el límite crítico para los ingenieros. El sandbox ejercita el ciclo de vida del registro, el seguimiento del ID, la navegación de la consola y el etiquetado de uso. No ejercita un callback de proveedor en vivo, una notificación firmada, una recuperación autoritativa ni una concesión de permiso real. La nota de solución de problemas refuerza que si no aparece ningún registro, el problema es la configuración del comerciante, el entorno o los filtros, no un fallo del proveedor. El escenario sintético es un ensayo del flujo de trabajo de la consola y la búsqueda de registros, no una verificación de una persona real. Cualquier código de integración que dependa del manejo de callbacks, la persistencia de estado entre reinicios o la aplicación de plazos debe probarse por separado usando los ejemplos sintéticos que modelan explícitamente esos comportamientos.
Revisar el flujo documentado
https://gridzen.ai/help/sandbox/ · Revisa requisitos, permisos, pasos y comprobación. El artículo no verifica ni activa servicios.
Fuentes y alcance
https://gridzen.ai/help/sandbox/ https://gridzen.ai/guides/current-capabilities/ Basado en instrucciones publicadas; no se ejecutó una verificación real ni se comprobó disponibilidad del proveedor. Redacción asistida por IA y revisión independiente.
Probar por separado tres resultados del sandbox Crear una cuenta para continuar la integración
Una descarga no demuestra una ejecución correcta. Los ejemplos locales y el sandbox en línea se prueban por separado.