API, Webhooks & Audit

Webhooks

Get a signed HTTP request the moment a review arrives or an NPS response lands, and verify it safely. Enterprise plan.

What they are for

A webhook sends an HTTP request to a URL you control as soon as something happens, so you can raise a Slack alert on a bad review or open a ticket without polling. Webhooks are available on the Enterprise plan.

Settings > Webhooks
https://your-app.com/webhooks/dinopix
review.createdreview.negativeorder.deliverednps.responded

Recent deliveries

review.negative1 attemptdelivered
review.created1 attemptdelivered
nps.responded4 attemptsfailed

Adding an endpoint

  1. Go to Settings, then Webhooks.
  2. Enter the URL that will receive the requests, such as https://your-app.com/webhooks/dinopix.
  3. Choose the events. All are selected by default; pick fewer if you only care about some.
  4. Save, then copy the signing secret shown against the endpoint.

The events

  • review.created when any new review or comment syncs in.
  • review.negative when one arrives that is negative. The usual trigger for an alert.
  • order.delivered when an order is marked delivered, which is the normal moment to ask for a review.
  • nps.responded when a customer answers an NPS survey.

A negative review fires both review.created and review.negative. If you subscribe to both, expect two requests and make your handler idempotent.

Verifying the signature

Every request carries a signature header:

X-Dinopix-Signature: sha256=...

It is an HMAC-SHA256 of the raw request body using your endpoint's signing secret. Verify it before trusting anything in the payload, and compare using a constant-time comparison rather than string equality.

Compute the HMAC over the bytes exactly as received. Parsing the JSON and re-serialising it will change the bytes and the signature will not match. This is the single most common reason verification fails.

Deliveries and retries

The endpoint list shows recent deliveries with their status and attempt count. A failed delivery is retried; a persistently failing endpoint shows a rising attempt count, which is your signal that something on your side is down.

Return a 2xx status quickly. Do the real work asynchronously: if your handler is slow, the delivery is treated as failed and retried, and you will process the same event twice.

Turning one off

An endpoint can be deactivated without deleting it, which keeps the configuration and the delivery history while you fix something. Reactivate when you are ready. Deliveries are not queued while it is off.

Changes are logged

Creating, editing and removing endpoints is recorded in the audit log under Webhooks, along with who did it.

Did this answer your question?

If not, ask and we will point you at the right page.

Contact support