Prueba los webhooks

1. Envía un evento de prueba

Desde el panel (Configuración → Desarrolladores → Webhooks → Enviar evento de prueba) o mediante la API:

curl -X POST https://api.nembol.com/rest/v1/webhook_endpoints/{id}/test \
  -H "Authorization: Bearer $NEMBOL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "type": "order.created" }'

La respuesta te dice al instante si tu endpoint respondió y con qué código de estado:

{ "delivered": true, "response_status": 200 }

Los eventos de prueba son entregas reales, con el mismo formato y la misma firma (así que también se ejercita tu código de verificación). data.object es una muestra con la forma real del tipo que pediste (un pedido, un anuncio, un producto…), construida con registros ficticios (TEST-SKU-1, pedido TEST-1001, ids que no existen en ningún sitio), y data.test es true. Tu handler se ejecuta de principio a fin exactamente igual que con un evento real: comprueba data.test antes de escribir nada en tu propio sistema. Un type desconocido responde 422.

2. Desarrollo local

Tu máquina de desarrollo no es accesible desde internet. Opciones:

• Apunta un endpoint de webhook a un servicio de captura (p. ej. webhook.site) para inspeccionar payloads y headers. Sirve para mirar, pero no puede verificar las firmas por ti.
• Crea un túnel a localhost con ngrok http 3000 (o cloudflared) y registra la URL del túnel como endpoint en modo de prueba. Es el ciclo completo de principio a fin: verificación de la firma, tu handler, tu 2xx.

3. Claves y webhooks en modo de prueba

Los endpoints de webhook creados con una clave nbl_test_ reciben solo eventos sintéticos (envíos de prueba y operaciones simuladas), nunca tráfico de producción. Los endpoints live reciben solo eventos reales. Mantén ambos separados en tu configuración.

4. Checklist antes del lanzamiento

• Verificación de firma activada (y falla si alteras un byte).
• El handler responde 2xx en < 10 s; el trabajo pesado se hace de forma asíncrona.
• Un event.id duplicado no tiene efecto (las entregas son al menos una vez).
• Los valores de type desconocidos se confirman, no dan error.
• Un proceso de reconciliación recorre GET /events para recuperar lo que se haya perdido.

Última actualización el 20 de octubre de 2026