An outbound webhook posts a small JSON message to your own server the moment something happens in your location, so your systems find out without polling for it. It lives in Settings > Developers, on its own card under your API keys.
What you need: you have to own the account, or be an administrator on it, or be a client with API access switched on for your location. If you buy through a provider, they decide whether this location can hold keys and endpoints at all; when it is switched off, the tab says so.
Add an endpoint
- Open Settings > Developers and press Add endpoint on the Outbound webhooks card.
- Enter your endpoint's URL. It has to be
https://and it has to name a real, publicly resolvable host: an IP address,localhost, or anything ending in.local,.internal,.home.arpaor.localdomainis refused, both here and again every time we are about to post to it. - Tick the events you want. Leave all of them ticked to receive everything.
- Press Add endpoint again.
The outbound webhooks card with one endpoint row, its events, status and row actions.
The signing secret is on screen exactly once, in the dialog that opens right after. Copy it into your own secret store before you close it: we keep only enough of it to show the last few characters on the row afterward, and nobody, including us, can show you the full value again.
A client can add an endpoint for their own location. Only an owner or an admin can send a test event, rotate a secret, or remove an endpoint.
What we tell you about
- review.actioned. A review was replied to, assigned or archived, whether by a person, a rule, an agent or an API key.
- rule.fired. An automation rule matched a review and ran its actions.
- An credit-threshold event, off by default. The account crossed the usage threshold set in notification settings. An endpoint scoped to specific locations gets only the location it fired on, never the account's pool size or spend.
Verify what arrives
Every request carries an X-Signature-256 header: sha256= followed by the hex HMAC-SHA256 of the exact request body, signed with your secret. Compute the same HMAC over the raw bytes you received, in constant time, and compare it to the header before you trust the payload. The body is JSON, but sign it as the raw text you received, not a re-serialized copy: re-encoding it can change the bytes and break a signature that was never actually wrong.
Send a test event
Press Send test on an endpoint's row to post one signed test.ping event and see what came back inline: the status code, how long it took, and your own server's error text if it sent one. A test is never retried and never affects the endpoint's health, so a typo in your receiver cannot disable a live integration. You can send one test per endpoint every 30 seconds.
Rotate the signing secret
Press Rotate secret on a row, read the confirmation, and confirm. The new secret is shown once, the same way the first one was. For 24 hours after a rotation, every request also carries X-Signature-256-Previous, signed with the secret you replaced, so a receiver you have not redeployed yet keeps verifying until you get to it. After that window the second header stops arriving and only the new secret works. Rotating a second time inside that window drops the oldest secret rather than keeping two around.
The delivery log
Press Show log on a row to open the second card below the table. Each row is one attempt: the event, the status code your endpoint answered with (or that it did not answer at all), which attempt number this was, how long it took, and when it ran.
The delivery log for one endpoint, showing one row per attempt with its status code and duration.
The log keeps 30 days of attempts and reads back up to 100 rows at a time. Nothing secret is ever written to it: not the payload, not the signature, not the secret in any form, only a hash of what was sent, the response status, up to the first 500 characters of what came back, and the timing. While someone from our side is standing in your location to help you, that response excerpt is withheld from what they can read, and the row says so.
Retries and when we give up
A failed delivery is retried at 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours, then once an hour, for up to 24 hours from when the event first happened. If nothing has succeeded for 24 hours straight, the endpoint is disabled automatically and an activity entry records it, so a dead integration stops costing you an hourly request into the void instead of failing silently forever.