---
title: "Webhooks in Crono"
description: "Subscribe to events in Crono and receive them on your own endpoint: setup, events, throttling, retries and payloads."
url: https://help.crono.one/it/articles/73-webhooks-in-crono
collection: "Connections"
updated: 2026-09-14
language: it
alternates: [en]
---

# Webhooks in Crono

Subscribe to events in Crono and receive them on your own endpoint: setup, events, throttling, retries and payloads.

Crono Webhooks let you subscribe to events in Crono and receive them on your own HTTP endpoint. They are useful for automations, integrations and keeping other systems in step with what happens in Crono.

Typical uses:

-   Triggering workflows in a tool such as n8n
    
-   Notifying your own backend when data changes in Crono
    
-   Synchronising Crono activity with a CRM, a BI pipeline or an internal service
    

* * *

## 1\. Access and permissions

### Where to create and manage webhooks

Webhooks are available on **Ultra and Enterprise**. If you are on another plan and need them, get in touch — they can be enabled for an individual workspace on request.

You will find them under **Settings → Integrations → Connections**: [app.crono.one/settings/integrations/api](https://app.crono.one/settings/integrations/api)

![](https://staticfiles.gleap.io/gattachments/Kpmh6LUKXypH3Q3FG7SjA6oknM8r6aOLSVXJSACkhTjn7gABq1xIKpCSiY8yDY0KzUxZSTuTQFu.png)

### Who can manage them

Webhooks are configured at subscription level. Users with **Manager** permissions and above can create them, edit them, disable and re-enable them, and delete them.

### Subscription limit

Each subscription can have up to **3 webhooks**. A single webhook can subscribe to many events, so you rarely need one per event.

* * *

## 2\. Creating a webhook

When you create one you configure a **name**, a **destination URL**, one or more **events**, and a **throttling value**: [create a new webhook](https://app.crono.one/settings/integrations/api/webhook/new)

![](https://staticfiles.gleap.io/gattachments/VBxVfubOV4417oWEyyPk8hzBSQrb8GswKGKPqdvWmCtJGbnBhi7KXWDTJ0jYh1qa62fa9VYVi4L.png)

### Name

Use something that makes the purpose obvious later — "n8n automation", "CRM sync", "Opportunity updates".

### Destination URL

The endpoint Crono calls when one of your chosen events happens — for example `https://api.yourcompany.com/webhooks/crono` or an n8n webhook URL.

It must accept **HTTP POST** with a **JSON payload**.

### Two ways people wire this up

**Straight into an automation platform.** Crono sends the event to your n8n endpoint, n8n receives the payload, and the workflow triggers whatever follows — notifications, data updates, calls to other APIs.

**Into your own backend, processed asynchronously.** Crono posts to your service, which validates and accepts the request, stores it or puts it on a queue, and lets background workers do the actual work. Worth the extra effort when processing is slow or several downstream systems depend on the same events.

* * *

## 3\. Events you can subscribe to

Each webhook can subscribe to one or more of the following.

_Before you read the list:_ event names use the API's object names, not the ones in the Crono interface. A **Company** is an **Account**, a **Contact** is a **Prospect**, a **Deal** is an **Opportunity**, and a **Sequence** is a **Strategy**. See [Crono object names: interface vs API](https://help.crono.one/en/articles/100-crono-object-names-interface-vs-api.md).

### Account events (companies)

-   Account created, updated, deleted
    

### Prospect events (contacts)

-   Prospect created, updated, deleted
    

### Opportunity events (deals)

-   Opportunity created, updated, deleted
    

### Lead events — Salesforce only

Lead created, updated and deleted fire **only if your workspace is integrated with Salesforce**. There is no Lead object in the Crono interface, so if you are not on Salesforce you can ignore these entirely.

### Strategy events (sequences)

-   Strategy completed
    
-   Strategy prospect replied
    

### Signal events

-   Role changed, company changed, website visit, hiring
    
-   Interested open, interested click
    

### Notification events

-   Email replied, opened, clicked
    
-   LinkedIn replied, invitation accepted, InMail replied, voice note replied
    

### Update events

For update events Crono also tells you **which fields changed**, in the `propertiesUpdated` array. Useful when your integration only cares about certain fields rather than every edit.

* * *

## 4\. Throttling

Throttling controls how Crono groups events before sending them. Instead of one request per event, it can batch several into a single delivery.

You can set it from **0 to 10**. **0** means no batching — events go out individually. **10** means up to ten events can share one delivery.

### Flush timeout

Events are never held indefinitely waiting for a batch to fill. If the batch reaches your threshold it is sent; if it does not, Crono sends what it has collected after **5 minutes**.

### Which value to choose

Go **lower** when you need near real-time processing, each event should be handled immediately, or your endpoint expects one event at a time.

Go **higher** when volume is high, your receiver can handle batches, or you want fewer inbound HTTP requests.

* * *

## 5\. Retries

Crono retries failed deliveries up to **5 attempts**, with increasing delays:

-   **Attempt 1** — immediate
    
-   **Attempt 2** — after 1 minute
    
-   **Attempt 3** — after 5 minutes
    
-   **Attempt 4** — after 30 minutes
    
-   **Attempt 5** — after 2 hours
    

**Crono retries** on temporary failures: a timeout or network error, an **HTTP 429**, or any **5xx**.

**Crono does not retry** on any other **4xx** — 400, 401, 403, 404, 405, 409 and 422 are all treated as permanent failures. If your endpoint rejects a delivery with one of those, that event is gone; it will not come back.

Return a `2xx` as soon as you have received the delivery. Accept it, store or queue it, and process it afterwards — rather than holding the request open while you work.

* * *

## 6\. Delivery format

Every delivery is an **HTTP POST** carrying a **JSON payload**. Your endpoint needs to accept POST, parse JSON, and return 2xx on success.

* * *

## 7\. Custom headers

Each delivery carries two headers you can use to identify and validate it.

### `x-crono-delivery-id`

```javascript
x-crono-delivery-id: 35dfc8b5-bf2e-41df-8706-758aaa42a8b1
```

The unique identifier of the delivery batch. Use it for tracing in your logs, deduplication, idempotency and troubleshooting. It stays the same across retry attempts, which is what makes it useful for idempotency.

### `x-crono-webhook-secret`

```javascript
x-crono-webhook-secret: 2c246a0412e1b092d37a3b388821970650f40e1a0fa81db64fd3f07088fbb545
```

The secret associated with that webhook. Check it on arrival to confirm the request genuinely came from Crono rather than from someone who found your endpoint URL.

* * *

## 8\. Payload structure

Deliveries arrive inside a **batch wrapper**, so the body is never a bare event object. Even a single event uses the same batch structure — design for that from the start.

### Wrapper fields

-   `batchId` — unique identifier for the delivery, shared across all retry attempts. Use it to correlate logs and detect duplicates.
    
-   `eventCount` — how many events are in this payload.
    
-   `isBatch` — whether the delivery contains more than one event.
    
-   `timestamp` — UTC timestamp of when the payload was assembled.
    
-   `events` — the array of events.
    

### Event fields

-   `eventType` — what happened: created, updated, deleted, or a named event.
    
-   `objectType` — the object involved: Account, Prospect, Opportunity, Lead, Strategy, Signal or Notification.
    
-   `data` — the object data for that event. Fields depend on the object type.
    
-   `propertiesUpdated` — for updates, which fields changed. Empty or null for creates and deletes.
    
-   `occurredAt` — UTC timestamp of when the event happened.
    

* * *

## 9\. Example payloads

Crono shows you an example payload for each event you subscribe to. Click the event inside the webhook after creating it and the example opens in a side panel.

![](https://staticfiles.gleap.io/gattachments/Z4l7kSi3uN0yTQdFtphaooIzYyA0MvAMD3blOVh6MVk23xWmEmxg99iUXYEzPQhcWqJlQfpft5h.png)

### Single-event delivery

```json
{
  "batchId": "35dfc8b5-bf2e-41df-8706-758aaa42a8b1",
  "eventCount": 1,
  "isBatch": false,
  "timestamp": "2026-04-23T10:15:00Z",
  "events": [
    {
      "eventType": "EntityCreated",
      "objectType": "Prospect",
      "data": {
        "objectId": "prospect_123",
        "email": "jane@company.com",
        "firstName": "Jane",
        "lastName": "Doe"
      },
      "propertiesUpdated": null,
      "occurredAt": "2026-04-23T10:14:10Z"
    }
  ]
}
```

### Batched delivery

```json
{
  "batchId": "e72e6c4a-8c46-47c1-8d4d-6f6f79b4f1b2",
  "eventCount": 2,
  "isBatch": true,
  "timestamp": "2026-04-23T10:20:00Z",
  "events": [
    {
      "eventType": "EntityUpdated",
      "objectType": "Account",
      "data": {
        "objectId": "account_1001",
        "name": "Acme Inc"
      },
      "propertiesUpdated": ["name"],
      "occurredAt": "2026-04-23T10:19:10Z"
    },
    {
      "eventType": "NotificationEmailReplied",
      "objectType": "Notification",
      "data": {
        "objectId": "notification_2001"
      },
      "propertiesUpdated": null,
      "occurredAt": "2026-04-23T10:19:25Z"
    }
  ]
}
```

* * *

## 10\. Best practices

-   **Handle batches from day one.** Even with throttling at 0 or 1, expect an array of events.
    
-   **Return 2xx quickly.** Receive, validate, store or enqueue, respond, then process. Do not keep the request open through long operations.
    
-   **Use the delivery ID for idempotency.** It is stable across retries, so it is your defence against processing the same delivery twice.
    
-   **Subscribe only to what you need.** Fewer events means less noise and less to reason about when something goes wrong.
    

* * *

## 11\. Summary

Crono Webhooks push Crono events to your own systems as HTTP POSTs with JSON payloads. To use them well:

-   Create them under **Settings → Integrations → Connections**
    
-   Give each one a clear name and a valid destination URL
    
-   Subscribe only to the events you actually need
    
-   Set throttling to match your volume and latency requirements
    
-   Return 2xx on receipt, and support batch payloads rather than single events
    
-   Use the delivery ID and the webhook secret for validation and troubleshooting