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.
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).
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.
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.
See the API Reference for the full parameter list for each endpoint.
Pagination
All list endpoints use cursor-based pagination. Each paginated response includes apagination object that tells you whether more results exist and where to continue from.
Parameters
How it works
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.
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.
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. UseupdatedAfter and updatedBefore to fetch only what has changed since your last sync:
updatedAfter set to the time of your last successful sync.
Tips for efficient polling:
- Use
limit=500to minimize the number of requests. - Store the timestamp of each successful sync and use it as
updatedAfteron 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).