Webhooks

Seegnals tells your systems what happened by POSTing a signed JSON event to a URL you control. Use it to push replies into a CRM that has no native connector, to mirror bounces into your own data, or to trigger a Zap.

Setting it up

1. Settings → Integrations → Webhooks. Paste an https:// URL and press Save URL.
2. Copy the signing secret (whsec_…). It is shown once now and can be revealed again from the same tab.
3. Press Send test event. Your endpoint receives a type: "test" payload; the tab shows the HTTP status it answered with.

The URL must be public and https://. Local hosts, private IP ranges, credentials in the URL and hosts that resolve to private addresses are rejected when you save and again before every delivery.

Events

type	Sent when	metadata
sent	A step of a sequence was sent to a prospect	{ "step": 2, "messageId": "<Message-ID header>" }
replied	A reply from the prospect arrived in a connected mailbox	{ "replyId": "<uuid>", "from": "<sender address>" }
clicked	The prospect clicked a tracked link (needs a verified tracking domain)	{ "url": "<target url>", "messageId": "<Message-ID>", "via": "redirect" }
bounced	The mailbox reported a bounce for the message	{ "error": "<SMTP error text>", "step": 1 }
unsubscribed	The prospect used the one-click unsubscribe	{ "via": "one-click" }
test	You pressed Send test event	{ "note": "Test event sent from Seegnals settings." }

opened is deliberately not sent. Apple Mail Privacy Protection and similar clients fetch the tracking pixel whether or not a person read the message, so an open is not a signal your automation should act on. It appears in the app per campaign, labelled as an upper bound.

The request

POST https://hooks.example.com/seegnals
Content-Type: application/json
User-Agent: Seegnals-Webhook/1
X-Seegnals-Event: replied
X-Seegnals-Delivery: 5d2f1c8a-3b4e-4f60-9a71-2c8e7d9f0b13
X-Seegnals-Signature: t=1767225600,v1=3f6a…c9e1

{"id":"10000000-0000-0000-0000-000000000002","type":"replied","occurred_at":"2026-08-23T09:00:00Z","workspace_id":"00000000-0000-0000-0000-000000000001","prospect_id":"00000000-0000-0000-0000-000000000002","prospect_email":"jane@example.com","campaign_id":"00000000-0000-0000-0000-000000000003","campaign_name":"Q3 outbound","metadata":{"replyId":"20000000-0000-0000-0000-000000000001","from":"jane@example.com"}}

Payload fields

Key	Type	Notes
id	uuid	The event id. For positive_reply subscriptions, the reply id.
type	string	Event type as above.
occurred_at	string	UTC, second precision, YYYY-MM-DDTHH:MM:SSZ.
workspace_id	uuid	Your workspace.
prospect_id	uuid or null	null only in the test event.
prospect_email	string or null	Looked up at event time; null if the prospect was deleted.
campaign_id	uuid or null	null for events outside a campaign and for the test event.
campaign_name	string or null
metadata	object	Per type, see the table above.

The body is compact JSON without whitespace and the key order is not guaranteed (it is the database’s JSONB order). Verify the signature over the raw bytes you received, never over a re-serialised object. See Verifying signatures.

Delivery, retries, timeouts

• Your endpoint has 10 seconds to answer. Any 2xx counts as delivered. The response body is never read.
• Redirects are not followed. A 3xx is a failure; point the webhook at the final URL.
• Failed attempts are retried by a worker that scans every minute: 3 attempts in total, roughly a minute apart. After the third failure the delivery is marked failed and stays in the log with the status or error.
• The first attempt of a new event also waits for the next scan, so expect a delivery within about a minute of the event. The test event is the exception: it is sent immediately.
• A dead endpoint does not disable the webhook. New events keep creating deliveries, each with its own three attempts. Nobody is emailed about failures; watch Recent deliveries in the Webhooks tab (last 10) or Settings → Integrations → History.
• The payload and the URL are snapshotted when the event happens. Changing the URL later does not redirect deliveries already queued.

Duplicates and ordering

X-Seegnals-Delivery is stable across retries of the same delivery; the timestamp and signature change with each attempt. Use the delivery id to deduplicate. Deliveries are independent, so a retried old event can arrive after a newer one; order by occurred_at if it matters.

Zapier

If your receiver is Zapier, use Webhooks by Zapier → Catch Hook as the trigger and filter on type. The full walk-through, including the action side (adding prospects from a Zap), is in Zapier.