El simulador desde su consola
El simulador se puede usar entero por HTTP, sin abrir un navegador — eso está en El simulador como API. La consola es la otra mitad: una interfaz web que sirve para ver lo que tu integración ya probó y lo que le falta.
No es un panel de administración ni un sustituto de tu código. Es un espejo con memoria: tú integras desde tu editor, y la consola te va diciendo, con la evidencia en la mano, hasta dónde has llegado de verdad.
Vive en la raíz del simulador —https://sim-productos.abiertolab.com, sin más ruta— y entras con el token de consola que te dio POST /console/register. La dirección vieja, /console, sigue funcionando y redirige → Credenciales.
Todo lo que ves aquí sale de endpoints que puedes llamar tú (GET /console/trace, GET /console/sessions, GET /console/progress). Si prefieres automatizar, no pierdes nada.
Cómo está montada
La pantalla tiene tres zonas fijas, y esa disposición es el mensaje:
| Zona | Dónde | Qué hay |
|---|---|---|
| El rail | Franja izquierda | Las nueve prácticas y los cinco casos borde, con su estado |
| El área de trabajo | Centro | El taller de la práctica en la que estés, o la herramienta que hayas abierto |
| La traza | Panel derecho | Los eventos de tu cuenta, en vivo, siempre visible |
La traza no es una pantalla aparte a la que se va: está a la derecha todo el rato, mientras trabajas. Antes sí era una vista propia, y se cambió a propósito — mirar lo que pasó no es una tarea distinta de integrar, es parte de integrar. El divisor entre el centro y la traza se arrastra para darle más o menos ancho, y también responde a las flechas del teclado cuando tiene el foco. Lo que elijas se recuerda.
Las nueve prácticas
El rail es la columna vertebral. Cada práctica es una cosa concreta que tu integración tiene que haber hecho:
| # | Práctica | Qué prueba |
|---|---|---|
| 1 | Conectado | Que tu código haga su primera llamada autenticada |
| 2 | Acuerdo creado | El acuerdo es la configuración que reutilizas; no se crea uno por pago |
| 3 | Sesión abierta | Crear la sesión y ver que devuelve una URL para quien paga |
| 4 | Pago recibido | El pago ocurre fuera de tu app y vuelve a ti por webhook |
| 5 | Tu endpoint contestó | El salto de los webhooks de prueba a tu propio servidor |
| 6 | Firma verificada | Que tu endpoint rechaza lo que no viene firmado por SPIDI |
| 7 | Acreditación | La fase 2: el dinero acreditado, no solo el pago hecho |
| 8 | Casos borde | Probar lo que rompe: duplicados, reintentos, fallos y expiración |
| 9 | Listo para producción | Todo lo anterior, probado con evidencia y no de memoria |
Cada uno tiene su taller en el área de trabajo: qué es, por qué importa, el código que lo consigue, y qué mirar en la traza cuando ocurra.
Se marcan solos, y no hay forma de marcarlos a mano
Esto es lo que separa a esta consola de una lista de tareas. No hay una casilla que puedas marcar tú. Cada práctica se enciende cuando el simulador observa el evento que la prueba:
| Práctica | Lo que el simulador tiene que ver |
|---|---|
| Conectado | Cualquier respuesta 2xx de la API |
| Acuerdo creado | Un 2xx en POST /api/v1/ext/agreements |
| Sesión abierta | Un 2xx creando una sesión de Botón o un lote de Solicitud |
| Pago recibido | La transición real de la sesión a paid |
| Tu endpoint contestó | Un webhook entregado con routing direct o relay |
| Firma verificada | Que tu endpoint rechace un reto de firma corrupta |
| Acreditación | La transición de la fase 2 a accredited |
loopbackEs la regla más importante de todo el rail. Si tu webhook_url apunta a los receptores de prueba del propio simulador, el 2xx lo produce el simulador contestándose a sí mismo: no prueba nada sobre tu servidor. Esa práctica exige direct o relay, y por eso puede quedarse apagada aunque veas entregas verdes en la traza. Está apagada con razón. → El enrutado, a fondo
Así se ve el rail de una cuenta que creó su acuerdo, abrió su sesión, recibió el pago y acreditó — pero mandó el aviso a los receptores del propio simulador. Las prácticas que dependen de tu servidor siguen apagadas, y es correcto:
Las dos últimas prácticas —Casos borde y Listo para producción— no tienen regla propia: se derivan de las demás. Nunca vas a poder encenderlas por la vía rápida.
La práctica 6, que es un reto de verdad
«Firma verificada» no se puede deducir mirando eventos: el simulador solo ve que tu endpoint respondió 2xx, no si comprobó la cabecera spidi-signature. Así que en vez de deducirlo, lo provoca.
Desde el taller de la práctica 6 lanzas el reto sobre una sesión tuya. El simulador construye un webhook legítimo, corrompe la firma cambiando un solo carácter —sigue siendo hexadecimal de la misma longitud, así que solo se cae si de verdad recalculas el HMAC— y lo envía a tu endpoint. Luego mira qué contestaste:
| Tu respuesta | Veredicto |
|---|---|
4xx | La rechazaste. Pasa el reto y la práctica queda marcada |
2xx | La aceptaste: cualquiera puede fabricar ese webhook sin conocer tu secreto. No pasa |
Timeout, error de red, 3xx, 5xx | Inconcluso. No marca la práctica, pero tampoco te acusa: no es lo que se observó |
El reto se niega a correr contra un receptor loopback, y te lo dice: el simulador estaría contestándose a su propia firma corrupta. Conecta tu endpoint —o el relay— primero. El reto espera hasta 5 segundos por tu respuesta.
Los cinco casos borde
Están ordenados por probabilidad de morderte en producción, no alfabéticamente:
| Caso | Qué tienes que provocar |
|---|---|
| Webhook duplicado | El mismo aviso otra vez, con la misma idempotency-key |
| Reintento | Que una entrega falle y el simulador vuelva a intentarlo |
| Falla la acreditación | Una fase 2 con accreditation_failed |
| Falla el pago | Una fase 1 con failed |
| Sesión expirada | Dejar vencer una sesión sin pagarla |
Los cinco son parte de «Listo para producción». No es rigor decorativo: son exactamente los cuatro o cinco días malos que tiene una pasarela de pagos, y llegar a producción sin haberlos visto es enterarse el día que ocurren.
La traza
El panel derecho muestra, en orden, todo lo que le pasó a tu cuenta: llamadas a la API con su código, transiciones de estado, e intentos y entregas de webhook con su routing, su intento número, su código de respuesta y su idempotency-key.
Dos cosas que conviene saber al leerla:
- Un webhook queda registrado aunque no se haya podido entregar. Sesión sin
webhook_url, servidor caído, relay desconectado: el aviso aparece igual, con su payload y su firma. Es justo la información que necesitas cuando tu servidor no recibe nada y no sabes por qué. - El
routingde cada entrega está a la vista. Es la forma más rápida de descubrir que llevas media tarde contestándote a ti mismo. - Lo que ENTRA por los receptores del simulador también queda, como
webhook.received, con el cuerpo crudo, las cabeceras y la firma. La traza cuenta las dos direcciones, no solo la de salida.
Aquí se ve el caso completo: el intento con la etiqueta loopback a la vista y, justo debajo, el webhook.received del receptor que lo contestó — las dos direcciones de la misma entrega, una encima de la otra.
Cuando una entrega agota sus reintentos, la traza registra la rendición como evento terminal. No desaparece en silencio.
Las cuatro herramientas
Aparte de los talleres, el rail da paso a cuatro utilidades:
Credenciales — tus tokens, tu account_id y tu webhook_secret a mano, más los receptores por defecto de tu cuenta. Es de donde se copian las cosas que hacen falta en cada curl.
Acuerdos — los acuerdos que has creado, para no tener que ir a buscar un agreement_id a la traza.
Workbench — un banco de pruebas con un set curado de cinco operaciones: crear acuerdo, crear sesión de Botón, crear un lote de Solicitud, forzar un desenlace y resetear tu cuenta. Dos detalles que lo hacen útil:
- Los ejemplos de cada petición salen del propio OpenAPI, no de una copia escrita a mano que se desincroniza.
- Valida la forma antes de enviar, con el mismo validador que usa el envío real. Un
400por un campo mal puesto lo ves antes de gastarlo.
Recetas — flujos completos montados de una sola vez, para cuando quieres ver la mecánica sin escribir nada: Pago completo crea acuerdo y sesión y fuerza las dos fases hasta accredited; Expiración deja la sesión vencer. Sirven para entender el flujo y no marcan «Tu endpoint contestó», porque usan los receptores del propio simulador.
El informe
La práctica 9 genera un informe en Markdown listo para pegar en un PR: las nueve prácticas y los cinco casos borde con la fecha en que se probó cada uno, el simulador contra el que se hizo, y una línea clara de si estás listo o no.
Lo importante es que funciona aunque no estés listo, y entonces lo que falta aparece por su nombre bajo «Lo que queda sin probar». Un informe que solo se puede generar cuando ya está todo bien no sirve para nada, porque justo entonces es cuando nadie lo necesita.
Es una herramienta, no una medalla: sirve para que quien revise tu PR vea con qué evidencia estás pidiendo el merge.
Direcciones antiguas
La consola se reorganizó y las direcciones viejas siguen funcionando: /trace, /empezar, /pagos, /acuerdos, /workbench y /recetas te llevan a donde vive ahora cada cosa. /trace va a la primera práctica, porque la traza dejó de ser una vista para estar siempre presente.
Siguiente paso
→ El simulador como API para hacer lo mismo sin navegador · Conducir el ciclo para el camino paso a paso · Observar y depurar para el catálogo de síntomas.