Tardis.dev is a digital assets market data provider, providing high resolution raw tick historical data — full order book depth snapshots and incremental updates, tick-by-tick trades, liquidations and more available via HTTP and WebSocket API.
High resolution historical market data API provided by tardis.dev can be used for a wide range of use cases such as:
backtesting and optimization of advanced quantitative trading strategies
training machine learning models
market microstructure and order book dynamics research
designing quantitative models
full historical order book reconstruction at any given moment in time
Any programming language that can communicate using HTTPS can consume HTTP API, additionally there are two official client libs that provide more high level and developer friendly data access:
There is also locally installable tardis-machine server providing on-demand tick-level historical market data replay via HTTP and WebSocket endpoints in exchange's message data format. In many cases existing exchanges WebSocket clients can be used to consume historical messages stream as if it was real-time one.
Currently supported exchanges:
Binance.com, Binance.je, Binance.org (DEX)
Crypto Facilities (Kraken Futures)
/exchanges API endpoint to get most up to date list of exchanges together with
/exchanges/:exchange API that provides useful exchange details like available currency pairs (symbols), pricing info, availability dates and more.
Data is available since
2019-03-30 for majority of the supported exchanges. In order to get exact availability data for particular exchange please use
/exchanges/:exchange API to get that info, or use order form that will display such info after exchange is selected.
Historical market data provided by main RESTful API can be accessed via HTTPS.
Locally installable tardis-machine server provides both streaming HTTP and WebSocket based APIs for accessing historical market data.
By using any of the official tardis clients flat files are automatically stored on local disk for caching purposes, but can also be opened and read from any programming language independently. Files are stored in directory hierarchy (grouped by exchange and dates) in compressed form (GZIP) and when decompressed their format is the same as data format provided by /data-feeds/:exchange HTTP API.
We can also upload flat files to the customer-owned Amazon S3 or GCS bucket (initial upload + daily updates) in normalized, customer requested format. This feature is not included in default pricing provided on the website, please get in touch with us via [email protected] if you'd like to know more details.
Raw market data is sourced from public WebSocket real-time APIs provided by the exchanges.
We're doing our best to provide the most complete and reliable historical raw data API on the market. To do so amongst many other things, we utilize highly available Kubernetes cluster on Google Cloud Platform that offers best in the class availability, networking and monitoring. However due to exchanges' API downtimes (maintenance, deployments etc.) we can experience market data gaps and cannot guarantee 100% data completeness. In rare circumstances, when exchange's API changes without notice or we hit new unexpected rate limits we also may fail to record data during such period, it happens very rarely and is specific for each exchange, please use
/exchanges/:exchange API endpoint and check for
incidents field in order to get most detailed and up to date information on that.
We use WebSocket protocol for all exchanges, plus HTTP REST APIs in case of fetching initial full order book snapshots for exchanges that do not provide them via WebSocket.
Historical market data available via API provides order book snapshots at the beginning of each day (
00:00:000 UTC) along with locally timestamped order book messages for each update, check out API docs for more details.
Order books are collected in streaming mode - snapshot at the beginning of each day and then incremental delta updates.
Each message received via exchange WebSocket API is timestamped with 100ns precision and stored in ISO 8601 format.
New market data delay is only 4 minutes in relation to real-time (T - 4min).
Data collection is being done on a single physical server that is a part of Google Cloud Platform Kubernetes Cluster. This prevents local timestamps being inconsistent and out of sync which helps with more accurate backtesting algo strategies across multiple exchanges.
RESTful HTTP API latency when requesting single minute of historical data is in range of 50-300ms depending of selected exchange and provided filters, it scales very well to multiple parallel requests, but please don't use more than 60 or so as it doesn't bring any speed benefits, but on contrary it may be slower - it's also the value all official clients use under the hood for fetching data logic, so effectively one one hour instead of one minute is being fetched at once.
Tardis-machine HTTP endpoint returns up to 400 000 historical data messages per second - that may vary due to local machine spec and local cache ratio. Same applies to tardis node-client which is being used by tardis-machine server under the hood. Python tardis-client is a little bit slower, but that also depends if auto decoding (parsing JSON messages) is turned on of off.
Price table on the tardis.dev homepage contains price per data month for each exchange, split by single instrument and full feed API access.
Single instrument API access price is for API access to all market data recorded for single instrument (trades, order book, etc.) for given exchange for single month (30 day basis).
Full feed API access price is for API access to all market data recorded for all available instruments for given exchange for single month (30 day basis).
Committed use discount means that you can order market data that will be available in the future and get better price because of that - up to 50%. For example if your order BitMEX data for next 12 months from now (from today to 365 from today) you'll receive 38% price discount. Best way to estimate exact discount is to use order form which will display price together with discount applied when exchange, symbol and date ranges are provided.
Current and any previous month
Next month (current month + 1)
Current month + 2
Current month + 3
Current month + 4
Current month + 5 and any future month after that
On order form select exchanges, instruments symbols and date ranges that you're interested in and get the exact price you'd pay.
Proceed to checkout where you provide email address on which you'll get your API key and select payment method - credit cards, PayPal and Apple Pay supported - full list available at https://paddle.com/support/which-payment-methods-do-you-support/.
Successfully complete your payment and receive API key via email.
Enjoy! In case of any questions, just contact us, we will get back to you as soon as possible.
On subsequent orders you can use new API key to access data available for previous orders as well.
Before the checkout process is complete, you should be given the option of entering a VAT ID which will exempt your purchase from a sales tax charge. If you think you’ve been incorrectly charged for VAT, please contact [email protected] and they will be able to issue a VAT refund to you. Paddle handle all our transactions and will be able to help you.
When you’re charged, you will receive an invoice for your subscription by email. There should be a link in the email that says “view your invoice, where you can add/edit your invoice address”. Click this link to add your VAT ID and address to the invoice.
When you’re charged, you will receive an invoice for your subscription by email. There should be a link in the email that says “view your invoice”. Click this link to get the address and VAT ID of Paddle who process our payments. Paddle acts as a reseller and Merchant of Record so they handle VAT on our behalf.
You need to contact [email protected] to request a new invoice. Please provide the email address you bought the subscription with and any extra details that might help.
We do not have a formal SLA in place yet, but all infrastructure is set up to provide highest availability possible on both recording and providing market data side with multiple geo-redundant fallbacks. Both recording and public APIs are constantly monitored from multiple locations and our engineering team is immediately notified in case of any issue. We don't practice maintenance that would affect availability, but in very rare circumstance if that would happen we'll communicate that in advance. If a formal SLA is something that your business require please contact us.