Skip to main content
Recibe eventos de YCloud en un endpoint público y procésalos sin perder ni repetir acciones comerciales. Utiliza HTTPS para producción, conserva el cuerpo crudo de la solicitud y verifica cada firma antes de aceptar el evento.

Registrar tu endpoint

En la Consola de YCloud, abre Desarrolladores > Webhook, selecciona Añadir Endpoints, introduce la URL de Endpoints, selecciona Eventos y guarda con Confirmar. También puedes usar POST /v2/webhookEndpoints; consulta Configurar webhooks para la solicitud y la respuesta.
  • Puedes configurar hasta 20 endpoints por cuenta.
  • La URL debe ser accesible públicamente y no debe resolver a una dirección privada.
  • La URL admite hasta 500 caracteres; la descripción opcional admite hasta 400.
  • Guarda de forma segura el secret devuelto para la firma.

Leer la solicitud del evento

Para ver ejemplos completos, consulta Cargas útiles de Webhook.

Verificar la firma

El encabezado YCloud-Signature tiene el formato t=TIMESTAMP,s=SIGNATURE. La marca de tiempo es la hora Unix en segundos.
  1. Extrae t y s del encabezado.
  2. Une la marca de tiempo, un punto y los bytes exactos del cuerpo crudo de la solicitud.
  3. Calcula HMAC-SHA256 con el secreto de firma del endpoint.
  4. Compara el resultado hexadecimal utilizando una comparación de tiempo constante.
No serialices JSON parseado para reconstruir el cuerpo. Los espacios en blanco, el orden de las claves o el escape de Unicode alteran la entrada de la firma. El siguiente ejemplo también utiliza una tolerancia de marca de tiempo configurable de cinco minutos para reducir el riesgo de ataques de reproducción (replay). Esta tolerancia es una política de la aplicación, no un límite de reintento de YCloud. Mantén sincronizado el reloj de tu servidor.

Aceptar antes de confirmar la recepción

Persiste el evento validado en una cola duradera o en una bandeja de entrada transaccional antes de devolver 2xx. Si el almacenamiento no está disponible, devuelve un error para que la entrega pueda reintentarse. Tras la aceptación duradera, permite que tu worker gestione los fallos del procesamiento comercial con sus propios reintentos. Este controlador de Express utiliza una operación persistEvent proporcionada por la aplicación. Impleméntala como una inserción atómica indexada por el id del evento; un evento ya almacenado debe considerarse como un éxito. No marques un evento como procesado antes de que su transacción comercial se confirme.

Ejemplo con Java y Spring

Este ejemplo de Java 17 aplica el mismo orden de verificación y aceptación duradera. Proporciona un bean EventInbox respaldado por un almacenamiento transaccional con una restricción única en el ID del evento. insertIfAbsent debe confirmar el evento completo antes de que retorne; los ID duplicados retornan con éxito. Tu worker podrá entonces procesar y marcar los eventos almacenados en su propia transacción.
No uses una escritura independiente de “ya procesado” en Redis antes de encolar el evento: si la puesta en cola falla después de esa escritura, se podría descartar un reintento. Utiliza una bandeja de entrada atómica y duradera o una cola cuya aceptación y gestión de duplicados sean atómicas.

Tiempos, reintentos y suspensión

Devuelve una respuesta 2xx con rapidez; procura que sea en menos de 6 segundos. Las respuestas lentas de más de 10 segundos pueden reducir la prioridad de entrega. No ejecutes tareas comerciales lentas dentro del controlador HTTP. Para una respuesta distinta de 2xx o la ausencia de respuesta, los intervalos de reintento predeterminados son: YCloud deja de reintentar ese evento tras alcanzar el límite de reintentos configurado. Con la configuración predeterminada, una URL puede suspenderse durante 3 minutos si alcanza 200 fallos por minuto o 10 minutos de tiempo de fallo acumulado en un minuto entre solicitudes concurrentes. Las solicitudes se pausan durante la suspensión y se reanudan después. Supervisa también el status del endpoint. Un endpoint pending no recibe eventos; consulta configuración del endpoint.

Verificar tu receptor

  • Una firma válida y un evento almacenado de forma duradera devuelven 2xx.
  • Los cuerpos modificados, las firmas mal formadas y las marcas de tiempo caducadas se rechazan.
  • Un evento duplicado se acepta sin repetir su acción comercial.
  • Una interrupción del almacenamiento devuelve un error y permite el reenvío.
  • Los tipos de eventos desconocidos no provocan el bloqueo del receptor.
  • Su worker reintenta los fallos de procesamiento después de la aceptación.
  • Los secretos y las cargas útiles completas de los clientes no se escriben en los registros de la aplicación.