Frequently asked questions
Check out our frequently asked questions below or use the search above. If you still can’t find the answer, feel free to reach out to us for help.
Dates and timestamps
Data availability is guided by our SLAs (Service Level Agreements), which outline the expected timelines for data delivery. The SLAs are as follows:
- Audio Recordings: Available for 90% of events within 20 minutes after the event concludes.
- Transcripts: Available for 95% of events within 15 minutes after the event ends, provided the recording was successful.
- Slide Decks: Available for 90% of events within 30 minutes of the deck being made publicly accessible.
- Interim Reports: Available for 90% of releases within 15 minutes of public availability.
- Annual Reports: Available for 90% of covered companies within 15 minutes of public release.
- Live Transcripts / Live Calls: For covered events, 90% of live content is streamed within 5 seconds of the event going live.
All timestamps are in UTC (Coordinated Universal Time). This standard time zone is used to ensure consistency and avoid confusion across different regions.
The updatedAt and createdAt properties are timestamps that indicate when properties were last updated or created. These timestamps are crucial for tracking changes and ensuring that you have the most current information.
The updatedAt property reflects the last time the data was modified, while the createdAt property indicates when the data was initially created.
The properties are not always related to the actual event date. This is the case when we add backlog material. In these cases, the updatedAt and createdAt properties might greatly differ from the event date which can be fetched from the event endpoint.
Keeping data in synced state
The best way to keep your data up-to-date depends on your use case. Here are some options:
- Webhooks: Use webhooks to receive real-time notifications about changes to your data. This is ideal for applications that require immediate updates, such as live audio or transcript streaming.
- Polling: Regularly poll the API for updates. This is suitable for applications that can tolerate some delay in data freshness but still need to stay current. In order to make this method more efficient, you can use the
updatedBeforeandupdatedAfterproperties to only fetch data that has changed in a certain time window.
While we do not currently enforce strict rate limits, we do monitor usage patterns. If we detect excessive or abusive behavior, we may implement rate limits to ensure fair access for all users. We recommend using the API responsibly and efficiently to avoid any potential issues. Currently, we recommend a maximum of 10 requests per second averaged over a day and a maximum of 50 requests per second for short bursts.
Update 2025-04-29
We are currently working on implementing rate limits to ensure fair access for all users. We expect this to be enforced December 1, 2025. Following recommendations above will make sure you are not affected by this change. More information will be provided in the changelog.
Company identification
Working with company identifiers can be tricky. We provide several identifiers to help you identify companies in our system. Here are the most common ones:
- companyId: This is the unique identifier for a company in our system. It is used to reference the company in API requests and responses. These are specific to our system and are not used by any other system.
- ticker: This is the stock ticker symbol for the company. It is used to identify publicly traded companies on stock exchanges. We also provide the exchange symbol to identify the exchange where the company is listed. For example, “AAPL” for Apple Inc. on NasdaqGS.
- isin: This is the International Securities Identification Number. It is a unique identifier for securities, including stocks and bonds, and is used internationally.
All relevant endpoints support querying by isin, ticker and companyId. This means you can use any of these identifiers to query the API. However, all but the company endpoints will only return the companyId in the response.
When querying more than one company identifier at a time, e.g. /events?tickers=AAPL,AMZN, the API will return the companyId for each object in the response. In order to map these back to the original identifiers, you can use the /companies endpoint with the ids query parameter.
This will return the isin, ticker and companyId for each company in the response and allows you to map the identifiers back to tickers in the original request.
We do not support company name searches at this time. We recommend using the isin, ticker or companyId to identify companies in our system. This is the most reliable way to ensure you are working with the correct company. Company names are subject to change and can be ambiguous. For example, “Delta” could refer to Delta Air Lines, Delta Electronics or Delta Lithium.
There are plans to implement a company name search tool in the portal to allow for searching for companies by name. This is intended to be used for exploratory purposes only when a certain company can not be identified by its ticker or isin. This is not intended to be used in production systems.
Keep an eye on the changelog for updates on this feature.
Was this page helpful?