Getting Started

Authentication

You must include a valid Intrinio API Key with every request to access the API.

Production Authentication

You can find your Intrinio API Key on your account page, and also listed below:

The Production API Key provides you with access to all data corresponding to your data feed subscriptions.

URL Parameter Authentication

Simply include your API Key in the HTTPS request by specifying an api_key URL parameter set to the value of your API Key.

Authorization Header Authentication

If you would prefer to use header authentication, include your API Key in the HTTPS request by specifying an Authorization header with the value: Bearer {api_key}‍

SDK Authentication

You will use your Production Intrinio API Key with all of our SDK offerings. Please select one of the language SDKs for more information, documentation, and code examples.

Public Authentication

For public/untrusted environments (such as client-side JavaScript), use our public key authentication over HTTPS.

You can create a Public API Key on your account page. Make sure to specify all domains from which this key may be used. Any domain not listed will be rejected by the API. For development purposes, localhost is listed as a domain by default. Make sure to delete this domain before going to production.

To include a public key in your HTTPS request, specify it as the value of an X-Authorization-Public-Key header.

If your public key is not authorized, a status code of 401 will be returned.

Paging and Request Limits

Paging

Often there is too much information in our system to serve in a single request of reasonable size. Therefore, we limit results to a certain number per request and provide you with paging information which can be used to retrieve the remaining pages of data.

Paged responses will include a next_page field in the response body. 

This means that to get all objects, you need to paginate through the results using the next_page field of the last request as a next_page parameter for the next call. You will know when you have paginated through all of the results and are on the final page when the response’s next_page field is set to null.

Example:

Endpoints that use paging will return 100 records per request. To receive more records per request, you may specify a page_size parameter of up to 10,000. However, these requests are subject to special limits.

Note: The Response List might in some cases return fewer objects than a specified page_size amount. This is normal behavior and should be expected as not all endpoints and requests carry the same amount of data points – i.e., AAPL will have 10k+ data points for its ongoing market history whereas PLTR, a relatively recently listed company, will have fewer than 1k data points.

Request Limits

The Intrinio API employs several reasonable limits to prevent abuse and ensure that stable, reliable performance is provided to all users. These limits can vary based on the size of the API request you are making. If you hit an API limit and your requests are being rate limited, HTTP response code 429 will be returned, accompanied by an explanation of the limit.

Per-Minute Request Limits

By default, our standard enterprise solution request limit at Intrinio is 2,000 calls per minute and 600 calls per data feed subscription. 

All API requests with a page_size less than or equal to 100 fall under this per-minute request limit. 

However, page_size requests greater than 100 (high-workload requests) are limited on a per-second basis, typically 1 per second. As a result, if you don’t implement some type of timing logic within your script – time.sleep(sleep_for) / sleep(sleepFor).then(() => { }; / setTimeout(resolve, sleepFor); – you are likely to receive a 429 or 503 response code. 

Custom Request Limits

Intrinio is built by developers, for developers, so we encourage you to reach out regarding your API call requirements. We offer custom solutions to ensure that your platform or application runs as smoothly as possible with our API endpoints.

Timeout Limits

Each request must be fulfilled within 25 seconds, or it will be dropped with a 503 error. Given the flexibility of our endpoints and the complexity of potential API calls, we leave it to the users to fashion requests which can be satisfied in a reasonable time.