Skip to content

Part 3 · Operate

Webhooks

Send your signals to your own tools: a signed POST to a URL you choose each time something happens, with a log of what your server answered.

01What it is

Settings, Webhooks takes an https address and the events it should hear about, and gives you a signing secret once. Each event is posted to that address as JSON, signed, and retried if your server does not answer. The log under it lists every attempt with your server's reply, and Send a test posts a test event to an endpoint on the spot.

Five of the events are signal events, made for a Clay table, a CRM workflow or a Zapier zap: engager.new (somebody engaged with your posts for the first time), account.changed (a company you watch changed), mention.new (a public thread matched what you sell), deal.created and deal.stage_changed. Settings, Webhooks offers them on every account. The full list of events is in the reference.

02Why it exists

A tool that fed your Clay table or your CRM can stop, and nothing tells you: the table just stops growing. A webhook you own, from the place your signals already live, means the workflow you built keeps its source, and a receiver that stops answering gets switched off and you get an email rather than silence.

Every payload is your own venture's data going to an address your workspace added. A webhook never contacts a person; it tells your tools something happened.

03How to use it

  1. 01Open Settings, Webhooks. Paste the https address your tool gave you, name it, tick the events it should hear, and press Add the endpoint. Copy the signing secret now: it is shown once.
  2. 02Press Send a test. The line under the endpoint says what your server answered; any 2xx counts as delivered.
  3. 03Clay: in a workbook, press Add, search Webhooks and choose Monitor webhook. Copy the URL Clay shows and paste it here. Send a test so the table has a first record to build columns from. Clay counts submissions per webhook source and asks for a new webhook past its limit, unless your plan deletes rows as they are processed.
  4. 04Zapier: start a Zap with Webhooks by Zapier and the Catch Hook event, then copy the URL from the Test tab and paste it here. Send a test, then press Test trigger in Zapier so the fields are ready for the next steps. Zapier offers Webhooks by Zapier on its paid plans only.
  5. 05Make: add the Custom webhook module from Webhooks, press Add next to Webhook, name it and save, then copy the URL. Run the scenario once and send a test so Make can read the fields; Detect new values reads them again after a change.
  6. 06Your own server: check the signature before you trust a request. It is HMAC-SHA256 of the Webhook-Id, the Webhook-Timestamp and the body, joined with dots, sent as v1= in Webhook-Signature. Refuse a timestamp more than five minutes old and treat a repeated Webhook-Id as the same event.

04What good looks like

You give it
An endpoint subscribed to deal.stage_changed, with signal webhooks on, and the founder moving a deal from conversation to proposal sent.
You get
One signed POST whose data carries the deal id, title, stage proposal_sent, from_stage conversation, the value, the reason and moved_by founder, with schema_version, logged as delivered with the server’s 200.
Why
The move commits first, then the event is checked against its published schema and queued for each endpoint of that workspace that asked for it.

Derived from the rules in the code

05What weak looks like, and what it costs

You give it
An endpoint whose server answers 500 to every event for a day.
You get
Each event is tried again after a back-off and then given up; after enough events fail every attempt in a row the endpoint is switched off, the reason shows beside it, and the workspace owner is emailed.
Why
A dead receiver retried forever fills a queue nobody reads; switching it off and saying so is the only honest end.

Derived from the rules in the code

06Read next