Skip to content
English
More support
Submit Ticket
  • There are no suggestions because the search field is empty.

Rhythm API Event Subscriptions

Rhythm can notify an integration when plan data changes, instead of the integration polling for changes.

Today, event subscriptions deliver to Zapier only. If you want Rhythm changes to start a workflow in another tool, use the Rhythm integration in Zapier, which handles subscriptions for you. See Integrate Using Zapier + Rhythm.

Delivery contract

For reference, the contract Zapier uses:

  • A subscription pairs one event with one delivery URL. Events are named {entity}.{action}, for example kpi.created, task.updated, comment.deleted, or kpi_status.created.
  • On each matching change, Rhythm sends a POST to the delivery URL with a JSON envelope:
{
  "event": "task.updated",
  "event_id": "{unique_per_delivery}",
  "created_at": "2026-09-21T14:03:11.482Z",
  "data": { "id": "…", "name": "…" }
}
  • event_id is a UUID, unique per delivery, and is the value to de-duplicate on. created_at is UTC, ISO 8601 with a Z suffix. data.id is the item's ID and repeats across updates to the same item.
  • For *.deleted events, data carries only the item's id and name (and, for comments, parentEntityId).
  • Deliveries are filtered by the permissions of the user who created the subscription. That user's subscription never receives items they could not view in Rhythm.
  • Failed deliveries are retried a small number of times with increasing delay. A 410 Gone response tells Rhythm the receiver is no longer listening and the subscription is removed. Repeated failures deactivate the subscription.

Deliveries carry the same data shapes as the corresponding v2 API responses. See the Rhythm API Overview for response conventions and permissions.