# nasdaq-data-link wraps the Data Link REST API in two levels of Python

> The Nasdaq Data Link Python client offers a quick method that returns pandas dataframes and a detailed method built for applications, with retries, several ways to supply an API key, and a config option for SSL verification. It is an official client for a paid data service, so most of the friction is about keys and entitlements rather than the API itself.

**Nasdaq/data-link-python** — A Python library for Nasdaq Data Link's RESTful API

- Repository: https://github.com/Nasdaq/data-link-python
- Stars: 627 · Forks: 94
- Language: Python
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/nasdaq-data-link-python

## Two ways to get data, and the difference matters

The package can be used to interact with the latest version of the Nasdaq Data Link RESTful API, and the documentation is compatible with Python 3.7 and newer.

Retrieval comes in two flavours. There is the Quick method and the Detailed method, and the documentation says the latter is more suitable to application programming. Both work with the two data structures the service exposes: time-series dataset data and non-time-series datatable data.

The quick method is a one-liner. To retrieve a dataset:

```python
import nasdaqdatalink
data = nasdaqdatalink.get('NSE/OIL')
```

That finds all data points for the dataset NSE/OIL and stores them in a pandas dataframe, which you can then inspect with data.head(). The datatable equivalent takes query parameters:

```python
import nasdaqdatalink
data = nasdaqdatalink.get_table('ZACKS/FC', ticker='AAPL')
```

which retrieves all rows for ZACKS/FC where the ticker is AAPL, again landing in a pandas dataframe.

The quick method is the analyst path, and the documentation points to a separate Quick Method Guide for analysts with more of these calls. The Detailed Method Guide is for the advanced techniques the API also supports, which the documentation describes as searching and providing metadata, and programmatically retrieving data. The interesting part is that the API is more than a data source, and the detailed method is where that surfaces.

For a production service, the split matters. The quick call is fine in a notebook; a service that needs to page through results, refresh specific rows, or handle a large export wants the detailed method.

## Retries are on by default, with a backoff you can tune

The configuration table is the most useful part of the documentation for anyone building a service on top of this, because it describes retry behaviour in detail.

The use_retries option controls whether API calls returning statuses in the retry_status_codes list are automatically retried, and number_of_retries sets the maximum number of retry attempts, used only when use_retries is True. The example values given are True and 5.

The timing options are max_wait_between_retries, the maximum number of seconds to wait before attempting a retry, with an example of 8, and retry_backoff_factor, which the documentation explains is exponential, so a factor of 0.5 produces waits of 0.5, 1, 2, 4 and so on, again only used when retries are enabled.

The retry_status_codes list is wide: 429, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510 and 511. Including 429 means rate limiting is handled by waiting and retrying rather than by failing the call.

That is the sensible default for a data service, since a transient 500 on a financial data endpoint is a normal event rather than an exception. The parameter to watch is the interaction between the backoff factor and the number of retries, since a long backoff with a high retry count turns one slow request into a very slow request. All five retry options are documented as taking effect only when use_retries is True, so they are inert if you turn retries off.

## Three places to put the API key, and one of them bites

Credential handling is the part with the sharpest edges, and the documentation covers three mechanisms.

The first is the api_key option, described as your access key, used to identify who you are and provide full access. That is the inline option and the least convenient for anything that runs unattended.

The second is the environment variable NASDAQ_DATA_LINK_API_KEY, which the SDK will use to configure itself and which takes precedence over the API key file. The third environment variable is NASDAQ_DATA_LINK_BASE_DOMAIN, which configures the domain the SDK talks to.

The third mechanism is a file. The default configuration file location is ~/.nasdaq/data_link_apikey, and the client will attempt to load this file if it exists. The documentation warns that if the file exists and is empty, a ValueError will be thrown. That is a slightly unhelpful failure mode: an empty file left behind by a script that touched the path will break the client with an error that does not obviously point at the file.

Since version 1.0.1 the module will attempt to autoload your API key, and if you prefer another location you must call read_key() explicitly with a custom path:

```python
import nasdaqdatalink
nasdaqdatalink.read_key(filename="/data/.corporatenasdaqdatalinkapikey")
```

The existence of this call is a mild design smell, since an autoload that is always on can pick up a file you did not mean it to. The environment variable route is the one to prefer in a deployed service.

## SSL verification is on, and turning it off is one line

By default, SSL verification is enabled. To bypass it, the documentation gives a single line, and marks it as not recommended:

```python
nasdaqdatalink.ApiConfig.verify_ssl = False
```

This is worth calling out precisely because it is the kind of setting that gets toggled during a debugging session and then stays in the code. Setting ApiConfig.verify_ssl to False disables certificate validation for every request the client makes, which means a man-in-the-middle can serve you data and your code will accept it.

The setting lives on ApiConfig, a class-level configuration object, so it is process-wide rather than per-call. That is convenient for configuration, and it means one line in a module imported early can change the behaviour of the whole application.

The documentation does not say anything about a per-request override, nor about what the client does when verification fails. If you are behind a corporate proxy that intercepts TLS, the correct answer is to configure the trusted certificate in the environment rather than to disable the check in code.

There is a related, smaller habit worth adopting from the same section. The documentation recommends downloading the data in raw format at the highest frequency possible and doing any data manipulation in pandas itself, with a link to the pandas timeseries documentation.

## Debug logging is scoped, and you have to switch it on

The logging situation is described as limited in scope, and the documentation gives the snippet to expand it:

```python
import nasdaqdatalink
import logging

logging.basicConfig()

data_link_log = logging.getLogger("nasdaqdatalink")
data_link_log.setLevel(logging.DEBUG)
```

The pattern is the standard one: configure the root logger, then create a named logger for the nasdaqdatalink namespace and set its level to DEBUG. The commented line is worth uncommenting when you need to see dependency debug information as well, which is the usual reason you are in this code at all.

The documentation also shows a commented out line setting the root logger to DEBUG, and notes that it is useful to see dependency debug info as well, so uncommenting it when you need the full picture is a one line change.

The logger name is the module name, so if you use this in an application with a configured logging setup you can set the level per environment rather than in code, and you get request-level detail without the noise of the whole dependency tree.

## The package is a thin layer, and its dependencies say what it does

The setup.py file describes the shape of the client, and the dependency list is short and deliberate. The install requirements are pandas 0.14 or newer, numpy 1.8 or newer, requests 2.7.0 or newer, inflection 0.3.1 or newer, python-dateutil, six and more-itertools.

pandas and numpy are there because the return value of every call is a dataframe, requests is the HTTP layer, and inflection is there to pluralise or otherwise shape the field names the API returns, which is a small detail that tells you the client post-processes column names rather than passing the raw JSON through.

The package layout is also visible. PACKAGES lists nasdaqdatalink along with nasdaqdatalink.errors, nasdaqdatalink.model, nasdaqdatalink.operations and nasdaqdatalink.utils, so errors are separated from the main module, which is a reasonable sign for a client that has to communicate backpressure to a caller.

The setup file also carries a version guard. If the running interpreter is older than 3.7 it raises an ImportError explaining that this version no longer supports Python versions less than 3.7.0, and suggesting pip install setuptools --upgrade before reinstalling nasdaq-data-link. The version itself is read from a version module rather than hardcoded, which is how the VERSION constant is imported after the source directory is put on the path.

The MIT licence applies, and the repository also carries a CHANGELOG.md, a setup.cfg, a tox.ini, a Makefile and a requirements.txt.

## Local development uses tox, and the tooling list is dated

The development setup is documented in a way that reflects an older Python workflow, and it is worth reading for what it implies about maintenance.

For local development you clone or fork the repository and run pip install -r requirements.txt. The recommended test tools are nose for running tests, tox for testing against multiple Python versions, flake8 for syntax checking, and virtualenv for tox virtualization.

The documented sequence is to make sure a 3.x Python is installed, install virtualenv and tox with pip install tox virtualenv, run python setup.py install, and then run tox to test the plugin in all supported Python versions. Individual tests can be run with the unittest module, and the documentation gives a worked example:

```python
python -m unittest -v test.test_datatable.ExportDataTableTest.test_download_get_file_info
```

Two things stand out. nose is the recommended test runner, and nose has been unmaintained for years and does not work on current Python versions, so a fresh checkout will not run its tests as written without replacing it. And the setup.py install step in the test instructions is a legacy invocation that pip no longer recommends.

The Makefile reflects the same vintage. Its targets are clean, lint, package, setup, test, upload and upload-test, with uploads going to twine against repositories named nasdaq-data-link and test-nasdaq-data-link, and the package target running python setup.py sdist bdist_wheel. There is a CircleCI directory in the repository, and the last push was on 2026-09-15, so the project is being worked on, but the published test instructions have not been refreshed for the current Python ecosystem.

## Conclusion

nasdaq-data-link suits an analyst or engineer who already has a Nasdaq Data Link subscription and wants a Pythonic, dataframe-shaped way to pull datasets and datatables, and who wants retry behaviour on rate limits without writing it. It is the wrong tool if you expect a free tier with full data, since the documentation warns you may receive limited or sample data when no API key is set, and the wrong tool for a project that needs broad coverage without a paid entitlement per dataset. Before building on it, set the key through NASDAQ_DATA_LINK_API_KEY rather than the default key file, confirm your subscription covers the specific database codes you plan to request, and read FOR_DEVELOPERS.md, since the quick method and the detailed method expose quite different capabilities.

## FAQ

### How do I install the nasdaq-data-link Python package and set my API key?

Install with pip install nasdaq-data-link, then set the NASDAQ_DATA_LINK_API_KEY environment variable, which the SDK picks up and which takes precedence over the key file. The default key file location is ~/.nasdaq/data_link_apikey, and if that file exists and is empty a ValueError is thrown.

### What is the difference between the Quick method and the Detailed method?

The Quick method returns data in one call, for example nasdaqdatalink.get('NSE/OIL') for a dataset or nasdaqdatalink.get_table('ZACKS/FC', ticker='AAPL') for a datatable, with the result stored in a pandas dataframe. The documentation says the Detailed method is more suitable to application programming, and points to FOR_DEVELOPERS.md for searching, metadata and programmatic retrieval.

### How do retries work in the Nasdaq Data Link client?

With use_retries enabled, calls returning a status in retry_status_codes are retried up to number_of_retries times. The wait between attempts is governed by max_wait_between_retries and an exponential retry_backoff_factor, so a factor of 0.5 gives waits of 0.5, 1, 2 and 4 seconds. The retryable codes include 429 and the 500 series up to 511.

## Sources

- [Issues](https://github.com/Nasdaq/data-link-python/issues)
- [License: MIT](https://github.com/Nasdaq/data-link-python/blob/main/LICENSE)
- [Nasdaq/data-link-python on GitHub](https://github.com/Nasdaq/data-link-python)
- [README](https://github.com/Nasdaq/data-link-python/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nasdaq-data-link-python