Events are important things that happen in a workspace. These are usually tied to actions taken. For example, an email being sent, a lead replying, etc.
When you add a webhook listener and give us a URL to send to, we pass over raw event data.The event payload matches the webhook payload exactly.You can see events for the past 10 days with all of their payloads, webhook deliveries, and webhook attempts. From the UI, navigate to Settings -> Events. Or, you could use the /api/events endpoint.
A webhook delivery is a single delivery to a single webhook listener. For example, say that you have 3 total URLs you want to receive a lead replied webhook to. This would translate to 3 specific webhook deliveries from our side. An ‘Event’ can have multiple webhook deliveries tied to it, with each delivery being tied to a webhook listener URL that you’ve defined. Webhook deliveries can be managed per event through: Settings -> Events -> Webhook Deliveries, or via the API.
A webhook attempt is our attempt to send the event to your registered webhook URL. Therefore, a webhook delivery can have multiple “attempts.”Ideally, if your webhook listener URL responds with a 200 code, you will only see 1 attempt per webhook delivery.But in cases where your listener might be timing out, or returning an unsuccessful (eg non 200 response code), there will be multiple attempts made. If an attempt receives no reponse in 15 seconds, it will time out.If you ever have downtime on your listeners, you can play back these attempts by “resending” the webhook attempt to your URL.This is possible via the UI in settings -> events -> webhook deliveries -> manage -> resend webhook attempt, or via the API.We strongly recommend playing webhook events via the API by filtering for events given a start and end date, and then calling the resend endpoint on the webhook_attempt_id.
