Receiving webhooks
Give another service an address at your app to call when something happens: a payment, a form, a booking, a shipment. Signature checks, retries and where to see deliveries.
Last updated September 17, 2026
On this page
A webhook is an address at your app that another company's server calls when something happens on their side: a payment cleared, a form was submitted, a parcel shipped, a meeting was booked. Your app receives the event and acts on it.
Setting one up
When a payment clears in our payment provider, mark the order paid. The builder writes the handler as a public backend function and lists it on the API tab under Webhooks.
Providers sign their deliveries. The builder asks for the provider's signing secret through a secret card, and the handler checks every delivery against it before doing anything.
The Webhooks card shows the exact address. Paste it into the provider's dashboard and choose the events to send.
The same card shows whether the address is reachable and how recent deliveries went.
Good handlers
- Verify first. The handler checks the provider's signature on the raw delivery before anything else. Anyone can post to a public address; a signature proves who did.
- Answer fast. A provider waits only a few seconds. The handler records the event and returns; slow work runs afterwards.
- Expect repeats. Providers retry. The handler records the provider's own event id and ignores a duplicate, so a retried payment does not create a second order.
The address
Webhook addresses live at your app's own domain under /api/webhooks/ followed by the handler's name. They work once the app is published; the API tab tells you when one is not reachable.
Sending events out
To tell another service when something changes in your app, use an automation with a data-change trigger whose function calls that service. See Automations.