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.
| Parameter | Description | Example |
|---|
| companyIds | Quartr internal company IDs | 4742,5123 |
| tickers | Ticker symbols | AAPL,AMZN |
| isins | ISIN codes | US0378331005 |
| ciks | SEC Central Index Keys | 0000320193,0001018724 |
| countries | ISO 3166-1 alpha-2 country codes | US,SE |
| exchanges | Exchange symbols | NasdaqGS,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).
| Parameter | Description | Example |
|---|
| startDate | Return records on or after this date | 2025-01-01T00:00:00Z |
| endDate | Return records on or before this date | 2025-03-31T23:59:59Z |
Update filters
All list endpoints support filtering by when records were last modified.
| Parameter | Description | Example |
|---|
| updatedAfter | Return records updated after this time | 2025-03-01T00:00:00Z |
| updatedBefore | Return records updated before this time | 2025-03-15T00:00:00Z |
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.
| Endpoint | Extra parameters |
|---|
| Events | typeIds, sortBy |
| Documents | typeIds, eventIds, expand |
| Audio | eventIds, expand |
| Live | eventIds, states , transcriptVersion |
pagination object that tells you whether more results exist and where to continue from.
Parameters
| Parameter | Description | Default |
|---|
| limit | Number of results per page | 10 |
| cursor | Cursor value from a previous response | 0 |
| direction | Sort direction by ID: asc or desc | asc |
How it works
{
"data": [...],
"pagination": {
"nextCursor": 4521
}
}
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.
| Field | Meaning |
|---|
| createdAt | When the record was first added to our system |
| updatedAt | When the record or its related data was last modified |
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"
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.
