Esta página está pensada como una sección de Webhooks de nivel superior, ya que los eventos de webhook abarcan múltiples áreas de la plataforma (flujos del widget y actividad de transacciones) en lugar de pertenecer a una sola función.
Cómo funciona
- Registras una URL de webhook en tu aplicación en el Portal de Desarrolladores.
- Seleccionas qué tipos de eventos escuchar (o te suscribes a todos).
- Cuando ocurre un evento coincidente, Fluz envía un
POSTHTTP a tu URL con un payload JSON firmado. - Tu servidor verifica la firma, responde con un
2xxy procesa el evento.
FAILED.
Webhooks por tipo de app
Cómo se enrutan los eventos a tu app depende de tu modelo de aplicación.Apps privadas — tu propia cuenta
Los webhooks se disparan por actividad en tu propia cuenta. Cualquier transacción, rechazo o depósito en cuentas que posees dispara webhooks registrados en tu app. Casos de uso comunes: notificaciones cuando se autoriza o liquida una transacción con tarjeta virtual; alertas en tiempo real sobre rechazos; monitoreo de depósitos y cambios de balance en tus cuentas de gasto.Apps públicas (OAuth) — actuando en nombre de usuarios
Los webhooks se disparan por actividad en cuentas que han autorizado tu app. Cuando un usuario otorga acceso a tu app vía OAuth, sus eventos se enrutan a tus webhooks registrados, siempre que la concesión OAuth del usuario incluya los scopes requeridos. Esto funciona tanto si el usuario interactúa a través de tu integración directa por API como mediante un widget embebido; el requisito clave es una relación OAuth entre el usuario y tu app. Casos de uso comunes: monitorear gasto con tarjetas virtuales en cuentas conectadas; notificaciones de rechazos en tiempo real; seguimiento de depósitos completados; recibir actualizaciones de estado de KYC.Apps de widget
Las apps de widget son una app pública especializada. Los eventos se enrutan de la misma manera (en base a la relación OAuth), y además las apps de widget admiten eventos específicos del widget como transferencias completadas y compras de tarjetas de regalo.Tipos de eventos
Fluz solo entrega un evento si tu aplicación — y, para apps públicas/OAuth, la concesión OAuth del usuario individual — posee los scopes requeridos.Eventos de transacción
Cubren el ciclo de vida completo de la transacción. Aplican a todos los tipos de app.Eventos de depósito
Eventos específicos de widget
Aplican a integraciones de widget y OAuth donde los usuarios interactúan mediante flujos embebidos de Fluz.📘 Nota sobre la nomenclatura:WIDGET_DEPOSIT_COMPLETEyWIDGET_WITHDRAW_COMPLETEdescriben transferencias cliente↔app; la redacciónDEPOSIT/WITHDRAWes histórica. Trata “deposit” como “cliente → app” y “withdraw” como “app → cliente”.
Configuración de webhooks
1. Abre el Portal de Desarrolladores
Ve al Developer Portal y selecciona tu aplicación.2. Abre la sección de Webhooks
- Apps OAuth: pestaña OAuth → Webhook URLs.
- Apps de widget: pestaña Widget → Webhook URLs.
- Apps API / privadas: la sección Webhook URLs en la configuración de tu app.
3. Agrega una URL de webhook
Haz clic en Add new URL e ingresa tu endpoint HTTPS (p. ej.,https://api.yourapp.com/webhooks/fluz).
4. Selecciona eventos
Elige los tipos de eventos que deseas recibir. Deja la selección vacía para actuar como catch-all y recibir todos los eventos para los que tu app tenga scopes.5. Guardar
Haz clic en Create Webhook. Tu endpoint comenzará a recibir eventos de inmediato.Gestión de webhooks
- Múltiples endpoints — puedes registrar más de una URL de webhook por aplicación.
- Cambiar eventos suscritos — elimina el webhook y vuelve a crearlo con la nueva selección de eventos.
- Eliminar un webhook — haz clic en Remove junto a él. El webhook se archiva de inmediato y deja de recibir eventos.
Recepción de webhooks
Formato de la solicitud
Cada webhook se entrega como unPOST HTTP con estos headers:
El cuerpo es un objeto JSON y cada payload incluye un campo
eventType que identifica el evento.
Requisitos del endpoint
- Solo HTTPS — los endpoints HTTP simples se rechazan al momento del registro.
- Accesible públicamente y capaz de aceptar solicitudes
POST. - Responder con un
2xxdentro de 30 segundos. Respuestas no-2xxo timeouts generan reintentos. - Verificar la firma HMAC en cada solicitud.
Verificación de firmas
Cada entrega incluye un headerX-HMAC-Signature: un hash HMAC-SHA256 del JSON crudo, firmado con la API key de tu aplicación. Verifícalo siempre antes de confiar en un payload.
⚠️ Verifica contra el cuerpo crudo de la solicitud. Calcula el HMAC sobre los bytes exactos que envió Fluz — no reserialices el JSON parseado. Reconvertir a string puede reordenar claves o cambiar espacios en blanco y causar que fallen firmas válidas. Los ejemplos a continuación capturan el cuerpo crudo por esta razón.
Node.js (Express)
Python (Flask)
Responder a webhooks
Tu endpoint debe:- Responder con un estado
2xxdentro de 30 segundos. - Responder rápido: reconoce primero, luego procesa de forma asíncrona.
- Ser accesible por HTTPS.
- Responder con redirecciones (
3xx). - Responder con
4xx/5xxpara webhooks válidos (esto dispara reintentos).
Política de reintentos
La entrega de nuevos eventos se reanuda automáticamente una vez que tu endpoint se recupere. Para reenviar eventos que ya llegaron a
FAILED, contacta al soporte con el X-Event-ID correspondiente.
Ciclo de vida del estado del evento
Idempotencia y orden
Los webhooks pueden entregarse más de una vez, y no se garantiza el orden de entrega.- Desduplica usando el header
X-Event-ID. Persiste los IDs procesados (Redis o una base de datos en producción) y omite eventos que ya manejaste. - Ordena por datos, no por llegada. Si la secuencia importa, ordena por timestamps del payload (
createdAt,updatedAt,transactionDateTime) y por IDs de evento.
Identificación de la app y el usuario
- Usuario:
userIdes el ID de usuario de Fluz. Para eventos de OAuth/widget,externalReferenceIdse asigna a tu identificador de usuario del flujo OAuth. - App: los payloads de transacción incluyen
connectedAppIdyconnectedAppName. Si enrutas múltiples apps a un endpoint, ramifica segúnconnectedAppId.
Referencia de payloads
Cada payload incluye uneventType. La disponibilidad de campos puede variar según el evento; los handlers deben ignorar campos no reconocidos para compatibilidad futura.
Transacción creada (TRANSACTION_CREATE)
Se dispara para cualquier transacción nueva: compras con tarjeta virtual, depósitos, transferencias y más.
Transacción actualizada (TRANSACTION_UPDATE)
Se dispara cuando cambian el estado o los detalles de una transacción, por ejemplo, cuando una autorización pendiente se liquida.
TRANSACTION_CREATE cuando están presentes, además de updatedAt (ISO 8601) indicando cuándo ocurrió el cambio.
🚧 Verificación de consistencia: confirmar queuserIdyconnectedAppId/connectedAppNameestén presentes enTRANSACTION_UPDATE(yTRANSACTION_DECLINE) para que los consumidores puedan identificar al usuario y la app de forma consistente a lo largo del ciclo de vida.
Transacción rechazada (TRANSACTION_DECLINE)
Se dispara cuando una transacción es rechazada. Incluye motivos de rechazo estructurados con los que tu app puede actuar.
Depósito completado (DEPOSIT_COMPLETE)
Se dispara cuando se completa un depósito desde una fuente de fondos hacia una cuenta de gasto.
Inicio de KYC (WIDGET_KYC_INITIATION)
Se dispara cuando un usuario inicia la verificación de identidad. Solo apps públicas/widget.
Transferencia completada — cliente a app (WIDGET_DEPOSIT_COMPLETE)
Se dispara cuando un usuario transfiere fondos a tu aplicación.
Transferencia completada — app a cliente (WIDGET_WITHDRAW_COMPLETE)
Se dispara cuando tu aplicación transfiere fondos a un usuario.
Compra de tarjeta de regalo (WIDGET_PURCHASE_GIFT_CARD)
Se dispara cuando se completa una compra de tarjeta de regalo a través del widget.
🚧 Por completar. Agregar el ejemplo de payload y la tabla de campos de WIDGET_PURCHASE_GIFT_CARD (p. ej., comercio, monto, identificador de la tarjeta de regalo).
Campos comunes de payload en widget: userId (ID de usuario de Fluz), accountId (ID de cuenta de Fluz), externalReferenceId (tu identificador de usuario del flujo OAuth) y amount cuando corresponda.
Mejores prácticas
- Responde rápido, procesa después. Devuelve
200inmediatamente y maneja el evento de forma asíncrona para evitar timeouts y reintentos innecesarios. - Verifica cada solicitud. Valida
X-HMAC-Signaturecontra el cuerpo crudo usando tu API key antes de procesar. - Desduplica con IDs de evento. Rastrea
X-Event-IDpara manejar entregas reintentadas/duplicadas. - Acepta campos desconocidos. Los payloads pueden ganar campos con el tiempo; ignora los no reconocidos en lugar de fallar.
- Monitorea tu endpoint. Alerta ante respuestas repetidas no-
2xx: después de 5 fallos los eventos se marcanFAILED.
Solución de problemas
¿Necesitas ayuda?
- Problemas técnicos: revisa los logs de tu endpoint y contacta soporte con el
X-Event-ID. - Preguntas sobre scopes: consulta Application Scopes y Códigos de rechazo.