Email SupportCall Us Go to Close

Retrieve Events

Retrieve a single event by ID.

GET /event/{id}/

The response contains a dictionary with a single event, using the format outlined in “Event format”.

Retrieve a list of events.

GET /event/{?date_updated__{lt|gt|lte|gte}, object_type, object_id, lead_id, action, user_id}

The list of available object types and actions is available here. The event log can be filtered by the following parameters:

  • date_updated: The date/time of when the event was last updated, in ISO format. Can be filtered by range (date_updated__gte=X&date_updated__lte=Y). Note: For pagination, it is recommended to use cursors instead of this filter (see below).
  • object_type: If specified, only events for objects of a given type are returned. Example: object_type=lead
  • object_id: If specified, only events for the given object are returned. No related object events are returned. Example: object_id=lead_123
  • action: Only events of specified actions are returned. Example: action=deleted
  • lead_id: If specified, events for the given lead, including any of its related objects (contacts, activities, opportunities, tasks) are returned.
  • user_id: Only return events of the given user.
  • request_id: Only events emitted while processing this specific API request.

Only certain combinations of filters are supported. date_updated can be optionally used with any allowed filter combination. Supported combinations are:

  • object_type and object_id
  • object_type and action
  • object_id and action
  • lead_id and object_type
  • lead_id, object_type and action
  • lead_id, user_id and object_type
  • lead_id, user_id, object_type and action
  • lead_id and user_id
  • user_id and object_id
  • user_id, object_id and action
  • user_id and object_type
  • user_id, object_type and action
  • Just lead_id
  • Just user_id
  • Just request_id

The response is a dictionary with the following fields:

  • data: A list of events (dictionaries), using the format outlined in “Event format”.
  • cursor_next: Cursor string to retrieve the next page of events, i.e. events before the given ID (earlier date), or null if no more objects are available.
  • cursor_previous: Cursor string to retrieve the previous page of events, i.e. events after the given ID (later date), or null if no more objects are available.

Events are always ordered by date (latest first), i.e. the date_updated field. Note that even though date_created and date_updated may only have millisecond-precision, two or more events for the same object are guaranteed to be returned in the proper order.

The endpoint supports the following parameters for pagination, and does not support _limit and _skip:

  • _cursor: Pagination using a cursor string (cursor_next or cursor_previous from a previous response). Note that you still need to supply any other filters (except for date_updated) that were used in the previous query.
  • _limit: Maximum number of events to return (capped at and defaulting to 50).

Cursors are a reliable way to go to the next or previous page of events (unlike filtering by date_updated, where you may need to account for and filter out multiple events happening in the same millisecond). However, cursors are not designed to stream new events: Events may be visible through the API in a different order than they were triggered (but the ordering returned by the API is correct). Also, event consolidation of multiple recent events to the same object may occur. To avoid missing recent events when paginating, we recommend to scan the latest five minutes of events.

In the example response, to retrieve the next older batch of events, specify _cursor=cursor2.