Simulador de Webhooks

Este simulador es el control de calidad (QA) de tu integración de webhooks. Prueba los endpoints receptores que construiste — depósitos y retiros — contra todos los escenarios que exigimos, construyendo notificaciones válidas, firmándolas exactamente como lo hacemos nosotros y entregándolas a tu endpoint.

Cuando todos los escenarios pasan, tu integración está lista — no hay un QA manual aparte de nuestro lado. Ejecuta los cuatro escenarios, confirma el estado ALL PASSED, exporta la ejecución como evidencia y envíanosla como tu visto bueno antes de que lances el sistema.

Cómo funciona

• Tu usuario de operador (el secreto compartido de la API que te entregamos por OTP) firma la solicitud localmente en tu navegador usando la Web Crypto API. Nunca se envía a nuestros servidores y nunca se almacena.
• La firma se calcula sobre los bytes exactos que enviamos — SHA256(operator_username + raw_body + operator_username), codificada en hexadecimal — y se envía como Authorization: Bearer <signature>. Consulta Firma para la fórmula y el código de validación.
• La solicitud firmada se retransmite mediante un pequeño proxy del lado del servidor para que llegue a tu endpoint en condiciones reales de servidor a servidor (sin CORS del navegador). El proxy reenvía el cuerpo tal cual y nunca lo registra, ni a él ni a la firma.

Funciona en el sitio desplegado

La retransmisión es una función serverless, por lo que el simulador funciona en el sitio de documentación desplegado — no con un npm start local. Apúntalo a un endpoint que puedas alcanzar por https (el proxy rechaza hosts no-https y privados/internos).

Qué se envía

Tú proporcionas las URLs de los endpoints, tu point_of_sale.id, tu usuario de operador y un amount opcional. Todo lo demás se genera de nuevo en cada disparo — un username de jugador aleatorio (un número de 10 dígitos), un transaction_number único, la description correspondiente, created_at y currency_code — para que cada ejecución parezca una notificación real y distinta. El amount siempre se envía como un número JSON (p. ej. 100), nunca como una cadena entre comillas ni con 2 decimales.

Los escenarios

1. Happy path — una notificación válida y correctamente firmada. Tu endpoint debe aceptarla y devolver 201 Created.
2. Tampered signature — un cuerpo válido con una firma corrupta. Tu endpoint debe rechazarla con un código distinto de 201 (401 / 403) y no procesarla.
3. Invalid payload — la misma solicitud se envía repetidamente, omitiendo cada vez exactamente un campo, siempre con una firma válida (para así aislar la validación de contenido de la validación de firma). Cada una debe devolver 400. Los resultados se muestran en una tabla por campo.
4. Duplicate event — el mismo transaction_number se entrega dos veces. La primera entrega debe devolver 201 Created y la segunda debe devolver 409 Conflict, demostrando que tu idempotencia tiene su clave en transaction_number (consulta Idempotencia). Este escenario solo pasa cuando la duplicada devuelve 409.

Qué comprueba cada escenario

Cada escenario valida el cuerpo de la respuesta, no solo el estado HTTP. Para que un escenario pase, la respuesta debe cumplir todo el contrato: el cuerpo debe ser JSON válido, status debe ser "success" (happy path) o "error" (los rechazos), transaction_number debe seguir la regla de eco (el valor que enviamos, o null donde no pudiste leerlo), y las respuestas de error deben llevar un message no vacío. Un 201 con un cuerpo vacío o basura es un fallo — así que ALL PASSED significa que tu endpoint cumple todo el contrato, no solo los códigos de estado.

Tu usuario de operador se usa solo aquí, en tu navegador, para firmar la solicitud; nunca se envía a nuestros servidores ni se almacena.

URL de depósitosURL de retirospoint_of_sale.idUsuario de operadorFirma localmente — nunca se envía a nosotros ni se almacena.Monto (opcional)Por defecto 100 para depósitos, 200 para retiros.Evento a probar

Happy pathFirma válida → se espera 201.

Tampered signatureCuerpo válido, firma corrupta → se espera 401 / 403.

Invalid payloadOmite un campo a la vez, con firma válida → se espera 400 en cada caso.

Duplicate eventEl mismo transaction_number dos veces → se espera 201 y luego 409.

Preparación de la integración

0/4

Happy path	Firma válida → se espera 201.	No ejecutado
Tampered signature	Cuerpo válido, firma corrupta → se espera 401 / 403.	No ejecutado
Invalid payload	Omite un campo a la vez, con firma válida → se espera 400 en cada caso.	No ejecutado
Duplicate event	El mismo transaction_number dos veces → se espera 201 y luego 409.	No ejecutado

Ejecuta los cuatro escenarios y deja todas las verificaciones en verde. Ese estado ALL PASSED es tu visto bueno — no hay un QA manual aparte de nuestro lado.

La exportación nunca incluye tu usuario de operador ni la firma de la solicitud.

Inspección

Ejecuta un escenario para ver aquí el estado HTTP, el cuerpo de la respuesta, los headers y la latencia.