A free forex API can be useful for evaluating live quotes, but “free” does not necessarily mean ongoing access for a production application. Check the trial expiry, permitted currency pairs, request and subscription budgets, historical access, and usage rights separately. TickDB provides a concrete example: its documented Free plan is a seven-day trial, not an unlimited free production tier.
The useful question is not just whether an API returns EURUSD. It is whether the access you can test today covers the application you intend to operate next month. A prototype that retrieves one quote can succeed even when a multi-user dashboard would exceed a connection limit, need an unavailable pair, or require historical queries outside the plan.
This article uses TickDB's public documentation, checked on November 13, 2026, to show how to make that decision. It is not a provider ranking or a live performance benchmark. The same evaluation questions can be applied to another supplier, but the numerical limits below belong to TickDB.
A free trial is a time-limited evaluation
TickDB's Pricing documentation lists a seven-day Free trial with selected symbols, five concurrent subscriptions, one WebSocket connection, and an API rate limit of 30 requests per minute. It includes real-time quotes and real-time candlesticks. Those are separate constraints: access to the quote endpoint does not establish that every currency pair is included, and one open connection does not imply unlimited subscriptions.
Start by writing down the exact pairs and data your prototype needs. A currency converter using occasional snapshots has a different workload from a streaming dashboard. Test those specific symbols with the actual evaluation account rather than assuming that a supported-market list is the same as an account's entitlement list.
For a permanent free tier, the evidence must explicitly establish continuing access after the trial period. The documented seven-day trial does not do that. An application intended to run indefinitely therefore needs a plan for what happens when evaluation access ends, even if its traffic is small.
Separate request volume from streaming capacity
REST requests, open WebSocket connections, and concurrent subscriptions measure different activity. Reducing polling can lower REST traffic without changing how many symbols remain subscribed. Combining updates on one connection can reduce the connection count without reducing the subscription count.
Consider an illustrative workload, not a measured service result. Polling one batched snapshot every two seconds produces 30 requests per minute. That reaches the documented Free request limit before allowing for any other calls. Polling every three seconds produces 20 requests per minute, leaving ten requests of arithmetic headroom, but it does not prove the server will accept a burst or that other applications sharing the key are idle. A rate limit is not a recommended target operating level.
The Ticker Snapshot documentation allows up to 50 symbols per request. That endpoint maximum is not a grant of access to 50 trial symbols. Batch only symbols the account can actually access, and budget all calls sharing the relevant allowance. For a streaming implementation, verify connection and subscription limits independently instead of treating “WebSocket supported” as the end of the check.
Figure 1. An evaluation checklist, not a measured benchmark or a guarantee of account access.
Candlestick access does not promise arbitrary history
A common surprise is that a plan can expose candlesticks while restricting time-range queries. TickDB's Candlestick Data documentation says that the Free plan can query candlesticks but cannot specify a range using start_time or end_time.
That distinction matters when a prototype becomes a backtest. A chart showing currently available bars is not evidence that the same account can retrieve the last year for every pair. The pricing page lists historical data separately, while the endpoint documentation describes the exact parameter restriction. Read both before deciding whether a free evaluation can answer your research question.
Make the historical requirement explicit: pairs, interval, requested date range, and any completeness checks. If a query mode is unavailable, preserve that result. Removing the dates until the endpoint returns something may help diagnose the issue, but it changes the question and cannot validate the original backtest requirement. Also account for the last returned candle still forming; its changing values are not automatically a data error.
Make access failures visible in the integration
A failed request should tell you whether to change the workload, check permissions, or investigate transport. Repeating a forbidden request does not create permission. TickDB documents 3001 as a rate-limit error, 3006 as product access unavailable on the current plan, 3008 as unavailable candlestick time-range queries, and 3009 as an endpoint permission problem.
The following Python example makes one snapshot request and records a useful failure category. It requires the third-party requests package and an API key supplied through the TICKDB_API_KEY environment variable. Run it on a trusted backend, not in a public browser bundle. It is an implementation example based on the documented contract; no live account or market-data performance was tested for this article.
import os import requests def fetch_forex_snapshot(symbol="EURUSD"): response = requests.get( "https://api.tickdb.ai/v1/market/ticker", params={"symbols": symbol, "type": "forex"}, headers={"X-API-Key": os.environ["TICKDB_API_KEY"]}, timeout=10, ) try: body = response.json() except ValueError as exc: raise RuntimeError( f"HTTP {response.status_code}: non-JSON response" ) from exc if not isinstance(body, dict): raise RuntimeError("Unexpected response shape") code = str(body.get("code", "UNKNOWN")) if not response.ok or code != "0": if code == "3001": retry_after = response.headers.get("Retry-After") action = f"Rate limited; Retry-After={retry_after!r}" elif code in {"3006", "3008", "3009"}: action = "Check product, query-mode, or endpoint access" else: action = "Inspect the documented error before retrying" raise RuntimeError( f"HTTP {response.status_code}, code={code}: {action}" ) rows = body.get("data") if not isinstance(rows, list) or not rows: raise RuntimeError("No usable snapshot returned") return rows The code checks both the HTTP outcome and the business code, normalizing the latter because error codes can be strings or integers. It deliberately performs no automatic retry. A production caller should honor the documented rate-limit wait, use bounded retries for transient failures, and stop on permission failures until the request or account changes. Connection exceptions and timeouts also need handling at that caller boundary.
A successful response is still only one piece of evidence. Inspect the requested symbol, its timestamp, and the fields your application uses. The ticker documentation makes fields such as bid and ask conditional on availability; a generic response schema is not proof that every forex instrument returns them. Do not invent missing values simply to make a comparison screen complete.
Figure 2. Proposed failure handling. Different failure causes require different next actions.
Choose paid access from requirements rather than the largest number
The public monthly pricing lists Starter at $99 per month, Professional at $299, and Enterprise at $899. Their documented API limits are 60, 600, and 1,800 requests per minute respectively, with one, three, and ten WebSocket connections. These figures describe monthly plans as checked on November 13, 2026; other billing periods and later pricing changes should be verified separately.
Those numbers are useful only after you know the binding constraint. A higher request allowance may solve polling pressure but not an unsupported field or an unsuitable data license. Likewise, a larger historical allowance does not by itself establish the coverage or quality needed by a particular strategy. Ask the provider to resolve any market-specific ambiguity before treating a general pricing table as a production promise.
Public display, redistribution, storage, and commercial use also require their own rights check. The technical access facts above do not establish those permissions. Obtain the terms applicable to your intended use rather than inferring them from a working key or a paid price.
The decision a free evaluation should produce
Finish the trial with a short acceptance record: which pairs worked, which data and date ranges were available, the workload you tested, failures observed, the expected paid configuration, and unresolved usage rights. Keep documented limits separate from measurements you actually made.
A free forex API is enough for an evaluation when it lets you answer those questions within its time and access limits. It is enough for ongoing production only when the continuing plan, workload, market coverage, and rights all support that use. If one remains unverified, the honest result is an open requirement, not a claim that the integration is ready.
