> ## Documentation Index
> Fetch the complete documentation index at: https://webhooks.docs.crm.africa/llms.txt
> Use this file to discover all available pages before exploring further.

# Grow CRM Webhooks: Getting Started with Real-Time Events

> Learn how Grow CRM Webhooks delivers events to your server — the payload envelope, retry schedule, auto-disable behaviour, and setup path.

Grow CRM Webhooks notifies your own server in real time whenever something happens in the CRM — an invoice is created, a lead converts, a payment comes in. You provide a destination URL and choose the events you care about; when those events occur, the CRM sends an HTTP POST request carrying a structured JSON payload. The Webhooks module is self-contained and does not require the API module to be installed.

## Where to manage webhooks

Navigate to **Settings → Webhooks → Endpoints** to manage all your webhook configuration. Each entry you create there is called an **endpoint** — a destination URL paired with a set of subscribed events. You can create as many endpoints as you need, and each one can subscribe to a different set of events.

## How delivery works

Delivery is **asynchronous**: creating an invoice, for example, is never slowed down by a webhook receiver being temporarily unavailable. Follow the steps below to understand exactly what happens between an event firing and your server receiving the payload.

<Steps>
  <Step title="Event is queued">
    When a subscribed event fires in the CRM, the system creates one **delivery** row per active, subscribed endpoint. Each delivery is independent.
  </Step>

  <Step title="Background process sends the delivery">
    A background process runs every minute and dispatches all due deliveries. Your server receives an HTTP POST with a JSON body.
  </Step>

  <Step title="Your server acknowledges">
    Respond with any `2xx` status code to mark the delivery as successful. Requests time out after **15 seconds**; anything other than a `2xx` — including a timeout — counts as a failure and triggers a retry.
  </Step>

  <Step title="Do slow work after responding">
    Acknowledge the delivery immediately and then process it asynchronously. A receiver that performs slow work before replying risks tripping the 15-second timeout, which causes a duplicate delivery on the next retry attempt.
  </Step>
</Steps>

## The payload envelope

Every delivery is a JSON object with the same four top-level fields regardless of which event fired or which resource it relates to.

```json title="Payload envelope" theme={null}
{
  "event": "invoice.created",
  "id": 295,
  "created": "2026-07-13T10:15:00+00:00",
  "data": {}
}
```

| Field     | Description                                                                                                                                                          |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `event`   | The event key, e.g. `invoice.created`. See the [Event reference](/events) for the full list.                                                                         |
| `id`      | The affected record's numeric id. The one exception is `<resource>.imported`, where `id` is the import's reference **string** rather than a numeric id.              |
| `created` | ISO 8601 timestamp indicating when the event was queued.                                                                                                             |
| `data`    | The record's data, shaped for the specific resource type. For deletion events, `data` contains only `{ "id": ... }` because the record no longer exists to describe. |

## Retry schedule

A failed delivery is retried up to two more times before being marked **Exhausted**. The three attempts follow this schedule:

| Attempt | Timing                               |
| ------- | ------------------------------------ |
| 1       | Immediately                          |
| 2       | +5 minutes after the first failure   |
| 3       | +30 minutes after the second failure |

## Auto-disable behaviour

If an endpoint accumulates **10 consecutive exhausted deliveries** with no successful delivery in between, Grow CRM automatically **disables** the endpoint and emails the CRM's main administrator. A disabled endpoint stops receiving new deliveries entirely until you re-enable it.

<Note>
  To re-enable a disabled endpoint, fix the underlying issue on your receiving server, then open the endpoint in **Settings → Webhooks → Endpoints**, and save it again. Saving reactivates the endpoint and new deliveries will resume immediately.
</Note>

## Next steps

<CardGroup cols={3}>
  <Card title="Endpoints" icon="plug" href="/endpoints">
    Create endpoints, subscribe to events, send test deliveries, and inspect the delivery log.
  </Card>

  <Card title="Verification" icon="shield-check" href="/verification">
    Validate every incoming request so you only process payloads that genuinely came from Grow CRM.
  </Card>

  <Card title="Event Reference" icon="list" href="/events">
    Browse all 15 resources, the five-key event model, discriminator fields, and import batch structure.
  </Card>
</CardGroup>