Webhooks

Instead of polling, register an HTTPS endpoint and Nembol POSTs you an event whenever something happens: a new order arrives from any channel, stock changes, a listing goes live or errors out.

Create endpoints in the dashboard (Settings → Developers → Webhooks) or via the API. Each endpoint has a signing secret, shown once at creation.

The delivery

POST /your/endpoint HTTP/1.1
Content-Type: application/json
User-Agent: Nembol-Webhooks/1.0 (+https://developers.nembol.com/docs/webhooks)
X-Nembol-Event-Id: evt_2c91…
X-Nembol-Signature: t=1784900412,v1=5257a869e7…

{
  "id": "evt_2c91…",
  "type": "order.created",
  "api_version": "2026-07-24",
  "store_id": "5f2a…",
  "account_id": "acct_66f0a1",
  "created_at": "2026-07-24T16:03:12Z",
  "data": {
    "object": { "id": "ord_…", "channel": "etsy", "total": "49.90", "currency": "USD" }
  }
}

account_id is there only for partners, on every event of one of their companies (deliveries and GET /events alike, operation.completed included): it says which company the event belongs to (the same id as in GET /accounts). Events of your own store don't have it. Route on it.

Every delivery carries User-Agent: Nembol-Webhooks/1.0 and the event id in X-Nembol-Event-Id. Trust the signature, not these headers: they are for your logs and firewall rules. A delivery is sent once per endpoint (repeats only on retries after a non-2xx answer, with the same event id).

data.object is the full resource as it is when the event is delivered (or read from GET /events), not a copy frozen at the moment of the change. What changed is in data itself: e.g. data.status and data.previous_status on listing.status_changed. If the resource changed again in between, data.object already shows the newer state and a newer event follows; order your updates by the event's created_at.

The contract (read this twice)

• At-least-once: the same event can be delivered more than once. Deduplicate by event.id.
• No ordering guarantee: events can arrive out of order. Use created_at (or re-fetch the resource) rather than assuming sequence.
• Every event is delivered, whichever part of Nembol produced it (API call, dashboard, order sync, channel webhook). If an event's delivery couldn't be queued when it was created, Nembol queues it within a few minutes (events up to 24 hours old): it arrives late, never not at all. An endpoint receives only events created after it. GET /events stays the reconcile path.
• Unknown types: new event types are added over time. Ignore types you don't handle, and return 2xx anyway.
• Respond fast with 2xx: within 10 seconds, or the delivery counts as failed. Do real work asynchronously: enqueue, then return 200.
• Verify the signature before trusting anything: verify signatures.

Retries

Failed deliveries (non-2xx, timeout, connection error) are retried with exponential backoff: 1m → 5m → 30m → 2h → 12h (about 15 hours), then the delivery is marked failed. If an endpoint keeps failing, it is auto-disabled and the store owner is notified in the dashboard and by email. Every attempt is visible in the dashboard delivery log, with manual redeliver.

Missed a window entirely? Reconcile with the event log API: GET /events?created_after=… returns the last 30 days of events.

Last updated on October 17, 2026