Every endpoint that takes a timeframe takes exactly one, and all 42 indicator series are computed for each of them. What changes between timeframes is not the shape of the data — it is how often it is republished and how far back it is kept.
{ "success": true, "data": { "timeframe": "H4", // SINGULAR - one per call "data": { "EURUSD": { "RSI_14": 58.4, "ADX": 28.4, "MACD_hist": 0.00012 }, "GBPUSD": { "RSI_14": 44.1, "ADX": 19.7, "MACD_hist": -0.00008 }, "XAUUSD": { "RSI_14": 66.2, "ADX": 33.0, "MACD_hist": 0.4120 } }, "not_found": null, // names any symbol with no cached row "updated_at": 1774620183 } }
This is worth stating plainly because getting it wrong fails silently: unknown query
parameters are ignored rather than rejected, so a request carrying an invented
timeframes= list returns a perfectly healthy 200 for the H1 default and
looks like it worked.
/v1/multi takes symbols and indicators as
comma-separated lists — up to 50 symbols in real-time mode — and returns a
symbol-keyed object of the values you asked for, at one timeframe, for 2× quota.
symbols=EURUSD,GBPUSD,XAUUSDindicators=RSI_14,ADXtimeframe=H4 — one valueThere is no endpoint anywhere that returns two timeframes in one response. A multi-timeframe view is a loop over timeframes in your own code, and each iteration is a normal, independently-scored request.
timeframes= parameter existsdata.timeframes object exists Cheaper than it looks. Because the batching happens on symbols and series rather
than timeframes, three timeframes across a ten-symbol watchlist is three calls (six weighted units)
through /v1/multi — against thirty if you looped
/v1/indicator per symbol per timeframe.
Publish interval, cache TTL, retention depth, roughly how many candles that depth holds, and the tighter window that applies to historical indicator requests. Every column is the same for every plan.
| Code | Interval | Republished | Cache TTL | Retention | ≈ candles held | History window | Max candles / history call |
|---|---|---|---|---|---|---|---|
| M1 | 1 minute | every 60 s | 180 s | 1 days | 1,440 | 12 hours | 720 |
| M5 | 5 minutes | every 60 s | 180 s | 2 days | 576 | 1 days | 288 |
| M15 | 15 minutes | every 10 min | 900 s | 4 days | 384 | 2 days | 192 |
| M30 | 30 minutes | every 10 min | 900 s | 7 days | 336 | 3.5 days | 168 |
| H1 | 1 hour | every 10 min | 900 s | 14 days | 336 | 7 days | 168 |
| H4 | 4 hours | every 30 min | 2,700 s | 30 days | 180 | 15 days | 90 |
| D1 | 1 day | every 30 min | 2,700 s | 45 days | 45 | 22.5 days | 22 |
Raw ticks are not an eighth timeframe. /v1/ticks is a separate
resource with its own rules: Pro and Enterprise only, from and
to both required, a one-hour maximum range per request, a hard 50,000-row
ceiling and 24-hour retention — the same schedule as M1.
See the tick endpoint.
Most of the surface shares one allow-list and one default, which is what makes swapping timeframes a one-character change. The exceptions are real, and each one rejects a timeframe the others accept.
| Endpoint | Accepts | Default | Note |
|---|---|---|---|
| GET /v1/ohlc | M1, M5, M15, M30, H1, H4, D1 | H1 | The candle endpoint. Spans the full retention window for the timeframe. |
| GET /v1/indicator | M1, M5, M15, M30, H1, H4, D1 | H1 | One of the 42 series, current value, with price context. |
| GET /v1/indicators | M1, M5, M15, M30, H1, H4, D1 | H1 | All 42 series for one symbol at one timeframe, current values only. |
| GET /v1/multi | M1, M5, M15, M30, H1, H4, D1 | H1 | Several series across several symbols — at ONE timeframe. The parameter is singular. |
| GET /v1/screener | M1, M5, M15, M30, H1, H4, D1 | H1 | One series banded across every symbol, on one timeframe. |
| GET /v1/summary | M1, M5, M15, M30, H1, H4, D1 | H1 | The aggregate verdict, scored independently per timeframe. |
| GET /v1/indicator/history | M1, M5, M15, M30, H1, H4, D1 | H1 | One series over time. Window capped at half the retention. |
| GET /v1/heatmap | H1, H4, D1, W1 | H4 | The only endpoint that accepts W1 — and the only one that rejects M1, M5, M15 and M30. |
| GET /api/market-insights/cards/{tf} | M30, H1, H4, D1 | — (path segment) | The four the 6-hourly snapshot job computes. The timeframe is a PATH segment, not a query parameter. |
| GET /v1/quote · /v1/ticks · /v1/spread | — | — | No timeframe at all. Quotes and ticks are point-in-time; spread takes a period (1h, 24h, 7d, 30d) instead. |
An out-of-set value is a 400, not a fallback. The error carries
INVALID_TIMEFRAME and the valid list for that endpoint in the detail, so a
typo surfaces immediately instead of quietly returning H1 data under the wrong label.
The efficient shape is the inverse of the obvious one: put the symbol list and the indicator list inside the request and the timeframe outside it. Three calls then cover a three-timeframe view of an entire watchlist.
/v1/multi: symbols and indicators. not_found — a missing symbol is reported, not an error. premium permission scope. # /v1/multi batches SYMBOLS x INDICATORS at ONE timeframe. # The parameter is "timeframe", singular. There is no "timeframes". curl -H "X-API-Key: YOUR_API_KEY" \ "https://tickatlas.com/v1/multi?symbols=EURUSD,GBPUSD,XAUUSD&indicators=RSI_14,ADX&timeframe=H4" # Candles are a different endpoint, also one timeframe at a time: curl -H "X-API-Key: YOUR_API_KEY" \ "https://tickatlas.com/v1/ohlc?symbol=EURUSD&timeframe=D1&limit=45"
# Multi-timeframe is N calls, one per timeframe. # Each is 2x, so a 3-timeframe view of a 10-symbol list is 6x total - # still far cheaper than 30 single-symbol reads. URL = "https://tickatlas.com/v1/multi" H = { "X-API-Key": KEY } def across_timeframes(symbols, indicators, timeframes=("H1", "H4", "D1")): out = {} for tf in timeframes: d = requests.get(URL, headers=H, params={ "symbols": ",".join(symbols), "indicators": ",".join(indicators), "timeframe": tf, }).json()["data"] out[tf] = d["data"] # {symbol: {indicator: value}} if d["not_found"]: warn(tf, "no cached row:", d["not_found"]) return out
The payload is identical whichever interval you ask for — same keys, same types, same envelope. That is what makes a timeframe a configuration value in your application rather than a branch in your code, and it is why a single integration can serve a one-minute view and a monthly-scale one without a second code path.
H1 is the default everywhere it is optional. W1 is valid inside
/v1/heatmap alone; MN1 is accepted by no endpoint at all, and anything else
returns a 400 naming the valid set rather than silently falling back.
A timeframe should be a value you pass, not a decision you architect around. These are the four things that hold whichever one you choose.
23 trend, 8 oscillator, 7 volatility and 4 volume are computed and stored per symbol per timeframe. A value can be null when the history behind it is too short, and null rows are skipped rather than faked.
Same keys, same types, same envelope on M1 as on D1. Changing the timeframe changes the numbers and nothing structural, so one parser covers all seven.
H1 candles open on the hour, H4 at 00:00, 04:00, 08:00 and so on, D1 at midnight UTC. No local time and no daylight-saving drift inside the data, so timeframes join cleanly against each other.
The retention resolver takes a timeframe and nothing else. Plans gate which surfaces you can reach — Pro for ticks, Starter for the WebSocket stream — never how far back the window reaches.
Every one of these takes the same parameter and the same H1 default, except the two noted. Weights are the real usage multipliers.
No tier buys a timeframe the next one down cannot reach, and none buys a deeper retention window. What plans change is the request budget, the rate limit, and access to raw ticks and the WebSocket stream.
The seven intervals cluster naturally by how often they are republished and how much history they hold — which is usually the real constraint on what an application can do with them.
M1 and M5 are the only timeframes our data refreshes on every update, so they are where the picture changes fastest. Retention is correspondingly short — 24 hours on M1, two days on M5 — which makes them a live surface rather than a research one.
M15 through H1 are republished every ten minutes and retained for four to fourteen days, so a whole trading week fits inside one window. This band is where a single request can cover an entire session-based question.
H4 and D1 are republished every half hour and retained for 30 and 45 days, so a couple of hundred H4 candles or a month and a half of dailies arrive in one call — comfortably inside the 1,000-candle ceiling.
Why there is no multi-timeframe call, which two endpoints break the pattern, how deep each interval goes, and what a bar does and does not carry.
No. Every endpoint that takes a timeframe takes exactly one, and the parameter is spelled `timeframe`, singular — including /v1/multi, whose plural parameter is `symbols`, not `timeframes`. A multi-timeframe view is one request per timeframe. That is cheaper than it sounds: /v1/multi batches your whole symbol list and your whole indicator list into each of those calls at 2× weight apiece, so three timeframes across ten symbols is three calls (six weighted units) rather than thirty.
A single timeframe echo, then a `data` object keyed by canonical symbol, each holding the indicators you asked for and their current values, plus `not_found` listing any symbol with no cached row and `updated_at`. No OHLCV, no bid, no ask, no spread and no per-timeframe nesting. Add `from` and `to` and it switches to historical mode, available on pay-as-you-go, Starter, Pro and Enterprise, weighted 2× per call, capped at 10 symbols and 5,000 rows total.
Almost. M1, M5, M15, M30, H1, H4, D1 is the set the core validator accepts, and /v1/ohlc, /v1/indicator, /v1/indicators, /v1/multi, /v1/screener, /v1/summary and /v1/indicator/history all use it with H1 as the default. Two endpoints differ and it matters: /v1/heatmap accepts only H1, H4, D1 and W1 — it is the single place W1 is valid — and the cached market-insights cards cover M30, H1, H4 and D1, because those are the four the snapshot job computes. Nothing above D1 is accepted anywhere else, and MN1 is accepted nowhere at all.
No. The resolver takes a timeframe and returns hours; it has no plan argument, so a pay-as-you-go account and an Enterprise account read the identical window. As deployed that is 45 days on D1, 30 on H4, 14 on H1, 7 on M30, 4 on M15, 2 on M5 and 24 hours on M1. What a plan changes is access to particular surfaces — tick data needs Pro, the WebSocket stream needs Starter — never the depth of the window behind them.
Our data updates about every 60 seconds, but not every update carries every timeframe. M1 and M5 blocks arrive on essentially every update; M15, M30 and H1 every ten minutes; H4 and D1 every half hour. The cache TTLs are sized to just outlast those intervals — 180 seconds, 900 seconds and 2,700 seconds respectively — so an entry expiring means our data has stopped updating, which is exactly the signal you want it to mean.
From /v1/ohlc: time, open, high, low, close and volume. That is the whole candle — there is no bid, ask or spread on it. The current-values endpoint /v1/indicators returns a different shape for the same symbol and timeframe: an ohlcv block, a bid, an ask, and all 42 indicator series with a count and updated_at. If you need spread history rather than a live spread, /v1/spread aggregates current, average, minimum, maximum and standard deviation over 1h, 24h, 7d or 30d.
Yes — the same 42 series are computed and stored per symbol and per timeframe: 23 trend, 8 oscillator, 7 volatility and 4 volume. A given value can still be null when the underlying history is too short for that period on that timeframe, which is why /v1/indicator/history skips rows whose column is null rather than emitting a gap. There is no VWAP in the set; if you have seen it listed, that was wrong.
It depends which endpoint. /v1/ohlc will serve the full retention window, subject to its 1,000-candle limit per call. /v1/indicator/history and /v1/multi in historical mode cap the query WINDOW at half the retention for that timeframe, and the 400 they return names max_window_hours and max_candles exactly, so splitting a long range into legal windows is mechanical.
None of them, in the sense the question usually means. Ticks are a separate endpoint, /v1/ticks, with its own 24-hour retention, a mandatory from and to, a one-hour maximum range and a hard 50,000-row ceiling — and it is Pro and Enterprise only. It is not a finer timeframe on the same surface; it is a different resource with a different gate.
The same payload shape on every interval, the same 42 series behind each one, and the same retention depth whatever you pay. Start on your $2.50 of credit, no card.