Outbound webhooks (Zapier, Make, custom systems)

Under Settings → Outbound webhooks (admin, visible only when the feature is enabled for your organization) you can register your own HTTPS endpoints that receive signed JSON POSTs when events happen in Novro — e.g. survey launched/reminded/closed, access requests, overdue action items, OKR check-ins and expiring training records. It is the same event catalog the chat integrations use, but machine-readable — ideal for wiring Novro into Zapier, Make or a custom system without polling the REST API.

Create a webhook: click “New webhook”, enter a label and the endpoint URL (https and public hosts only — localhost, private IP addresses and unusual ports are rejected for security), tick the events to send and save. You then receive a signing secret shown ONCE — copy it immediately and store it securely. It cannot be shown again.

Rotate the secret: to change the signing secret click “Rotate secret” (the webhook keeps its id and subscriptions — no need to reconfigure the receiver). A NEW secret is shown once, exactly as at creation. For a grace window of about 24 hours every delivery is signed with BOTH secrets: the X-Novro-Signature header with the new one and X-Novro-Signature-Previous with the old one. Your receiver can verify either — switch it to the new secret any time during the window, after which the old one stops working. The rotation is recorded in the audit log.

Verify deliveries in your receiver: every request carries the X-Novro-Signature header with the value sha256=<hex>, an HMAC-SHA256 of the raw request body computed with your secret. Compute the same HMAC on your side and compare (constant time). The body is JSON with the fields id (delivery id, identical on every retry — use it for deduplication), event, timestamp, orgId and data. The X-EquiPay-Event header carries the event type and X-EquiPay-Delivery the delivery id.

Delivery, retries and history: a delivery is attempted immediately first. If it fails (5xx or a network error) it is queued and retried with growing backoff — roughly 1 min, 5 min, 30 min, then 2 h. If it still fails after five attempts it is “dead-lettered” (kept as failed, never retried). A 4xx response is treated as a permanent failure and is not retried. Click “History” on a webhook to see recent deliveries with status (delivered/queued/dead-lettered), attempt count and the last HTTP code/error — click “Load more” for older deliveries — and to manually re-queue a failed or dead-lettered delivery (“Redeliver”). After five consecutive failed delivery attempts the webhook is auto-disabled; its queued deliveries pause and are replayed when you re-enable it. Delivered and dead-lettered history rows are kept for 30 days and then cleared out automatically — the queue of still-pending deliveries is not affected.

Delivery-time security (DNS): on every delivery the receiver’s hostname is resolved and the delivery is refused if it points at a private, loopback, link-local or cloud-metadata address (defence against DNS rebinding). A blocked delivery is treated as a failure and follows the same queue/dead-letter path.

Use “Send test” to verify endpoint and signature with a test.message event. The panel shows the last delivery status (time, HTTP code, error) per webhook.

Important about the content: payloads contain event metadata only (titles, counts, dates, statuses) — never salaries, survey responses or raw employee data, and participation counts below the anonymity threshold are never sent. “Remove” disables the webhook immediately after a confirmation.