Forex Tick Data API: Live Quotes, Historical Downloads, and Access Costs
TickDB Research ·
Summary: For quant teams choosing an FX data supplier, a working live feed answers only part of the purchasing question. Research may need historical bid and ask updates, while a dashboard may need current quotes and charts. This guide explains how to distinguish quotes, trades, and bars, check historical access, and compare costs against a specific job. It includes a dated EUR/USD quote sample, three actual TickDB historical queries, and a supplier questionnaire you can copy into an enquiry.
Imagine approving an EUR/USD feed after watching prices update on a screen. The next request from research is a year of bid and ask history. The chart works, the subscription is active, and the team still has to establish whether the required archive is available. That gap can mean another purchase or a change to the research plan.
Specify the record and the date range before choosing the subscription. TickDB provides streaming FX quotes and historical bar queries, which let a team inspect live price fields and retrieve defined chart periods. Those capabilities should be checked against the purchase requirement: a quote archive, an execution record, and a bar series serve different jobs.
One minute to understand quotes, trades, and bars
“Tick data” needs a follow-up question: what event produced each record?
A quote update reports a price offered or observed within a particular feed. A trade record reports an execution within its stated venue or reporting scope. A bar summarises a price series over an interval.
Concept illustration generated with AI. The objects represent record types, not a conversion process.
If you want to inspect quoted spreads, ask for bid and ask observations with timestamps. If you want to study executions, specify the execution source and the relevant size and trade fields. If you want to plot hourly movement, bars may already contain the information you need.
These choices affect what can be reconstructed later. An open, high, low, and close preserve selected properties of an interval. They do not retain the order and timing of every quote change inside it. An hourly chart can answer an hourly question while leaving an intraminute spread question unanswered.
The price label matters too
In a two-sided quote, bid and ask describe the buying and selling sides of that quote. The midpoint is their arithmetic average. A field named last_price needs its own definition; its name alone does not establish that it is a midpoint or an executed trade.
For a bar, ask which underlying price series generated the open, high, low, and close. Comparing a bid-based close with an ask-based close introduces a price-side difference before any discussion of data quality.
Start with the question your team needs answered. A daily trend study may work with bars; reconstructing the quoted spread around an announcement requires more detailed observations.
Why two FX feeds can deliver different records
For spot FX, source scope matters. The BIS described trading spread across electronic venues, dealer platforms, and proprietary liquidity pools in its research on fragmented FX execution. A supplier’s feed therefore needs a stated view of the market: whose prices or executions does it contain? BIS research on FX execution
Delivery rules add another distinction. OANDA’s pricing-stream documentation says that its account price stream sends at most four prices per second per instrument. When several prices occur within a 250-millisecond window, it sends the price in effect at the end of that window. The documentation explicitly says that subscribers will not receive every price created for the account. OANDA pricing-stream documentation
That is a useful example of a published delivery rule. A buyer studying every quote change would need to account for it; a display refreshing less frequently may have a different requirement.
Historical ticks also have dedicated access paths. Dukascopy’s IHistory documentation includes getTicks alongside bar-retrieval methods. Its examples expose bid and ask information. Dukascopy historical-data interface
These examples show what to ask about. They are documentation examples, not a performance comparison between suppliers. For each candidate, request the source scope, record definition, delivery rule, and historical access method.
Historical downloads need an exact specification
“We need a year of forex history” leaves several purchasing decisions open.
Which pairs? Quote updates or bars? Bid and ask separately, or a specified reference-price series? Which dates and timezone? Can the account retrieve a bounded period, and how much can one response contain?
The distinction becomes practical around an event. The Federal Reserve’s calendar schedules an FOMC meeting for October 27–28, 2026. A team monitoring prices during that meeting and a team later studying historical spreads would need to specify different inputs. Federal Reserve meeting calendar
A live subscription and a historical archive need separate acceptance checks.
For a historical request, agree on the currency pair, record type, price side, exact start and end, and retrieval limits. Establish how timestamps, closed-market periods, filtering, and genuine gaps are represented. If the intended output is a CSV, ask whether the service supplies files directly or whether your team must retrieve API responses and create the files.
A multi-year retention label is a starting point for that conversation. Ask for the earliest retrievable date for the particular pair, record type, and granularity you intend to buy.
What the TickDB samples actually looked like
TickDB’s FX quote stream exposes price fields for monitoring, while its historical K-line query retrieves bars for a specified period. For a buyer combining a live screen with historical charts, testing these separately makes the delivery easier to inspect.
A saved live EUR/USD quote
A quote collected on October 22, 2026 contained the following fields:
{
"symbol": "EURUSD",
"last_price": "1.11950",
"bid_price": "1.11950",
"ask_price": "1.11951",
"spread": "0.00001",
"timestamp": 1792677449581
}
The provider timestamp corresponds to 13:57:29.581 UTC. The bid and ask difference in this observation is 0.00001. This is a dated stream observation; its price fields can be examined directly alongside the TickDB ticker documentation.
Although last_price happens to equal bid in this record, one equality does not define how that field is generated. For a purchasing requirement involving midpoints or executed trades, obtain the field definition.
Three historical queries with a defined time window
On October 25, 2026, we queried TickDB’s historical K-line endpoint for EURUSD under the test account’s permissions. The requested periods were on October 22 and had already ended.
| Request | Limit | Returned bars | Returned bar timestamps in UTC |
|---|---|---|---|
| One-minute bars for 13:00:00–13:59:59.999 | 1,000 | 60 | 13:00 through 13:59 |
| Same pair, interval, and time window | 5 | 5 | 13:00 through 13:04 |
| Hourly bars for 00:00:00–23:59:59.999 | 1,000 | 24 | 00:00 through 23:00 |
All three requests returned HTTP 200 and API code 0. In the 60-bar response, timestamps were unique and spaced one minute apart throughout the requested hour. The 24 hourly timestamps were also unique and evenly spaced.
Rendered from the actual historical responses. Grey blocks show minutes omitted from the five-record response, rather than missing source data.
The first minute bar, timestamped 13:00 UTC, returned open 1.12048000, high 1.12053000, low 1.12020000, and close 1.12037000. These are bar values. A historical bid-and-ask tick request would require a different delivery specification.
The five-record query is particularly useful for acceptance. Its successful status accompanied only the first five minutes of the requested hour. A bulk-download process must check the returned timestamps and continue until it covers the required period.
TickDB’s K-line documentation specifies millisecond start and end timestamps and a maximum of 1,000 records per response. It also says that free accounts can query K-lines but cannot specify start_time or end_time. Historical access permissions therefore belong in the trial checklist.
For your own sample, give the technical colleague the pair, interval, UTC window, and intended record count. Ask them to return the actual first and last timestamps, row count, duplicates, and gaps. Compare those results with the purchasing requirement before expanding the download.
Access costs go beyond the monthly number
The useful comparison is the price of a service that meets your agreed requirement.
As checked on October 25, 2026, TickDB’s pricing documentation listed these general monthly plans:
| Plan | Listed monthly price | WebSocket connections | API requests per minute |
|---|---|---|---|
| Starter | $99 | 1 | 60 |
| Professional | $299 | 3 | 600 |
| Enterprise | $899 | 10 | 1,800 |
The same documentation lists general historical-data allowances of one, three, and ten years respectively. For FX procurement, confirm the required pair, data object, and historical granularity against the selected plan. Check current terms before ordering. TickDB pricing documentation
Separate the items that change the bill
Live access. Count the pairs, simultaneous subscriptions, and connections your application needs. A research notebook and a separate production dashboard may use connections differently.
Historical access. Ask whether the required archive is included, whether bounded retrieval is permitted, and how request limits affect the initial download. A long retention period and a fast bulk export are separate requirements.
Your own processing. API access still leaves work such as batching requests, storing results, checking dates, and handling revisions. A suitable file export can change that workload. An open-source downloader can help with retrieval, but its software licence does not establish permission to use the underlying data.
Intended use. Describe whether the output stays inside research, appears on a customer dashboard, or is redistributed. Ask for the applicable written terms and any associated charges. A working key demonstrates technical access; the intended commercial use needs its own answer.
Free or lower-cost data can be a sensible choice when it meets the required dates, definitions, and permitted use. A more granular paid feed can add unnecessary work when the job only calls for daily bars.
A supplier questionnaire you can copy
Send the same requirement to each supplier. Specific answers are easier to compare than differently worded feature pages.
| Ask this | Request this answer |
|---|---|
| What does each record represent? | Quote update, execution within a stated scope, or interval bar |
| Which source does it describe? | Provider, venue, or aggregation scope and relevant filtering |
| Which price series will we receive? | Bid, ask, midpoint, or another explicitly defined series; definitions of last and OHLC |
| How is the live feed delivered? | Update or sampling rules, subscriptions, and connection limits |
| Which history is available? | Pair-specific dates, record type, granularity, and a retrievable sample |
| How do we obtain the full period? | API or file delivery, response limits, batching method, and request allowance |
| How should time and gaps be read? | Timezone, precision, interval boundaries, filtering, and closed-market treatment |
| Does our intended use fit the terms? | Written conditions for internal research, customer display, or redistribution |
| What will the quoted price include? | Live access, historical access, extra capacity, and any other applicable charges |
For example, a research enquiry could read:
We need EUR/USD bid and ask quote history from October 1 through October 22, 2026, with UTC timestamps, for internal spread research. Please specify the source, record filtering or sampling, available time precision, retrieval method, total cost, and permitted use. Supply a one-hour sample before we proceed with the full period.
For a dashboard enquiry, replace the history requirement with the intended live update behaviour and chart periods. Keep the actual use explicit.
Frequently asked questions
How should I start evaluating a forex tick data API?
Write one requirement containing the pair, task, record type, price side, dates, and intended use. Request a small sample, then check its fields and returned time range. For TickDB, the live quote sample and bounded bar query above are two concrete starting points.
Can minute bars recover missing historical quote ticks?
A minute bar retains an interval summary. It cannot reconstruct the full sequence of bid and ask updates within that minute. For spread research, request the required quote archive. For a chart with a missing minute, check account permissions, limits, returned dates, and retrieval progress before treating the source period as absent.
Can TickDB support both a live FX dashboard and historical chart work?
Its FX quote stream and historical K-line query provide those two data paths. Match the target pairs, chart periods, date access, and quotas to the account you intend to use. If your requirement is historical quote ticks or FX execution history, request confirmation for that exact object; the bar query shown here delivers OHLC bars.
Before you approve the purchase
A team should be able to describe its order in one sentence: these pairs, this kind of record, this period, this price definition, and this permitted use.
Take one representative hour through the supplier’s actual delivery path. Inspect what arrives, resolve the gaps in the quotation, and then choose the subscription. That small acceptance step makes the purchasing decision easier to explain to both the budget owner and the colleague who has to use the data.
Sources and further reading
- BIS — FX trade execution: complex and highly fragmented, December 2019. Market-structure background.
- OANDA — Pricing endpoints. Account price-stream delivery rules.
- Dukascopy — IHistory interface. Historical tick and bar access methods.
- Federal Reserve — FOMC meeting calendars. October 2026 meeting dates.
- TickDB — Ticker stream, historical K-lines, and pricing. Product documentation checked October 25, 2026.
The examples concern data selection and acceptance. They are not trading recommendations.