Webhooks Pro

Point an endpoint at another system — a warehouse, an internal dashboard, a script on a server you control — and StoreMaster posts each event to it.

This is a handoff, not an automation engine. It delivers an event and retries. It does not branch, transform, schedule or send marketing. A tool built for that is a better place for that.

What arrives

A small JSON envelope: a delivery id, the event name, when it was sent, which site sent it, and the event’s own data.

The data is already redacted before it reaches a webhook — StoreMaster events carry ids, uuids and counts, never an email address, a password, a licence key or a raw customer record. There is no unredacted form to opt into. A webhook URL typed with a mistake in it therefore costs you nothing but noise on somebody else’s server.

Every request is signed

Each endpoint has a secret of your choosing, at least sixteen characters. A webhook without one is refused at save: an unsigned webhook is a URL anyone who learns it can impersonate.

Requests carry:

• X-StoreMaster-Signature — sha256= plus an HMAC of the timestamp and the body, keyed with your secret.
• X-StoreMaster-Timestamp — the moment it was signed, which is also inside the signed string, so your receiver can reject a replayed request without trusting a header it cannot verify.
• X-StoreMaster-Event and X-StoreMaster-Delivery — the event name and a unique id, so a receiver can make its own handling idempotent.

The secret is never returned by the API, not even to somebody who could read it from the database. A settings screen that echoes a secret back has put it in a browser cache and, eventually, in a screenshot.

Nothing is sent from the request that caused it

An event can fire in the middle of a customer’s checkout. A ten-second wait for somebody else’s server must not become part of that, so deliveries are queued and sent by a background run.

Retries stop

Five attempts, backing off from a minute to about ten hours. After that the delivery becomes a dead letter: a row you can see, with the event, the status code and the error.

Dead letters are never swept away on a timer. They are the only record that something did not arrive, and deleting them automatically is how a store finds out six months late. Delivered rows are cleaned up after a week.

Fix your endpoint and retry a dead letter, and it goes back in the queue with a fresh allowance of attempts.

Choosing events

An endpoint can name the events it wants, or name none and get all of them — the first is what a warehouse system wants and the second is what a dashboard wants.

Diagnostics tells you if an active endpoint uses plain HTTP, and how many deliveries are waiting in the dead-letter list.