Seguimiento y reenvío de entregas de webhooks

Retrospectiva histórica: marzo de 2026
Este artículo se escribió posteriormente y describe el registro público de entregas añadido durante ese periodo.

Cuando el receptor de un webhook no responde como se espera, puedes investigar la entrega sin tener que crear manualmente un nuevo evento de negocio. Abre el registro de entregas en Alunta o consulta la lista mediante la API para ver el estado, los intentos y los detalles públicos de cada entrega.

Una entrega con estado failed suele indicar que debes corregir el receptor o su validación. Dispatching significa que el envío sigue en curso. La API también usa succeeded cuando la entrega se ha completado. En los filtros, failed excluye las entregas cuyo estado es dispatching; usa el valor independiente dispatching para verlas. Consulta la referencia actual de la API para conocer los nombres exactos de los campos y los estados.

Reenviar una entrega

Selecciona una entrega fallida y usa la acción de reenvío. El reenvío vuelve a enviar el mismo mensaje externo; no crea un nuevo evento de suscripción ni de factura. Por eso, el receptor debe deduplicar data.event_id cuando el tipo de evento documente una clave estable, usar webhook_uuid como identificador de la entrega cuando esté disponible y admitir que un mismo evento llegue más de una vez. Mantén como entregas independientes los distintos intentos de subscription.payment_failed.

El reenvío no corrige automáticamente un error de tu sistema. Comprueba primero el endpoint, la verificación de la firma y el procesamiento del evento; después confirma el resultado en el registro de entregas.

Consulta la guía de API pública y webhooks (Markdown-fil, AI-agentvenlig) para ver el flujo actual de registro y reenvío.

Flujo seguro para reenviar

Usa en tu receptor de pruebas un evento ficticio e inexistente con el UUID 00000000-0000-4000-8000-000000000004. Antes de reenviarlo, comprueba que el receptor almacena la clave estable pertinente y responde con rapidez. Para un tipo de evento que incluya data.event_id, el reenvío entrega de nuevo la misma clave y el receptor no ejecuta dos veces la acción de negocio; si existe webhook_uuid, este identifica la entrega. Después, comprueba el estado. Conserva como intentos independientes las distintas entregas de subscription.payment_failed. Si sigue fallando, vuelve a corregir el receptor en lugar de crear manualmente un evento de suscripción.

El reenvío repite un mensaje, no un pago. Si el sistema externo inicia una acción a partir del evento, esa acción también debe ser idempotente.

Si el estado no cambia

Un reenvío correcto significa que el receptor aceptó la entrega, no que su procesamiento interno sea correcto. Consulta tanto el estado de entrega de Alunta como tu propio registro de recepción. dispatching no equivale a failed ni a succeeded, y ninguno de esos estados representa por sí mismo el estado de una suscripción o un pago.

Si el reenvío envía un tipo de evento que ya no usas, el receptor debe seguir gestionándolo de forma segura y marcarlo como ignorado según su política. No borres el historial para «corregir» un error: corrige el receptor y utiliza la acción de reenvío documentada.