Response format

Every successful response has the same two-part shape:

{
  "meta": {
    "request_id": "req_7729f93d3facf68ff83e5c50",
    "as_of": "2026-07-31T12:00:00.000Z",
    "cache": "MISS",
    "pagination": {
      "page": 1,
      "next_page": 2,
      "limit": 10,
      "returned": 10
    }
  },
  "data": {
    "results": [
      "…"
    ]
  }
}

data is pure content — only the thing you asked for. Everything else lives in meta, and it speaks the same language on every endpoint of every API: the same field names, the same types, the same meanings. Learn it once.

meta is serialized first, so it is readable before the payload in a streamed or truncated response.

Why the split

Platform facts never mix into your data. Pagination is the clearest case: a next_page inside data would make your parsing depend on which endpoint you called, and would collide the day a result object legitimately has a field by that name. In meta, navigation is navigation everywhere.

It also means data can be handed straight to your own models. If you deserialize data.results into a SearchResult[], nothing platform-specific comes along for the ride.

Fields

Only request_id is on every response. The rest depend on the endpoint, and each endpoint's API reference lists exactly which ones it returns.

Errors

Failures do not use this envelope. They return application/problem+json with a stable code — see Errors. The one thing both shapes share is request_id, so you can trace any response, successful or not.