Skip to main content
Everything you can see in the follow-ups list view is also available through our public API. Use it to sync follow-ups into a data warehouse, mirror them in an internal tracker, or build reporting that we don’t offer natively.

​
What you can do

The Follow-ups V3 API covers the full lifecycle of a follow-up:

​
List and filter follow-ups

You can list follow-ups across your organization. Results are paginated, and you can filter by incident, assignee team, and the created_at and updated_at timestamps. The timestamp filters are what make incremental syncing possible, which we cover below.

​
Create and update follow-ups

You can create follow-ups against an incident, update them (title, description, status, assignee, priority, labels), and delete them. Use the show endpoint to fetch a single follow-up.

​
Connect external issues

If you track follow-up work in your issue tracker, you can connect a follow-up to an existing issue by its URL. The follow-up then carries a reference to that issue, and we keep its status in sync.

​
Keeping follow-ups in sync

The most common use of this API is keeping an external system up to date with your follow-ups. Rather than re-fetching everything on a schedule, do an initial full import and then poll for changes. For the initial import, page through the full list:
Each response includes a pagination_meta object. If it contains an after cursor, pass that to the next request to get the next page. When after is missing, you have reached the end. From then on, poll with updated_at[gte] set to when you last synced:
This returns only the follow-ups that changed since your last sync, so a poll usually returns a handful of rows instead of your whole history. Two things to account for in your sync logic:
  • Overlap your window. Timestamps are stamped just before a write commits, so a follow-up can occasionally become visible with an updated_at slightly older than rows you have already seen. Set your updated_at[gte] bound a few minutes earlier than your last sync time and treat re-fetched rows as upserts.
  • Embedded objects don’t bump updated_at. The timestamp moves when the follow-up itself changes. Changes to things embedded in the payload, like an assignee being renamed or an external issue’s status text, don’t move it. If you need those fresh too, run an occasional full re-sync.

​
Getting started

Check out our API reference for the full details on authentication, pagination, and response formats. Here are the direct links to the follow-up endpoints: