Webhooks

Overview

Webhooks push events to your systems as they happen — a completed pre-start landing in your safety system seconds after the operator submits it, instead of whenever your next poll runs. They come with the Developer platform add-on, alongside the REST API and the MCP server, covering 3 event types across inspections, defects, and services.

The three events

The list is deliberately small and fully honest — every event named here genuinely dispatches, which our own build gates verify. Payload schemas live in the API reference, and the event catalogue with payload shapes at /developers/webhooks.

Creating a subscription

1. 1

   In the console, open Developer → Webhooks, choose New Webhook and add an endpoint URL.

2. 2
   Select the event types it should receive.
3. 3

   Save, and copy the signing secret straight away: it's shown once and can't be retrieved later.

4. 4

   On the webhook's page, use Send Test Event to confirm the endpoint is reachable before real traffic depends on it. Saving doesn't send one for you.

Delivery, retries, and health

Events arrive as HTTP POSTs with JSON payloads. A 5xx, a timeout, a connection error, or a 408, 425 or 429 triggers retries with exponential backoff — 20 attempts spanning roughly 10 hours — so a deploy window or a brief outage on your side doesn't lose events. Some failures can't fix themselves, so they fail at once with no retries: any redirect (3xx; register your endpoint's final URL), any other 4xx, and an endpoint URL that breaks one of the fixed URL requirements (for example, not HTTPS). A host name that stops resolving, loses its IPv4 address or resolves to a private address is retried instead, since DNS can change. The one exception is a 401 or 403 within a day of the signing secret being issued, which is retried while your receiver picks up the new secret. Failures are counted per subscription and surfaced in the console, and a failing subscription notifies your organisation's Administrators and Account Owner rather than dying quietly.

Design your receiver accordingly:

• Acknowledge fast, process later — return 2xx on receipt and queue the work; a slow handler risks timing into the retry machinery.
• Be idempotent — retries mean the same event can arrive more than once; key your processing on the event's identifiers.
• Don't rely on order — retries and concurrency mean events can arrive out of order. Each payload carries what you need to fetch current state via the API if sequence matters.

Verifying payloads

Every request carries a signature header. Verify it before trusting the payload, and reject anything that fails — it's what proves the request came from PreStartGo and wasn't altered. Verification details are in the webhooks guide.

Edge cases

• Subscriptions are per-organisation — an integrator serving several organisations needs a subscription in each.
• Events reflect field reality, delayed by sync — an offline pre-start dispatches its check.completed when it reaches the platform, carrying its original performed-at time.
• Removing an endpoint stops delivery immediately; the compliance record itself is unaffected (webhooks are a copy, never the record).

Troubleshooting