Saltar al contenido principal
Los webhooks permiten que tu aplicación reciba notificaciones en tiempo real cuando ocurren eventos en la plataforma de Fluz. En lugar de hacer polling para detectar cambios, registras un endpoint HTTPS y Fluz envía datos del evento en el momento en que sucede algo: una transacción con tarjeta virtual, una compra rechazada, un depósito completado y más.
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.
Los webhooks funcionan en todos los tipos de aplicación de la plataforma de Fluz: apps privadas que operan en tu propia cuenta, apps públicas OAuth que actúan en nombre de otros usuarios vía API y apps con widgets embebidos.

Cómo funciona

  1. Registras una URL de webhook en tu aplicación en el Portal de Desarrolladores.
  2. Seleccionas qué tipos de eventos escuchar (o te suscribes a todos).
  3. Cuando ocurre un evento coincidente, Fluz envía un POST HTTP a tu URL con un payload JSON firmado.
  4. Tu servidor verifica la firma, responde con un 2xx y procesa el evento.
Si tu endpoint no está disponible o devuelve un error, Fluz reintenta hasta 5 veces con backoff exponencial antes de marcar el evento como 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_COMPLETE y WIDGET_WITHDRAW_COMPLETE describen transferencias cliente↔app; la redacción DEPOSIT/WITHDRAW es 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 OAuthWebhook URLs.
  • Apps de widget: pestaña WidgetWebhook 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 un POST 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 2xx dentro de 30 segundos. Respuestas no-2xx o timeouts generan reintentos.
  • Verificar la firma HMAC en cada solicitud.

Verificación de firmas

Cada entrega incluye un header X-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 2xx dentro de 30 segundos.
  • Responder rápido: reconoce primero, luego procesa de forma asíncrona.
  • Ser accesible por HTTPS.
Tu endpoint no debe:
  • Responder con redirecciones (3xx).
  • Responder con 4xx/5xx para 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: userId es el ID de usuario de Fluz. Para eventos de OAuth/widget, externalReferenceId se asigna a tu identificador de usuario del flujo OAuth.
  • App: los payloads de transacción incluyen connectedAppId y connectedAppName. Si enrutas múltiples apps a un endpoint, ramifica según connectedAppId.

Referencia de payloads

Cada payload incluye un eventType. 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.
Los campos coinciden con TRANSACTION_CREATE cuando están presentes, además de updatedAt (ISO 8601) indicando cuándo ocurrió el cambio.
🚧 Verificación de consistencia: confirmar que userId y connectedAppId/connectedAppName estén presentes en TRANSACTION_UPDATE (y TRANSACTION_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 200 inmediatamente y maneja el evento de forma asíncrona para evitar timeouts y reintentos innecesarios.
  • Verifica cada solicitud. Valida X-HMAC-Signature contra el cuerpo crudo usando tu API key antes de procesar.
  • Desduplica con IDs de evento. Rastrea X-Event-ID para 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 marcan FAILED.

Solución de problemas

¿Necesitas ayuda?