Webhook de afiliados

Un webhook de afiliados es una notificación HTTP que se envía a otro sistema cuando ocurre un evento relacionado con los afiliados, como una conversión, una actualización de comisión o un cambio en el estado de un pago. Para integraciones relacionadas se puede usar un callback o postback. Los activadores y las cargas útiles compatibles dependen de la plataforma.

Terminología de webhook, callback y postback

Estos nombres se solapan entre plataformas. Webhook describe una notificación HTTP basada en eventos. Callback es un término más amplio para una respuesta o notificación dirigida a otro sistema. En las integraciones de afiliados, postback suele referirse a un evento de conversión enviado desde un servidor. La dirección, por sí sola, no establece una distinción universal.

Ejemplos de eventos y acciones del sistema receptor

Estos son ejemplos conceptuales, no una garantía de que todas las plataformas ofrezcan estos activadores. Confirma el catálogo de eventos real y la versión de la carga útil antes de diseñar el sistema receptor.

Webhooks frente a sondeo

El sondeo consulta una API según un horario para buscar cambios. Los webhooks envían los eventos compatibles a medida que ocurren. Los webhooks pueden reducir las consultas repetidas a la API, mientras que el sondeo o la conciliación pueden ayudar a recuperar estados que falten. Una integración sólida puede usar ambos, en lugar de asumir que las notificaciones son completas y llegan en orden.

Ejemplo de notificación duplicada

Un evento de aprobación se entrega dos veces después de un tiempo de espera agotado. El sistema receptor reconoce el mismo ID de evento y registra una sola transición de estado. Un reembolso posterior es un evento distinto que debe procesarse igualmente, aunque corresponda a la misma transacción.

Por eso puede ser incorrecto deduplicar todos los webhooks únicamente por el ID de transacción. La identidad del evento y la de la transacción tienen propósitos diferentes.

Comprobaciones operativas

No incluyas credenciales en ejemplos públicos, registra los resultados de entrega sin almacenar datos innecesarios de clientes y configura alertas para los fallos repetidos. El sistema receptor debe confirmar las solicitudes según el protocolo documentado por el emisor y procesar de forma segura los efectos financieros. Concilia los estados importantes con la plataforma autorizada, en lugar de depender únicamente de la hora de llegada de las notificaciones.

Diseño de un sistema receptor para condiciones reales de entrega

Confirma qué evento inicia la notificación y si se refiere a una comisión registrada, aprobada o pagada. Almacena el identificador del evento y el identificador de entidad pertinente, valida la solicitud mediante el mecanismo de autenticación compatible del emisor y pon en cola las tareas que no puedan completarse rápidamente.

Prepárate para eventos duplicados, retrasados, fallidos y fuera de orden. Un reintento debe actualizar el mismo registro, no pagar una bonificación dos veces. Si una aprobación llega antes de que exista el registro local de la venta, recupera o reconcilia el estado que falta en vez de tratar el orden de llegada como una regla de negocio.

La documentación oficial de webhooks de Stripe describe patrones de entrega y diseño de endpoints; sus firmas y cargas útiles son específicos de Stripe. Consulta la documentación de la plataforma de afiliados para conocer los campos reales, los activadores compatibles y la autenticación. Prueba las respuestas fallidas y la conciliación antes de vincular un webhook a una acción financiera.

Para consultar los ajustes correspondientes de Post Affiliate Pro, revisa la documentación de callbacks de webhooks . Verifica la configuración y los requisitos de integración según las reglas de tu programa.

Proceso de un vistazo