Publishing and responses
Integrations
Creating one
Go to Integrations, add an endpoint, and choose which events it should receive. You are shown a signing secret once, at creation. Store it then — it is encrypted at rest and cannot be displayed again.
Verifying a delivery
Every request carries a signature computed over the raw body with your secret. Verify it before trusting the payload, and compare using a constant-time comparison rather than string equality.
Do not rely on the source address instead. Anyone can post to your endpoint; the signature is what makes a request provably ours.
Delivery behaviour
| Aspect | Behaviour |
|---|---|
| Retries | A non-2xx response or a timeout is retried with exponential backoff. Persistent failure eventually stops delivery and the endpoint is marked failing. |
| Ordering | Not guaranteed. Under load two responses can arrive out of order — use the submission timestamp in the payload, not arrival order. |
| At-least-once | A delivery can arrive more than once. Treat the submission id as an idempotency key. |
| Timeout | Respond quickly. Do the work asynchronously and return 2xx as soon as you have accepted the payload. |
Endpoint requirements
- Must be
https://and publicly resolvable. - Private and loopback addresses are refused. A webhook pointed at an internal address would make the platform fetch on your behalf from inside its own network.
- Return 2xx on success. Anything else is treated as a failure and retried.
Other routes out
For one-off analysis, export from Responses as CSV or Excel. For reference data going the other way — a list of schools from your own system into a dropdown — upload it as an option list rather than pasting it into each form.