What webhooks are for
Most owners never need this page. It exists for one situation: you already use another system — an accounting tool, a member register, a spreadsheet an assistant keeps, an automation service like Zapier or Make — and you want it to know about a booking without anyone retyping it.
A webhook is Stund calling that system for you. You give us an address to call, you tick the things worth calling about, and from then on every matching change is sent there within seconds. Nobody has to remember to do it.
If you just want to see what happened, you don't need a webhook: Activity in the sidebar already logs every booking change, message and webhook attempt.
Setting one up
Open Settings → Webhooks. Only the owner and admins can see this page.
- Paste the address the other system gave you into Endpoint URL. It has to start with
https://and be reachable from the internet — an address on your own office network won't be accepted. - Tick the events you want sent. Leave every box unticked to receive all of them.
- Choose Add endpoint.
You can add several endpoints — one for your accountant's tool, one for an automation that texts you — and each one gets its own list of events.
The events you can subscribe to
Eight things can be sent:
- Booking created — a new request or booking arrived
- Booking accepted — you (or auto-approval) confirmed one
- Booking rejected — you declined a request
- Booking cancelled — a booking was cancelled, by you or by the client
- Booking expired — someone never paid in time and the slot was released
- Payment completed — money arrived
- Payment failed — a charge didn't go through
- Payment refunded — money went back to the client
Each message carries the details of the booking or payment it is about: who booked, which coach, the start and end time, the status, and the amount where there is one. Pick narrowly rather than subscribing to everything — an endpoint that only cares about paid bookings is easier to keep working than one that has to sort through all eight.
The signing secret
Every endpoint has its own secret. Stund uses it to sign each message, so the system receiving it can prove the message really came from us and wasn't tampered with on the way. It is shown hidden by default; use the eye button to reveal it and the copy button to hand it over.
Heads up
Treat the secret like a password: give it only to the system that needs it, and never post it anywhere public. If it leaks, use the refresh button beside it to generate a new one — but note the old secret stops working the moment you do, so update the receiving system straight away or its deliveries start failing.
Whoever set up the receiving end will also want to know that each message arrives as a POST with a JSON body, and carries the event name, a unique delivery id and the signature in its headers. That's all they need from you; the rest is on their side.
Did it arrive? Delivery history
Under your endpoints, Recent deliveries lists the last fifty messages with, for each one, the event, how many attempts it took, the response code that came back, and when. A delivery is in one of three states:
- Delivered — the other system accepted it (any 2xx response).
- Pending retry — an attempt didn't land and another is scheduled.
- Failed — every attempt was used up.
Stund retries on its own: up to five attempts per message, with growing waits between them — about a minute, then five, then thirty, then two hours, then six. That covers the ordinary case of the other system being down for a while. Each attempt waits ten seconds for a response before giving up.
Inspect on any row opens exactly what was sent and, if something went wrong, the error that came back — a refused connection, a timeout, an HTTP error code. Retry beside a failed delivery sends it again immediately, which is what you want once the other end is fixed.
Tip
If deliveries fail in a batch at the same time, the problem is almost always the receiving system rather than the message. Inspect one, fix that end, then retry.
What you need
Webhooks come with the Growth and Scale plans. On Free the page shows what it does but nothing can be created.
When something isn't working
- The endpoint was refused when you added it. The address must be
https://and public. Anything pointing at a private network or a machine only you can reach is rejected on purpose. - Nothing is arriving at all. Check the endpoint's status dot — an endpoint can be switched off with the toggle beside it, and a disabled endpoint is skipped silently. Check the event you expected is actually ticked, too.
- Everything says failed. Inspect one delivery and read the error. A response code means the other system answered and refused; a timeout means it never answered in ten seconds.
- You changed the receiving system's address. Use the pencil button to edit the endpoint rather than adding a second one, or you'll get every event twice.