Returns a paginated list of responses. By default, responses are ordered by their inserted_at timestamp in reverse chronological order. Use the sort parameter to change the ordering direction.

Pagination

Pagination of the results is cursor-based, using the ending_before or starting_after query parameter. To fetch the next page of results, provide the id of the last response returned as the value of the starting_after query parameter. To fetch the previous page of results, provide the id of the first response returned as the value of the ending_before query parameter. To aid in pagination, the response body includes prev and next properties whose values are the full URL (including filters) of the previous and next pages of results respectively.

🚧

starting_after and ending_before are mutually exclusive

The starting_after and ending_before query parameters cannot be used simultaneously.

Filtering by time

Use inserted_at_min and inserted_at_max to narrow results to a specific time window. Both accept ISO 8601 UTC timestamps and can be combined with cursor pagination.

Sorting

The sort parameter controls the ordering direction. Allowed values:

The cursor parameters (starting_after / ending_before) walk in the active sort direction.

Filtering and sorting by updated_at

The updated_at_min, updated_at_max, and sort=updated_at_* parameters behave like their inserted_at_* counterparts but operate against the response's updated_at field - useful for re-syncing responses that were recategorized in the Fairing UI.

Migrating from legacy parameter names

A previous version of this endpoint used parameter names like since, until, after, and before. Those names are still accepted, but new integrations should use the canonical names below - they're more explicit, they are what prev and next URLs use in every response, and they are the only names that support the new sort parameter.

Parameter mapping

Side-by-side examples

Fetching a date window:

# Before
GET /api/responses?since=2026-05-01T00:00:00Z&until=2026-05-31T23:59:59Z

# After
GET /api/responses?inserted_at_min=2026-05-01T00:00:00Z&inserted_at_max=2026-05-31T23:59:59Z

Paginating forward through results:

# Before
GET /api/responses?after=ENz45Kvbxru0B5X6kDN7Y

# After
GET /api/responses?starting_after=ENz45Kvbxru0B5X6kDN7Y

Combined filter + cursor:

# Before
GET /api/responses?since=2026-05-01T00:00:00Z&after=ENz45Kvbxru0B5X6kDN7Y&limit=50

# After
GET /api/responses?inserted_at_min=2026-05-01T00:00:00Z&starting_after=ENz45Kvbxru0B5X6kDN7Y&limit=50

What stays the same, what's new

Behavior, defaults, response shape, and the id value you pass as a cursor are all unchanged. Two things are only available through the canonical surface:

• The sort parameter (default inserted_at_desc) - there is no legacy equivalent. See the Sorting section.
• The updated_at_min / updated_at_max parameters and sort=updated_at_* options.

When both names are sent in the same request

If a request includes both a legacy name and its canonical equivalent (e.g. ?since=…&inserted_at_min=…), the canonical value wins, and the legacy one is ignored. We don't recommend sending both — pick one per request — but if your code is mid-migration, the resolution is deterministic, so you won't be surprised.

Tip: pagination URLs auto-migrate

The prev and next URLs in every response always use canonical names, regardless of which names your request used. So if your pagination loop just follows the next URL the API hands back (rather than constructing the next URL itself), your second page onwards is already on the canonical names — even if your first request used since / after. For most integrations, the only place you actually need to change parameter names is the initial request that kicks off pagination.