Webhooks in Crono

Crono Webhooks

Crono Webhooks let you subscribe to events in Crono and receive them on your own HTTP endpoint. They are useful for automations, integrations, and data synchronization with external systems.

Typical use cases include:

• triggering workflows in tools such as n8n

• notifying your backend when data changes in Crono

• synchronizing Crono activity with a CRM, BI pipeline, or internal service

1. Access and permissions

Where to create and manage Webhooks

When on Ultra/Enterprise plan - you can create and manage Webhooks from:

Settings → Integrations → Connections

https://app.crono.one/settings/integrations/api

Who can manage webhooks

Webhooks are configured at subscription level. Users with Manager permissions and above are able to manage these settings:

• create webhooks

• edit existing webhooks

• disable or re-enable them

• delete them

Subscription limit

Each subscription can have up to 3 webhooks.

A single webhook can subscribe to multiple events, so you usually do not need one webhook per event.

2. Creating a webhook

When creating a webhook, you configure:

• a name

• a destination URL

• one or more events

• a throttling value

https://app.crono.one/settings/integrations/api/webhook/new

Webhook name

Use a descriptive name that makes the purpose of the integration easy to understand.

Examples:

• n8n automation

• CRM sync

• Internal event processing

• Opportunity updates

Destination URL

This is the endpoint that Crono will call when one of the selected events occurs.

Examples:

• https://api.yourcompany.com/webhooks/crono

• https://hooks.yourdomain.com/crono

• https://your-workspace.app.n8n.cloud/webhook/crono

The endpoint must be able to accept:

• HTTP POST

• JSON payloads

Suggested integration patterns

Simple automation pattern

You can connect Crono directly to an automation platform such as n8n.

Example flow:

1. Crono sends the event to your n8n endpoint

2. n8n receives the payload

3. the workflow triggers follow-up actions, such as notifications, data updates, or external API calls

Backend plus async processing pattern

For more robust integrations, a common pattern is:

1. Crono sends the webhook to your backend

2. your backend validates and accepts the request

3. your system stores the payload or sends it to a queue

4. background workers process the event asynchronously

This is generally recommended when processing may be slow or when several downstream systems depend on the same events.

3. Events you can subscribe to

Each webhook can subscribe to one or more events. Crono currently supports the following event categories and event types. The valid object and event combinations are defined in the backend event map

3.1 Account events

• Account created

• Account updated

• Account deleted

3.2 Prospect events

• Prospect created

• Prospect updated

• Prospect deleted

3.3 Opportunity events

• Opportunity created

• Opportunity updated

• Opportunity deleted

3.4 Lead events

• Lead created

• Lead updated

• Lead deleted

3.5 Strategy events

• Strategy completed

• Strategy prospect replied

3.6 Signal events

• Role changed

• Company changed

• Website visit

• Interested open

• Interested click

• Hiring

3.7 Notification events

• Email replied

• Email opened

• Email clicked

• LinkedIn replied

• LinkedIn invitation accepted

• LinkedIn InMail replied

• LinkedIn voice note replied

The event types exposed by the system include Create/Delete/Update events for Account, Prospect, Opportunity, and Lead (if you are integrated with Salesforce), plus Strategy, Signal, and Notification events such as StrategyCompleted, SignalWebsiteVisit, and NotificationLinkedinInvitationAccepted

Update events

For update events, Crono can also provide the list of fields that changed. This is useful if your integration only needs to react to specific updates rather than every modification. Support for property-level filtering is documented on EntityUpdated events

4. Throttling

Throttling controls how Crono groups events before sending them.

Instead of always sending one request per event, Crono can group multiple events into a single delivery.

Allowed values

You can configure throttling from 0 to 10.

What each value means

• 0: no batching, events are sent individually

• 10: up to 10 events can be grouped into one delivery

Example

If throttling is set to 10:

• Crono can group up to 10 events into the same request

• if fewer events are available, Crono may still send a smaller batch after a timeout of 5 minutes if the batch of events hasn’t reached the throttling limit yet, this is called Flush Timeout, described below

Flush timeout

Crono applies a flush timeout so that events are not held indefinitely while waiting for a batch to fill.

In practice, this means:

• if the batch reaches the throttling threshold, it is sent

• if the threshold is not reached in time, Crono still sends the events collected so far

Guidance

Use a lower throttling value when:

• you need near real-time processing

• each event should be handled immediately

• your endpoint expects one event at a time

Use a higher throttling value when:

• event volume is higher

• your receiver can process events in batches

• you want to reduce the number of incoming HTTP requests

5. Retry behavior

Crono supports configurable retries for failed deliveries, up to 5 attempts.

Retries use increasing delays between attempts.

Retry schedule

When the maximum retry policy is enabled, the delivery schedule is:

• Attempt 1: immediate

• Attempt 2: after 1 minute

• Attempt 3: after 5 minutes

• Attempt 4: after 30 minutes

• Attempt 5: after 2 hours

When Crono retries

Crono retries a delivery only for temporary failures, such as:

• timeout or network failure

• HTTP 429

• HTTP 5xx

When Crono does not retry

Crono does not retry for HTTP 4xx responses other than 429.

This means no retry is expected for responses such as:

• 400 Bad Request

• 401 Unauthorized

• 403 Forbidden

• 404 Not Found

• 405 Method Not Allowed

• 409 Conflict

• 422 Unprocessable Entity

These rules are enforced in the delivery logic: retries are allowed for network errors, 429, and 5xx, while other 4xx responses are treated as non-retryable failures

What your endpoint should return

Your endpoint should return a 2xx response when the request has been received successfully.

A common best practice is to accept the request quickly, persist or enqueue it, and process it asynchronously.

6. Delivery format

Crono sends webhook deliveries as:

• HTTP POST

• JSON payload

• REST-style request

Your endpoint should therefore be able to:

• accept POST requests

• parse JSON

• return a 2xx response when the delivery is accepted successfully

7. Custom headers

Each delivery includes custom headers that help you identify and validate the request.

x-crono-delivery-id

Example:

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

This is the unique identifier of the delivery batch. It can be used for:

• tracing deliveries in your logs

• deduplication

• idempotency handling

• troubleshooting

The delivery header names are defined in the webhook delivery headers used by Crono, including X-Crono-Delivery-Id

x-crono-webhook-secret

Example:

x-crono-webhook-secret: 2c246a0412e1b092d37a3b388821970650f40e1a0fa81db64fd3f07088fbb545

This is the unique secret associated with the webhook. It can be used by your system to validate that the request was sent by Crono.

Crono includes X-Crono-Webhook-Secret among the custom outbound delivery headers

Note

The backend support for this exists. User-facing configuration and UX around this can still evolve, so this part should be considered subject to future refinement.

8. Payload structure

Crono sends webhook deliveries inside a batch wrapper.

This means the JSON body is not just a single event object. It includes:

• delivery-level information

• one or more events

Even when only one event is sent, the payload still follows the same batch structure. The batch envelope always includes BatchId, EventCount, IsBatch, Timestamp, and Events

8.1 Wrapper fields

batchId

A unique identifier for the delivery batch.

Use it to:

• correlate logs

• detect duplicate deliveries

• safely handle retries

The backend model describes it as the unique identifier for the batch delivery, shared across all retry attempts

eventCount

The number of events included in the payload.

If throttling is disabled or set to a very low value, this will usually be 1.

If throttling is enabled, this can be greater than 1.

isBatch

A boolean flag that indicates whether the delivery contains multiple events.

timestamp

The UTC timestamp representing when the payload was assembled for delivery.

events

An array containing the events included in the webhook delivery.

8.2 Event fields

Each item in events includes these fields:

• eventType

• objectType

• data

• propertiesUpdated

• occurredAt

This structure is defined by the event payload model used for outbound deliveries

eventType

The type of event that occurred, such as created, updated, deleted, or another supported event.

objectType

The Crono object related to the event, such as Account, Prospect, Opportunity, Lead, Strategy, Signal, or Notification.

data

The main payload for that event.

This contains the object data relevant to the event. The exact fields depend on the object type.

propertiesUpdated

For update events, this contains the list of fields that changed.

For create or delete events, this is typically empty or not relevant.

occurredAt

The UTC timestamp indicating when the event occurred.

9. Example payloads

When you configure a webhook and subscribe it to one or more events, Crono shows example payloads for the selected event subscriptions. These examples are generated during webhook setup so you can understand the structure your endpoint should expect.

In order to open specific example payload - just click on the event inside webhook after it’s been created - the side panel with payload will appear

Example: single-event delivery

{
  "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": "[email protected]",
        "firstName": "Jane",
        "lastName": "Doe"
      },
      "propertiesUpdated": null,
      "occurredAt": "2026-04-23T10:14:10Z"
    }
  ]
}

Example: batched delivery

{
  "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

Design your endpoint for batch payloads

Even if you initially configure throttling as 0 or 1, your endpoint should still be able to process an array of events.

Return a 2xx response quickly

Do not keep the webhook request open while performing long business operations.

A better approach is:

1. receive the request

2. validate it

3. store or enqueue it

4. return a 2xx

5. process it asynchronously

Use the delivery ID for idempotency

The delivery ID can help you avoid processing the same delivery more than once.

Subscribe only to the events you need

Avoid subscribing to unnecessary events if your integration only depends on a smaller subset.

11. Summary

Crono Webhooks allow you to send Crono events to your own systems through HTTP POST requests with JSON payloads.

To use them correctly:

• create them from Settings > Integrations > APIs & Webhooks

• choose a clear name and a valid destination URL

• subscribe to the events you need

• configure throttling based on your volume and latency needs

• return 2xx responses when deliveries are accepted

• support batch payloads, not only single events

• use the custom headers and delivery ID for validation and troubleshooting