Docs

API

Envelope and metadata

Every successful response is {data, meta}. data is the payload; meta says where it came from, what shaped it, and how to continue.

The envelope

Every 2xx JSON response has the same two keys:

json
{
  "data": { "…": "the payload — its shape is on each reference page" },
  "meta": { "caps": { "tier": "pro", "applied": [] }, "cursor": null }
}

data is never reshaped by the envelope: a grid is a grid object, a list is an array. Errors use a different shape — see Errors.

What is in meta

FieldTypeMeaning
capsobject or nullEntitlement metadata on routes that check it: tier (the plan the request was served under) and applied (which caps shaped this response; empty means nothing was clamped).
cursorstring or nullAn opaque continuation cursor. Present only when there is another page — pass it back as ?cursor=. See Pagination.
planestring or nullWhich serving tier answered (for example memory for live state, or cache). Useful when debugging latency; do not branch business logic on it.
endpoint contextvariesEach endpoint adds its own context — date, symbol, origin, expired_filtered, row_count and so on — documented on its reference page.

Unknown meta fields will appear over time. Ignore the ones you do not use; the SDKs keep them for you.

The same metadata in headers

For clients that want it without parsing the body, the API also sends:

HeaderMeaning
x-itm-planeSame as meta.plane.
x-itm-capsThe caps summary for the request.
x-itm-extraEndpoint-specific extras, when there are any.
x-request-idA unique id for the request. Quote it when you report a problem.
ETagOn snapshot-style reads; see Caching.

Browsers can read the first three from page script (the API lists them in Access-Control-Expose-Headers); x-request-id is visible to cURL and server-side clients.

SDK results

Both SDKs return a result that keeps the envelope intact: data, meta, the HTTP status, the request id and the ETag. Nothing in meta is dropped, including fields the SDK version does not know about.