Quick Auth:
{" "}
Authenticate once to auto-fill your Bearer token across all API
endpoints
{modalMarkup}
;
}
## What is a tick chart?
A regular chart candle covers a fixed **amount of time** — a 1-minute candle always covers one minute, whether ten trades happened during it or ten thousand. A tick candle instead covers a fixed **number of trades**. A `100T` candle closes the moment the 100th trade happens, whether that took two seconds during a busy open or two minutes during a quiet afternoon.
This makes tick charts a way to watch **activity** instead of the clock. When a stock suddenly gets busy, tick candles compress and appear in quick succession; when it goes quiet, they stretch out. Traders use this to spot momentum shifts and unusual volume that a time-based chart can smooth over.
Because a tick candle is built directly from individual trades, resolutions like `1T`, `100T`, or `1000T` cannot be produced by resampling regular time-based candles — they need their own data path, which is why this is a separate endpoint from [Historical Bars](/api-reference/chart/get-historical-bars).
Tick resolutions (`1T`–`1000T`) are **not** supported on `/v1/chart/history`. Use this endpoint for tick-based candles, and `/v1/chart/history` for minute/hour/day/week/month candles.
## Loading more history (pagination)
A tick chart doesn't have a fixed calendar, so "give me the next month of data" doesn't make sense the way it does for a daily chart. Instead, older bars are loaded one page at a time using a pagination token:
1. **First request:** call the endpoint with `symbol`, `resolution`, and `countback`, and leave `cursor` out. You get the most recent bars, plus a `nextTo` value in the response.
2. **Scrolling further back:** when the user scrolls the chart into the past and more history is needed, call the endpoint again with the same `symbol`/`resolution` and set `cursor` to the `nextTo` value from the previous response. You get the page of bars immediately before the ones you already have — no gaps and no repeated bars.
3. **Reaching the beginning:** once there's no more history to load, the response has no `nextTo` field. Stop requesting further pages at that point.
Treat `cursor`/`nextTo` as an opaque token: always store and forward it exactly as received, and never try to construct, parse, or calculate one yourself.
You may sometimes get **fewer bars than you asked for** in `countback` — this is expected, not an error. Each call fetches a bounded amount of trade data to keep response times fast, and a large bar size like `1000T` needs far more trades per bar than `1T`, so fewer complete bars fit in that budget. Check how many bars actually came back (the length of the `t` array) and, if you need more, use `cursor` to load the next page.
## Response fields at a glance
| Field | Meaning |
| ------------------ | -------------------------------------------------------------------------------------------------------------- |
| `s` | Status: `ok` (bars available), `no_data` (nothing found for this symbol/resolution), or `error` (see `errmsg`) |
| `t` | Bar timestamps, in **Unix milliseconds** — note this is milliseconds, not seconds like `/v1/chart/history` |
| `o`, `h`, `l`, `c` | Open, high, low, and close price for each bar |
| `v` | Total traded volume for each bar |
| `nextTo` | Pass this back as `cursor` to load the next older page; absent when there's no more history |
Every array lines up by index — `t[0]`, `o[0]`, `h[0]`, `l[0]`, `c[0]`, and `v[0]` all describe the same bar.
## OpenAPI
````yaml openapi.json GET /v1/chart/tick-history
openapi: 3.0.3
info:
contact:
email: dev@aries.com
name: Aries Financial
description: >-
OpenAPI Specification for the Aries trading platform API.
# Authentication
Learn how to authenticate with the Aries API using OAuth2 and manage access
tokens in your SDK.
## Overview
The Aries API uses **OAuth2 with Bearer tokens** (JWT format) for
authentication. All API requests require a valid access token in the
`Authorization` header:
```
Authorization: Bearer
```
## Providing Client ID and Client Secret (SDK)
When using the generated SDK, provide your **Client ID** and **Client
Secret** when you create the API client (e.g. in the constructor or security
options). The SDK will use these to obtain and refresh the access token
internally; you do not need to manage tokens yourself.
Obtain your OAuth2 credentials from the Aries platform (e.g. Client Center /
Manage Account at https://app.aries.com):
- **Client ID** – Your application identifier (pass to SDK client)
- **Client Secret** – Your application secret key (pass to SDK client; use
PKCE for public clients where secret cannot be stored)
## Authentication Flow
### 1. Authorization Code Flow
For server-side or confidential clients:
1. **Redirect the user** to the authorization URL to sign in and consent:
- **URL:** `https://app.aries.com/oauth2/authorize`
- **Query params:** `response_type=code`, `client_id`, `redirect_uri`, `scope`, `state`
2. **Exchange the code for tokens** (after user is redirected back with
`?code=.`):
- **POST** `https://api.aries.com/v1/oauth2/token`
- **Body:** `grant_type=authorization_code`, `code`, `redirect_uri`, `client_id`, `client_secret`
- Response includes `access_token` and `refresh_token`
3. **Call the API** with the access token: `Authorization: Bearer
`
### 2. PKCE Flow
For SPAs and mobile apps (public clients that cannot store `client_secret`):
1. Generate a **code_verifier** (random string) and **code_challenge** =
BASE64URL(SHA256(code_verifier)).
2. **Redirect the user** to `https://app.aries.com/oauth2/authorize` with
`code_challenge`, `code_challenge_method=S256`, plus `client_id`,
`redirect_uri`, `scope`, `state`.
3. **Exchange the code** at POST `https://api.aries.com/v1/oauth2/token`
with `grant_type=authorization_code`, `code`, `redirect_uri`, `client_id`,
`code_verifier` (no client_secret).
4. Use the returned `access_token` as Bearer.
### 3. MFA Verification
If the user has MFA enabled, the authorize step may return `is_mfa: true`
and a `next_step_auth_id`. Call **POST**
`https://api.aries.com/v1/oauth2/authorize/mfa` with `next_step_auth_id` and
`verification_code` (6-digit code). Then continue with **POST**
`/v1/oauth2/authorize/confirm` to get the authorization code, and exchange
it at `/v1/oauth2/token`.
## Token Management
- **Refresh when expired:** POST `https://api.aries.com/v1/oauth2/token`
with `grant_type=refresh_token`, `client_id`, `client_secret`,
`refresh_token`.
- **Using a Bearer token directly:** If you already have an access token,
set the header `Authorization: Bearer ` on every request. The
SDK can accept a pre-obtained token and use it until it expires.
## OAuth2 Scopes
Request only the scopes your application needs. Available scopes:
| Scope | Description |
|-------|-------------|
| `user:information` | View user profile and personal details |
| `account:information` | View account balances, positions, and transaction
history |
| `order:execution` | Place, modify, and cancel orders |
| `order:information` | View order history and status |
| `position:information` | View current positions and holdings |
| `market:information` | Access live and historical market data |
| `calendar:information` | Access earnings, economic, and market schedule
data |
| `options:information` | Access options chains and expiration data |
| `analytics:information` | View analytics, ratings, and market insights |
| `market:supplemental` | News, company profiles, financials, filings, ETF
data, technical analysis |
Specify multiple scopes as a space-separated string, e.g.
`account:information order:execution market:information`.
## Security Best Practices
- **Store credentials securely** – Use environment variables or a secrets
manager for `client_id` and `client_secret`. Never hardcode them.
- **Handle token expiration** – Check for 401 responses and refresh the
token using the refresh_token, then retry the request.
- **Use HTTPS** – All authorization and token endpoints must be called over
HTTPS.
- **Validate state** – When using the authorization code flow, validate the
`state` parameter on the callback to prevent CSRF.
## Error Handling
- **400 Bad Request** – Invalid or missing parameters, validation failures,
or malformed JSON. Response bodies follow the same patterns as other errors
(flat `error` string, optional `codes`, nested `error` object, or rarely no
body).
- **401 Unauthorized** – Invalid or expired access token; refresh the token
or re-authenticate. JSON bodies are not identical on every route: you may
see a flat `error` string (sometimes with `codes`), a nested `error` object
(`type`, `code`, `message`), or rarely an empty body
- **403 Forbidden** – Insufficient scope or permissions for the requested
resource. Error JSON may be flat or nested, like 400/401.
- **404 Not Found** – Resource does not exist or is not visible. Error JSON
may be flat or nested.
- **429 Too Many Requests** – Rate limit exceeded; slow down and respect
`Retry-After` when the header is present. Error JSON may be flat or nested.
- **500 / 5xx** – Server or upstream failure; retry with backoff. Do not
depend on a single error JSON shape; some responses may have no body.
---
Endpoints in this spec: health, OAuth2 (authorize, confirm, mfa, token),
users, accounts, orders, market data, watchlist, chart, analytics,
calendars, company, economy, financials, indices, options, news, and
supplemental data.
title: Aries API — OpenAPI Specification
version: 1.0.0
servers:
- description: Production server
url: https://api.aries.com
security: []
tags:
- description: >-
Analytics endpoints for market data analysis including top gainers,
losers, volume leaders, sector analysis, analyst ratings, market breadth,
and net inflow
name: Analytics
- description: User management and profile endpoints
name: Users
- description: >-
Order management endpoints for placing, updating, canceling, and
previewing orders
name: Orders
- description: Account management endpoints for positions, orders, and balances
name: Accounts
- description: Calendar and mergers/acquisitions endpoints
name: Calendar
- description: >-
Market data endpoints for symbol search, real-time data access, and equity
details
name: Market Data
- description: >-
Watchlist endpoints for listing, creating, updating, and deleting
watchlists
name: Watchlist
- description: Chart endpoints for config, symbols, history, quotes, and server time
name: Chart
- description: News and news sentiment endpoints
name: News
- description: >-
Indices endpoints for groups, list, search, bar, bars, chart-bars,
realtime values
name: Indices
- description: Logos search and sync endpoints
name: Logos
- description: 'Corporate actions: spinoffs, tender offers, IPO calendar, dividends'
name: Corporate Actions
- description: 'Economy endpoints: inflation, inflation expectations, treasury yields'
name: Economy
- description: >-
Options endpoints: expiry dates, contracts, activity, trades, quotes,
unusual activity
name: Options
- description: >-
Financials: reported, statements, revenue breakdown, short volume, ratios,
short interest
name: Financials
- description: Signals and bull-bear cases
name: Signals
- name: Company
- name: ETF
- name: Filings
- name: Market
- name: Ownership
- name: Stocks
- name: Stock Estimates
- name: Stock Alternative
description: >-
Transcripts, company presentation, social sentiment, investment themes,
supply chain, and ESG data
- name: Technical Analysis
paths:
/v1/chart/tick-history:
get:
tags:
- Chart
summary: Get Tick-Based Chart Data
description: >-
Retrieves tick-based chart bars for a specific symbol. Unlike time-based
candles (which close every fixed number of minutes, hours, or days), a
tick bar closes every time a fixed number of trades has occurred — for
example, a `100T` bar closes after every 100 trades, whether that takes
two seconds in a busy market or two minutes in a quiet one. This makes
tick charts useful for visualizing market *activity* rather than the
*passage of time*, which many traders use to spot momentum and unusual
volume. Tick resolutions cannot be derived from time-based bars, so they
are served from this dedicated endpoint rather than `/v1/chart/history`.
Bar timestamps are returned in Unix milliseconds and are always strictly
increasing, even for very actively traded symbols. Because tick bars are
built from live trade activity rather than fixed calendar periods, older
bars are loaded using the `cursor` pagination token instead of a date
range — see the `cursor` and `nextTo` fields below.
operationId: getTickHistory
parameters:
- description: >-
Symbol to fetch tick bars for. Use the exact symbol returned by
symbol search, such as `AAPL` for equities.
example: AAPL
in: query
name: symbol
required: true
schema:
type: string
- description: 'Tick bar size: the number of trades that make up one bar.'
example: 100T
in: query
name: resolution
required: true
schema:
$ref: '#/components/schemas/TickResolution'
- description: >-
How many bars to return, counting back from the most recent bar (or
from `cursor`, if provided). Defaults to 300 when omitted. The
maximum depends on `resolution`: each call is bounded by a fixed
per-request trade budget, so low-count ticks (e.g. `1T`) can return
up to 5000 bars, while high-count ticks (e.g. `1000T`) may cap out
around 50. Requests above the resolution's maximum are silently
reduced to it — this is normal, not an error. Use the `cursor` field
to keep loading further back until you have as much history as you
need.
example: 300
in: query
name: countback
required: false
schema:
type: integer
minimum: 1
default: 300
- description: >-
Pagination token for loading OLDER bars, used when a user scrolls a
chart backward in time. Omit this parameter for the initial chart
load, which returns the most recent bars. To load the page before
that, pass the `nextTo` value from the previous response as
`cursor`. Treat this value as opaque — always pass it back exactly
as received; do not attempt to construct, decode, or modify it.
example: '1784677563966606471'
in: query
name: cursor
required: false
schema:
type: string
responses:
'200':
content:
application/json:
examples:
success:
value:
c:
- 130.15
- 130.89
- 131.24
h:
- 130.28
- 131.05
- 131.37
l:
- 129.88
- 130.09
- 130.81
nextTo: '1784677563966606471'
o:
- 129.93
- 130.15
- 130.89
s: ok
t:
- 1784677561000
- 1784677562500
- 1784677563966
v:
- 1234567
- 1345678
- 1456789
schema:
$ref: '#/components/schemas/TickChartBars'
description: >-
Tick bars in TradingView UDF format, extended with a pagination
cursor. Always returns 200; check **s** (status): `ok` = data in t,
o, h, l, c, v (and usually `nextTo`); `no_data` = no matching trade
activity, and `nextTo` will be absent — stop requesting further
history; `error` = errmsg contains reason (e.g. invalid resolution
or malformed cursor).
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'403':
$ref: '#/components/responses/Forbidden'
'404':
$ref: '#/components/responses/NotFound'
'500':
$ref: '#/components/responses/InternalServerError'
security:
- OAuth2:
- market:information
components:
schemas:
TickResolution:
type: string
description: >-
Tick bar size: the number of trades that make up one bar. For example,
`100T` closes a new bar every 100 trades, regardless of how much time
that takes. Larger values (e.g. `1000T`) smooth out noise and are better
suited to a wider chart view; smaller values (e.g. `1T`, one trade per
bar) show every individual trade and suit a zoomed-in view.
enum:
- 1T
- 5T
- 10T
- 25T
- 50T
- 100T
- 250T
- 500T
- 1000T
example: 100T
TickChartBars:
description: >-
Tick-based chart data returned as parallel arrays, plus a pagination
cursor for loading older history. Values at the same index belong to the
same bar, so `t[0]`, `o[0]`, `h[0]`, `l[0]`, `c[0]`, and `v[0]` describe
one candle.
properties:
c:
description: >-
Close price for each bar. Use the value at the same index as `t` for
chart candles and performance calculations.
items:
type: number
type: array
errmsg:
description: Human-readable error message. Present only when `s` is `error`.
type: string
h:
description: >-
Highest traded price during each bar. Use it for candle wicks and
intraperiod range.
items:
type: number
type: array
l:
description: >-
Lowest traded price during each bar. Use it for candle wicks and
intraperiod range.
items:
type: number
type: array
nextTo:
description: >-
Opaque pagination token for loading the next OLDER page of bars.
Save this value and send it back as the `cursor` query parameter
when the user scrolls the chart further into the past. Not present
when there is no older history left to load — stop requesting
further pages when this field is absent.
type: string
o:
description: >-
Open price for each bar. Use the value at the same index as `t` for
candle bodies.
items:
type: number
type: array
s:
description: >-
Response status. `ok` means chart arrays are usable; `no_data` means
no matching trade activity was found; `error` means read `errmsg`.
enum:
- ok
- no_data
- error
type: string
t:
description: >-
Bar timestamps in Unix MILLISECONDS (not seconds, unlike
`/v1/chart/history`). Each timestamp is strictly greater than the
one before it, even when many trades happen within the same second.
Each timestamp index lines up with open, high, low, close, and
volume arrays.
items:
format: int64
type: integer
type: array
v:
description: >-
Total traded volume for each bar. Use the value at the same index as
`t` for volume charts.
items:
format: int64
type: integer
type: array
required:
- s
type: object
AuthenticationErrorEnvelope:
type: object
description: >-
JSON envelope where `error` is a nested object (`type`, `code`,
`message`, …). Many services use this shape for 400, 401, 403, 404, 429,
and 5xx when using the shared HTTP error format.
properties:
error:
$ref: '#/components/schemas/AuthenticationErrorDetail'
meta:
type: object
additionalProperties: true
description: Optional metadata
ErrorResponse:
properties:
codes:
description: Structured error codes for programmatic handling
items:
$ref: '#/components/schemas/ErrorCode'
type: array
error:
type: string
description: >-
Error detail as a string. Exact message content is not fixed and
should not be hard-coded.
example: string
metadata:
additionalProperties: true
description: Additional error context
type: object
type: object
AuthenticationErrorDetail:
type: object
description: >-
Structured payload for the nested `error` object. Services using the
shared Go error writer emit uppercase `type` values aligned with error
categories (for example `VALIDATION`, `BAD_REQUEST`, `AUTHENTICATION`,
`AUTHORIZATION`, `NOT_FOUND`, `RATE_LIMIT`, `INTERNAL`).
properties:
type:
type: string
description: >-
Error category emitted by the shared error writer, such as
VALIDATION, BAD_REQUEST, AUTHENTICATION, AUTHORIZATION, NOT_FOUND,
RATE_LIMIT, or INTERNAL.
example: AUTHENTICATION
code:
type: string
description: Machine-readable code
example: INVALID_TOKEN
message:
type: string
description: >-
Error detail as a string. Exact message content is not fixed and
should not be hard-coded.
example: string
details:
type: object
additionalProperties: true
description: Optional extra context
request_id:
type: string
description: Request correlation id when provided
ErrorCode:
properties:
code:
description: Machine-readable error code
example: INVALID_PASSWORD
type: string
description:
description: Human-readable description of the error
example: Password must be between 8 and 64 characters
type: string
field:
description: Field name that caused the error
example: password
type: string
type: object
responses:
BadRequest:
description: >-
Invalid query/path/body, malformed JSON, or failed validation.
**Backend (shared HTTP errors):** Routes that use the shared error
writer typically return a **nested** JSON object: `error.type` is an
uppercase category such as `VALIDATION` or `BAD_REQUEST` (see the API
implementation). Other routes may return the **flat** `ErrorResponse`
shape (`error` as a string, optional `codes`). The body may rarely be
empty.
**OpenAPI:** Every operation’s **400** response references this
component so the documented schema and examples stay aligned.
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/AuthenticationErrorEnvelope'
- $ref: '#/components/schemas/ErrorResponse'
description: >-
400 responses commonly use a nested `error` object (`type`,
`code`, `message`, optional `details`). Some services still return
flat `ErrorResponse` (`error` string, optional `codes`).
examples:
nested_shared_http_error:
summary: Nested error (typical for shared WriteHTTPError-style responses)
value:
error:
type: VALIDATION
code: VALIDATION_ERROR
message: Query parameter validation failed
details:
fieldName: field is required
nested_bad_request:
summary: Nested error (BAD_REQUEST / invalid JSON)
value:
error:
type: BAD_REQUEST
code: INVALID_JSON
message: string
flat_string:
summary: Flat error string
value:
error: string
flat_with_codes:
summary: Flat error with field codes (some services)
value:
error: string
codes:
- field: string
code: string
description: string
Unauthorized:
description: >-
Authentication failed: missing credentials, invalid JWT, or expired
access token.
**Response body variants:** Some routes return JSON with a string
`error` field (and optionally `codes` / `metadata`). Others return JSON
where `error` is a structured object (`type`, `code`, `message`, and
optionally `details`, `request_id`). In edge cases (for example certain
gateway or middleware paths) the response may have **no body** even
though the status is 401—clients should treat 401 as unauthenticated and
refresh or re-authenticate regardless of body shape.
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/ErrorResponse'
- $ref: '#/components/schemas/AuthenticationErrorEnvelope'
description: >-
401 responses may use a flat `ErrorResponse` shape or a nested
`error` object. Inspect `error`: if it is a string, use the flat
shape; if it is an object, use the structured shape.
examples:
flat_message:
summary: Flat error string (typical)
value:
error: string
flat_with_codes:
summary: Flat error with structured codes
value:
error: string
codes:
- code: string
description: string
nested_error_object:
summary: Nested error (shared HTTP error format)
value:
error:
type: AUTHENTICATION
code: INVALID_TOKEN
message: string
Forbidden:
description: >-
Authenticated but not allowed to perform this action or access this
resource (insufficient scope or role).
**Response body variants:** Flat `ErrorResponse` or nested `error`
object, same pattern as 400/401.
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/ErrorResponse'
- $ref: '#/components/schemas/AuthenticationErrorEnvelope'
description: 403 responses may use a flat or nested error shape.
examples:
flat:
summary: Flat message
value:
error: string
nested:
summary: Nested error (shared HTTP error format)
value:
error:
type: AUTHORIZATION
code: INSUFFICIENT_SCOPE
message: string
NotFound:
description: >-
The requested resource does not exist or is not visible to this caller.
**Response body variants:** Flat `ErrorResponse` or nested `error`
object.
content:
application/json:
schema:
oneOf:
- $ref: '#/components/schemas/ErrorResponse'
- $ref: '#/components/schemas/AuthenticationErrorEnvelope'
description: 404 responses may use a flat or nested error shape.
examples:
flat:
summary: Flat message
value:
error: string
nested:
summary: Nested error (shared HTTP error format)
value:
error:
type: NOT_FOUND
code: RESOURCE_NOT_FOUND
message: string
InternalServerError:
description: >-
Unexpected server error or upstream failure. **Retry with exponential
backoff**; do not assume a specific JSON body shape.
**Response body variants:** Flat `ErrorResponse`, nested `error` object,
or occasionally a minimal message. Some paths may return **no body**.
content:
application/json:
examples:
flat_string:
summary: Flat error string
value:
error: string
nested_error_object:
summary: Nested error (shared HTTP error format)
value:
error:
type: INTERNAL
code: INTERNAL_ERROR
message: string
schema:
oneOf:
- $ref: '#/components/schemas/ErrorResponse'
- $ref: '#/components/schemas/AuthenticationErrorEnvelope'
description: 5xx responses may use a flat or nested error shape.
securitySchemes:
OAuth2:
type: oauth2
description: >-
OAuth2 Bearer token: obtain an access token from the token endpoint and
send it in the Authorization header.
flows:
clientCredentials:
tokenUrl: https://api.aries.com/v1/oauth2/token
refreshUrl: https://api.aries.com/v1/oauth2/token
scopes:
user:information: View user profile and personal details
account:information: View account balances, positions, and transaction history
order:execution: Place, modify, and cancel orders
order:information: View order history and status
position:information: View current positions and holdings
market:information: Access live and historical market data
calendar:information: Access earnings, economic, and market schedule data
options:information: Access options chains and expiration data
analytics:information: View analytics, ratings, and market insights
market:supplemental: >-
News, company profiles, financials, filings, ETF data, technical
analysis
user:management: >-
Manage user-scoped resources such as watchlists and other saved
configuration.
authorizationCode:
authorizationUrl: https://app.aries.com/oauth2/authorize
tokenUrl: https://api.aries.com/v1/oauth2/token
refreshUrl: https://api.aries.com/v1/oauth2/token
scopes:
user:information: View user profile and personal details
account:information: View account balances, positions, and transaction history
order:execution: Place, modify, and cancel orders
order:information: View order history and status
position:information: View current positions and holdings
market:information: Access live and historical market data
calendar:information: Access earnings, economic, and market schedule data
options:information: Access options chains and expiration data
analytics:information: View analytics, ratings, and market insights
market:supplemental: >-
News, company profiles, financials, filings, ETF data, technical
analysis
user:management: >-
Manage user-scoped resources such as watchlists and other saved
configuration.
````