Testing webhooks

1. Send a test event

From the dashboard (Settings → Developers → Webhooks → Send test event) or via the 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" }'

The response tells you immediately whether your endpoint answered and with what status:

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

Test events are real deliveries, with the same envelope and signature (so your verification code is exercised too). data.object is a sample of the real shape for the type you asked for (an order, a listing, a product…), built from fake records (TEST-SKU-1, order TEST-1001, ids that exist nowhere), and data.test is true. Your handler runs end to end exactly as on a real event: check data.test before writing anything to your own system. An unknown type answers 422.

2. Local development

Your dev machine isn't reachable from the internet. Options:

• Point a webhook endpoint at a capture service (e.g. webhook.site) to inspect payloads and headers. This is fine for looking, but it can't verify signatures for you.
• Tunnel to localhost with ngrok http 3000 (or cloudflared) and register the tunnel URL as a test-mode endpoint. This is the full end-to-end loop: signature verification, your handler, your 2xx.

3. Test-mode keys and webhooks

Webhook endpoints created with a nbl_test_ key receive only synthetic events (test sends and simulated operations), never production traffic. Live endpoints receive only real events. Keep the two separated in your configuration.

4. Pre-launch checklist

• Signature verification on (and it fails if you tamper a byte).
• Handler responds 2xx in < 10s; heavy work happens async.
• Duplicate event.id is a no-op (deliveries are at-least-once).
• Unknown type values are acked, not errored.
• Reconciliation job crawls GET /events for anything missed.

Last updated on October 16, 2026