Skip to main content

​
Datasets

The Quartr API provides access to datasets that can be purchased individually or as a bundle. The events and companies endpoints are always available and contain metadata that makes it easier to work with other datasets. Most list endpoints share the same query parameters for company filtering, date ranges, update tracking, and pagination. This page covers how they work.

​
Common query parameters

​
Company filters

Every list endpoint supports filtering by company identifiers. All filters use AND logic when combined across parameters and OR logic within each parameter. For example, tickers=AAPL,AMZN&countries=US returns companies that match any of the listed tickers AND are domiciled in any of the listed countries.
ParameterDescriptionExample
companyIdsQuartr internal company IDs4742,5123
tickersTicker symbolsAAPL,AMZN
isinsISIN codesUS0378331005
ciksSEC Central Index Keys0000320193,0001018724
openfigisOpenFIGI codesBBG000B9XRY4,BBG001S5N8V8
countriesISO 3166-1 alpha-2 country codesUS,SE
exchangesExchange symbolsNasdaqGS,NYSE
All values are comma-separated. The companies endpoint uses ids instead of companyIds since the resource itself is a company.

​
Date ranges

Most endpoints support filtering by the date of the underlying content (e.g. the event date or document publication date).
ParameterDescriptionExample
startDateReturn records on or after this date2025-01-01T00:00:00Z
endDateReturn records on or before this date2025-03-31T23:59:59Z
Both use ISO 8601 format. These filter on the event date, not on when it was added to our system.

​
Update filters

All list endpoints support filtering by when records were last modified.
ParameterDescriptionExample
updatedAfterReturn records updated after this time2025-03-01T00:00:00Z
updatedBeforeReturn records updated before this time2025-03-15T00:00:00Z
These timestamps pertain to the resource itself. Changes to related resources are not reflected. For example, if a document linked to an event is updated, the event’s updatedAt timestamp does not change. These are the key parameters for incremental syncing. See Keeping data in sync below.

​
Endpoint-specific parameters

Some endpoints have additional filters beyond the shared set.
EndpointExtra parameters
EventstypeIds, sortBy
DocumentstypeIds, eventIds, expand
AudioeventIds, expand
LiveeventIds, states , transcriptVersion
See the API Reference for the full parameter list for each endpoint.

​
Pagination

All list endpoints use cursor-based pagination. Each paginated response includes a pagination object that tells you whether more results exist and where to continue from.

​
Parameters

ParameterDescriptionDefault
limitNumber of results per page10
cursorCursor value from a previous response0
directionSort direction by ID: asc or descasc

​
How it works

{
  "data": [...],
  "pagination": {
    "nextCursor": 4521
  }
}
Pass nextCursor as the cursor parameter in your next request to fetch the next page. When nextCursor is null, you have reached the end of the result set. 
# First page
curl "https://api.quartr.com/public/v3/events?limit=100"

# Next page
curl "https://api.quartr.com/public/v3/events?limit=100&cursor=4521"
Cursor values are opaque identifiers. Don’t assume they are sequential or that you can calculate them. Always use the nextCursor value from the previous response.

​
Timestamps

All timestamps in the API use UTC and are formatted as ISO 8601 strings. Every record has two timestamp fields.
FieldMeaning
createdAtWhen the record was first added to our system
updatedAtWhen the record or its related data was last modified
These reflect system time when the record was added or modified, not the actual date of the event. A historical earnings call from 2022 that was ingested in 2024 will have a createdAt in 2024. For the actual date of an event, use the event’s date field. The updatedAt field covers changes to the resource and its direct attributes. For companies, this includes the company record itself and its identifiers (tickers, ISINs, CIKs). For events, it reflects changes to event metadata only, updates to documents or audio linked to an event do not change the event’s updatedAt. To track changes across related resources, query each endpoint separately using updatedAfter.

​
Keeping data in sync

​
Polling

Polling works well if you need data on a schedule and can tolerate some delay. Use updatedAfter and updatedBefore to fetch only what has changed since your last sync: 
# Fetch all events updated since your last sync
curl "https://api.quartr.com/public/v3/events?updatedAfter=2025-03-01T00:00:00Z&limit=500"
To build or backfill a full local copy, paginate through the entire dataset without update filters, then switch to incremental polling using updatedAfter set to the time of your last successful sync. Tips for efficient polling:
  • Use limit=500 to minimize the number of requests.
  • Store the timestamp of each successful sync and use it as updatedAfter on the next run.
  • Poll less frequently for datasets that change infrequently (e.g. companies) and more often for fast-moving ones (e.g. live data).

​
Webhooks

Webhooks push updates to you in real time, eliminating polling delay entirely. They are ideal for live audio, live transcripts, and any workflow where latency matters. Even with webhooks, implement a periodic polling fallback to catch any events you may have missed due to network issues or downtime.