Help
Webhooks and Zapier
Sealinn can POST to a URL you choose the moment something happens — a certificate approved, a document rejected, a policy nearing expiry. Point it at Zapier or Make and the rest of your tools can react.
What people use it for
The useful ones all have the same shape: something in Sealinn decides a subcontractor is or is not covered, and somewhere else a person is about to act on that. A message into the project channel when a certificate clears. A row appended to the job spreadsheet the office already lives in. A task raised for whoever chases paperwork when one comes back rejected. A hold released on a payment once the sub is covered — that last one is the reason A document is approved is the event most people start with.
There is no Sealinn app in the Zapier directory
What there is, is a signed webhook. In Zapier that means a Webhooks by Zapier → Catch Hook trigger; in Make, a Custom Webhook. Both hand you a URL, and that URL is all Sealinn needs. Anything either tool can do downstream works from there.
Setting one up
- In Zapier, create a Zap with the Webhooks by Zapier → Catch Hook trigger and copy the custom webhook URL it gives you. (In Make, add a Custom Webhook module and copy its address.)
- In Sealinn, open Settings → Integrations and press Add an endpoint. Paste the URL and tick the events you want.
- Press Send test. Zapier will show the sample as a caught request, which is what lets you map the fields in the steps that follow. The test payload is marked `"test": true` and names a fake subcontractor, so nothing downstream mistakes it for a real approval.
- Finish and turn on your Zap. Sealinn will POST to it from then on.
You need the Compliance defaults permission to see or change endpoints, because the page shows the signing secret. Owners and admins have it; a reviewer does not — see roles and permissions for who gets what.
The four events
| Event | When it fires |
|---|---|
| A document is approved (`document.approved`) | Fires when a certificate passes your checks — automatically or because someone approved it. |
| A document is rejected (`document.rejected`) | Fires when a document is rejected, with the reasons it failed. |
| A document is nearing expiry (`document.expiring`) | Fires on each reminder rung, so you hear it before the policy lapses. |
| A subcontractor's status changes (`subcontractor.compliance_changed`) | Fires when the roll-up for a subcontractor moves between compliant, expiring, non-compliant and incomplete. |
A subcontractor's status changes fires only on an actual transition — compliant to non-compliant, say — never on a recalculation that landed on the same answer. A document is nearing expiry follows the reminder schedule you set, so if your ladder is 60 and 14 days, that is when the webhook arrives too. One cadence, two ways of hearing it. What decides a document's verdict in the first place is covered in reviewing a flagged certificate.
What arrives
A JSON POST with `id`, `event`, `createdAt`, `organizationId` and a `data` object whose contents depend on the event — document and subcontractor ids, the decision, the coverage type, the expiry date. The `id` is unique per event: if you ever see the same one twice it is a retry, and treating it as one occurrence is worth doing in anything that costs money downstream.
No names, addresses or phone numbers are ever sent
A payload leaves Sealinn entirely — into a Zap, a spreadsheet, a channel whose membership we cannot see. So it carries ids and statuses, plus the subcontractor's company name where the event is about them, and never a contact detail you gave us. If you need more than the payload holds, look the id up through your own copy of the data.
Verifying the signature
Your endpoint is a public URL, so anyone who finds it can POST to it. Every delivery therefore carries a `Sealinn-Signature` header of the form `t=<unix seconds>,v1=<hex>`, where the hex is an HMAC-SHA256, keyed on your endpoint's signing secret, of the string `<t>.<raw body>` — the timestamp, a full stop, then the body exactly as received, before any JSON parsing.
- Recompute the HMAC and compare it to `v1` using a constant-time comparison.
- Reject anything whose `t` is more than a few minutes old. The timestamp is inside the signed string, so it cannot be edited to bring an old delivery back into the window.
- Keep the secret out of your Zap's visible steps if other people can see it. Anyone holding it can forge a delivery.
If you are only pushing into a private Zapier URL you may reasonably skip verification — the URL is the secret in that case. Verify wherever the webhook triggers something you would not want a stranger to trigger.
When it stops working
Sealinn retries a delivery that times out or comes back a server error, and does not retry one your endpoint refuses outright — a 404 or a 401 means it was understood and rejected, and retrying that for an hour only fills your logs. After ten failures in a row the endpoint is switched off and the Integrations page says so, with the last response it got.
Turning it back on clears the counter and keeps the same signing secret, so nothing on your side needs re-doing. Removing an endpoint and adding it again does not — that issues a new secret.