/v1/openapi.json

The live OpenAPI 3.1.0 document for the /v1 REST API — the machine-readable surface to generate a client from or diff after a deploy.

GET https://data.vike.io/v1/openapi.json

The live OpenAPI 3.1.0 document for the /v1 REST API. This is the machine-readable surface: fetch it once to generate a client or drive a request tool, or diff it after a deploy to see what moved.

No path or query parameters — the only input that matters is the credential header. Without a key, read the same document at https://vike.io/data/openapi.json (the keyless copy).

cURL

curl -H "X-API-KEY: $VIKE_API_KEY" \
  https://data.vike.io/v1/openapi.json -o openapi.json

200, 84,924 bytes of application/json when captured on 2026-09-03. Too large to show whole, so it is split below into the three parts worth reading; the entries under paths, the two schemas under components.schemas and the one prose string noted below are elided, and every other byte shown is verbatim from that response.

The envelope — the document with paths and components removed and one prose string elided.

Example response — the envelope

{
  "openapi": "3.1.0",
  "info": {
    "title": "vike.io Data API",
    "description": "<elided — see the note below>",
    "version": "1.0.0"
  },
  "servers": [
    {
      "url": "https://data.vike.io"
    }
  ],
  "security": [
    {
      "OAuth2Bearer": []
    },
    {
      "ApiKeyHeader": []
    }
  ]
}

info.description is the one string elided from that capture. It is a hand-written summary the document carries rather than derives, and on the capture date it still named surfaces that had been removed; the application's string was corrected the same day, and a test now keeps it from naming them again. It summarises the products in one paragraph, so read paths for what the API covers, or the namespace pages under API endpoints.

components.securitySchemes, the block that makes client generation viable — both credentials, each carrying its own prose, and a top-level security (above) that is a list of single-key requirements, i.e. either, not both:

components.securitySchemes

{
  "OAuth2Bearer": {
    "type": "http",
    "scheme": "bearer",
    "bearerFormat": "vk_oat_...",
    "description": "OAuth 2.1 access token: `Authorization: Bearer vk_oat_...`. Issued by vike.io — discovery at `https://vike.io/.well-known/oauth-authorization-server`. Tried first; an invalid bearer falls through to the API-key header, so a request may carry either or both."
  },
  "ApiKeyHeader": {
    "type": "apiKey",
    "in": "header",
    "name": "X-API-KEY",
    "description": "Long-lived API key: `X-API-KEY: vk_...`. Create and revoke keys at https://vike.io/account?tab=api-keys. Every call is metered against the key and subject to an hourly rate limit and, on `/v1`, a per-minute cap of 200 requests; a trip is HTTP 429 with a `Retry-After` header."
  }
}

components.schemas is elided: it holds exactly the two entries the table on Schema and spec names, HTTPValidationError and ValidationError, and both are the framework's own request-validation error shapes.

One entry under paths, verbatim — /v1/onchain/wallets/{address}, chosen because it is the smallest complete operation in the document and shows two of the three gaps at once:

One entry from paths

{
  "get": {
    "tags": [
      "onchain"
    ],
    "summary": "Wallet Summary",
    "description": "Aggregate metrics for one wallet — volume, inflow, outflow, net flow, transaction count and\ntokens traded, across the 24h / 7d / 30d / 90d / all windows in a single response. `chain` in the\nresponse says which chain answered.",
    "operationId": "wallet_summary_v1_onchain_wallets__address__get",
    "parameters": [
      {
        "name": "address",
        "in": "path",
        "required": true,
        "schema": {
          "type": "string",
          "description": "Wallet address, 0x-prefixed hex",
          "title": "Address"
        },
        "description": "Wallet address, 0x-prefixed hex"
      },
      {
        "name": "chain",
        "in": "query",
        "required": false,
        "schema": {
          "type": "string",
          "description": "`ethereum` | `bsc` | `base` | `hyperevm`. Omit for the more recently active of ethereum and bsc; `base` or `hyperevm` is then answered only for a wallet with no priced ethereum/bsc volume",
          "default": "",
          "title": "Chain"
        },
        "description": "`ethereum` | `bsc` | `base` | `hyperevm`. Omit for the more recently active of ethereum and bsc; `base` or `hyperevm` is then answered only for a wallet with no priced ethereum/bsc volume"
      }
    ],
    "responses": {
      "200": {
        "description": "Successful Response",
        "content": {
          "application/json": {
            "schema": {}
          }
        }
      },
      "422": {
        "description": "Validation Error",
        "content": {
          "application/json": {
            "schema": {
              "$ref": "#/components/schemas/HTTPValidationError"
            }
          }
        }
      }
    }
  }
}

The operation and its parameter are described and fully typed, and the parameter is marked required — the part a generator can use. But the 200 body is "schema": {}, an undeclared object, and the only other declared response is the 422, whose $ref reaches one of the two error schemas. A generated client gets a correct request signature and an untyped response — the three gaps is the fuller account.

The table on Schema and spec carries the current counts, rendered at build time from the same openapi() this document is built from: 71 paths and 71 operations (70 GET, the one POST being /v1/onchain/labels/batch), the 31 · 10 · 17 · 13 namespace split, 71 of 71 descriptions, 307 parameters of which 307 are described, 200 on all 71 and 422 on 67, zero 2xx bodies declaring a schema, and no declared status code anywhere in the document other than those two.

It is generated, not hand-written, and it cannot drift from the routes that serve it: it is the framework's own document with the two security schemes added, then cached. Fetching it queries no data store, so it costs a request and nothing more.

What the document declares, what it leaves out, and the gate in front of it: Schema and spec.