Webhooks & Events API

What it does

The Webhooks & Events API is the push side of the platform: it manages subscriptions that make Reply POST a JSON payload to your URL every time an event fires. The management surface is ten operations — list, create, get, update (PUT), and delete subscriptions; enable and disable them without losing configuration; list the supported event types; send a test payload to a subscription’s URL; and read its delivery failure log. A subscription binds one eventType to one receiver URL, with a scope of personal (owner’s activity) or team (any team member), plus optional payload enrichment flags (email URL, email text, contact custom fields).

The event catalog covers the whole outreach loop: email engagement (email_sent, email_opened, email_link_clicked, email_replied, reply_categorized, email_bounced, email_auto_reply), email account health (email_account_connection_lost, email_account_error), LinkedIn (linkedin_connection_request_sent, linkedin_connection_request_accepted, linkedin_message_sent, linkedin_message_replied, linkedin_reply_categorized, linkedin_account_alerts), calls (contact_called), contact lifecycle (contact_finished, contact_opted_out), and sequence automation (autopilot_stopped).

Direction matters: the endpoints above are ordinary REST calls you make to Reply, but the deliveries are OUTBOUND — Reply POSTs to your endpoint. You need a publicly reachable https URL to receive them.

The problem it solves

A polling agent is always late and always wasteful. Checking the inbox every minute burns rate limit on empty responses and still reacts minutes after a prospect replies — which is exactly when interest is highest. Webhooks invert the flow: subscribe once, then react. A reply arrives, email_replied fires, the agent classifies the intent, drafts a response, and books the meeting — an event-driven pipeline instead of a polling loop. The same nervous system carries operational signals an agent should act on immediately: a bounce or opt-out prunes the contact list, email_account_connection_lost pauses sending before deliverability suffers, linkedin_account_alerts flags a channel that needs human attention, and autopilot_stopped tells the agent its evergreen sequence went quiet. If you cannot host an endpoint — a static agent with no server — the honest fallback is polling the Conversations & Inbox API; webhooks are strictly better only once you have somewhere for Reply to POST.

How an agent starts using it

Call GET /v3/webhooks/events to get the exact event type names, then POST /v3/webhooks with an eventType and your receiver url (scope webhooks:write). Verify the wiring with POST /v3/webhooks/{id}/test before relying on it, then handle the POSTs Reply sends to your endpoint. Use POST /v3/webhooks/{id}/enable and /disable (scope webhooks:operate) to pause during maintenance, and GET /v3/webhooks/{id}/logs (scope webhooks:read) when events stop arriving — it lists failed delivery attempts with event id, HTTP status, and timestamp. One subscription carries one event type, so an agent that needs replies, bounces, and opt-outs creates three subscriptions pointing at the same receiver.