Webhooks
Sailor sends a signed, durable outcome webhook to the public HTTPS URL configured on an action outcome. Use the payload to update your CRM, trigger follow-up, audit list movement, or start downstream automation.
Before configuring an action webhook, an owner or admin creates a signing secret in Settings → Integrations → Webhook signing. Sailor shows whsec_… secrets once. Store the secret only in the receiver’s server-side secret manager.
For an outcome that existed before signing setup, Sailor atomically creates an encrypted bootstrap secret on the next delivery and signs that delivery immediately—there is no unsigned fallback. Rotate the bootstrap secret in Settings to obtain the one-time value before changing your receiver to reject invalid signatures.
When Webhooks Are Sent
Return any 2xx status to acknowledge receipt. Do slow or unreliable downstream work after you have accepted the webhook.
Verify Every Delivery
Sailor sends these headers on every attempt:
Build the signed message as:
Compute HMAC-SHA256 with the matching whsec_… secret and compare the lowercase hex digest in constant time. Reject a timestamp more than five minutes from your server clock. Verify the signature before parsing JSON or performing any side effect.
During rotation, new deliveries use the new version immediately and the prior version remains listed for a seven-day verification overlap. Keep both secrets until the overlap ends; a delivery always identifies its version.
Example Payload
Payload Fields
Destination Shapes
For an add-to-list outcome:
For a remove-from-lists outcome:
Receiver Checklist
- Accept
POSTrequests withContent-Type: application/json. - Return a
2xxstatus after you store or enqueue the event. - Verify
X-Sailor-Signatureagainst the exact raw body before parsing JSON. - Make your receiver idempotent by storing the unique
X-Sailor-Delivery-Idbefore doing work. - Keep endpoint credentials and forwarding secrets out of browser code.
- Log delivery ID, signature version, result, and timestamp while testing. Do not log the signing secret.
Minimal Receiver
Delivery And Retry Behavior
Sailor persists the URL, exact body, delivery ID, and signing-secret version before the first network attempt. Network errors and HTTP 408, 409, 425, 429, and 5xx responses retry with bounded exponential backoff and deterministic jitter. A valid Retry-After header can extend the next delay. There are at most eight total attempts.
Delivery is at least once: a receiver can process a request even when Sailor never receives its response. Deduplicate on X-Sailor-Delivery-Id; do not assume exactly-once delivery or global ordering.
Every attempt has an append-only audit row. The original delivery keeps one stable ID and body across retries and operator replay.
Endpoint Safety
Webhook URLs must use HTTPS on port 443. Sailor resolves both A and AAAA records before every attempt, rejects the whole hostname if any address is private or special-use, pins the validated address for the TLS connection, preserves hostname verification, and does not follow redirects. Localhost, link-local, private-network, credential-bearing, fragment-bearing, and non-HTTPS URLs are rejected.
Testing Locally
Use a tunnel during development so Sailor can reach your local server.
Set the outcome webhook_url to the public HTTPS tunnel URL while testing, then switch it to your production HTTPS URL before using the outcome with live agents.
See the Webhooks section in the API Reference for the complete schema.