/v1/openapi.json

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.

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.

{
  "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 the envelope above. It is a hand-written summary the document carries rather than derives, and it has fallen behind the routes the application actually serves — it still names surfaces that were removed. Read paths for what the API covers, or the namespace pages under API endpoints; do not read that string.

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:

{
  "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; 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:

{
  "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.",
    "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"
      }
    ],
    "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: 61 paths and 61 operations (60 GET, the one POST being /v1/onchain/labels/batch), the 35 · 15 · 11 namespace split, 61 of 61 descriptions, 258 parameters of which 258 are described, 200 on all 61 and 422 on 58, 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.