Pantacor Hub can now push device and deployment activity to your own systems as it happens. Subscribe an HTTPS endpoint to the events you care about and the Hub POSTs a signed JSON payload each time one occurs — no more polling the API to find out a rollout finished.
Typical uses: page an on-call channel when a rollout reports ERROR, kick off a CI job when a new revision lands, or mirror device metadata into your own inventory.
Creating a webhook
Open Webhooks in the Hub sidebar and choose Create webhook: give it a name, the endpoint URL, and pick the event types you want. Optional filters narrow deliveries to specific devices (one PRN per line) or to metadata events touching specific keys, and you can attach custom headers to every delivery for routing or your own auth. HTTPS is required unless you explicitly allow an insecure development endpoint.
On creation you get the subscription’s signing secret, shown exactly once. Every delivery is signed with HMAC-SHA256(secret, "{Webhook-Id}.{Webhook-Timestamp}.{raw-body}"), so your receiver can prove a request really came from Pantahub. Secrets can be rotated later with an overlap window — deliveries are signed with both old and new during the transition, so receivers that check every signature entry never see a failure.
Subscription lifecycle
The list view shows each webhook’s URL, event types and lifecycle status — pending_verification, active, disabled or failed — with pause, test, deliveries, edit and delete actions per row. New endpoints prove ownership through a verification handshake: a webhook.verification delivery carries a one-time challenge, and the endpoint echoes it back to start receiving events.
Event types
Nine event types cover the device and deployment lifecycle:
| Event | Fires when |
|---|---|
device.created / device.updated / device.deleted |
Device records change |
device.public.toggled |
A device’s public flag flips |
device.device_meta.updated / device.user_meta.updated |
Device-reported or user-set metadata changes |
step.created |
A new trail step (revision) is pushed |
step.progress.changed / step.status.changed |
A rollout progresses or transitions between NEW, STARTED, DONE, UPDATED, WONTGO, ERROR |
A word of warning from the docs: device.device_meta.updated is by far the highest-volume event — devices report metadata continuously — so subscribe to it deliberately.
The delivery contract
The status code your endpoint returns is the whole protocol: 2xx completes the delivery; 408, 425, 429 and 5xx are retried with exponential backoff (8 attempts over roughly two hours); any other 4xx is a permanent failure and dead-letters the delivery. Deliveries must complete within 10 seconds — validate, enqueue, return 2xx, and do the real work out of band.
Delivery is at-least-once with no ordering guarantee, so make handlers idempotent and dedupe on the event id, which stays stable across retries.
Every attempt is visible in the per-webhook delivery log — event, attempt number, status, HTTP response and timings — with a resend button per row. Dead-lettered deliveries stay visible and can be replayed by hand, and a test action sends a synthetic delivery through the full path (signing, your endpoint, response handling) without waiting for a real device event:
The Events explorer
Webhooks → Events is the account-wide log of everything the system emitted for you, whether or not a subscription matched. Filter by type, resource PRN or time range; select an event to see its payload, which subscriptions it went to and each outcome — and Redeliver all fans a fresh attempt out to every matching subscription, which is handy after fixing a bug in your receiver.
Try it
Webhooks are live for every account at hub.pantacor.com under Webhooks in the sidebar. The full reference — payload format, a copy-paste signature verifier, retry schedule and troubleshooting table — is in the docs: Webhooks guide. Questions and feedback welcome below!