Authentication

Two credential types — an X-API-Key header and OAuth 2.1 bearer tokens — which surfaces take which, and the caching window that makes revocation take a few seconds.

Vike's data planes accept two kinds of credential. All three surfaces authenticate the same way, and try them in a fixed order:

Authorization: Bearer vk_oat_... — an OAuth 2.1 access token.
X-API-KEY: vk_... — an API key.

An invalid bearer token falls through to the API-key header rather than failing outright, so a request may carry either or both. If neither validates, the request is rejected.

Surface	Credential
`https://data.vike.io/mcp`	either — OAuth for desktop clients, `X-API-KEY` for everything else
`https://data.vike.io/v1/...`	`X-API-Key` header
`https://data.vike.io/archive/...`	`X-API-Key` header for Polymarket data files. Open, no key: `manifest.json`, the Polymarket samples under `/archive/samples/` and the Hyperliquid samples under `/archive/hl-samples/`
a Hyperliquid file link (Cloudflare R2, valid 7 days)	none: the link is the credential. The key goes on the call that asks for the link, `GET /v1/hyperliquid/archive/url`

The credential always travels in a header. There is no query-string form, and adding one to a URL authenticates nothing.

API keys

Create keys at vike.io/account?tab=api-keys. A key is the literal prefix vk_ followed by 40 bytes of cryptographic randomness, so match on the prefix if you need to recognise one, and never on its length or shape beyond that.

Up to 3 active keys per account. Creating a fourth is refused with a 400. The count is of active keys, so deactivating or deleting one frees a slot.

Every key today has identical reach. There are no scopes to choose between and no way to narrow a key to a subset of the API, so a key is read access to everything your account can reach.

Keys are recoverable

Unlike most API products, Vike stores an encrypted copy of the full key at creation, so you can read it back later from the account page rather than losing it the moment the dialog closes.

The exception is keys created before that behaviour existed: those have no stored copy, and the reveal endpoint answers with a 410 telling you to create a new one. If you are holding a key old enough to hit that, rotating it is the fix.

Using one

curl -H "X-API-Key: $VIKE_API_KEY" \
  "https://data.vike.io/v1/onchain/tokens/search?q=USDC&limit=3"

The header name is matched case-insensitively, so X-API-KEY and X-API-Key both work. Getting started makes a first call with it.

One key, one budget

The hourly rate limit is counted per key, not per account — so a second key is a legitimate way to keep a bulk archive job from starving an interactive MCP client. OAuth tokens work the other way round and share one pooled counter per user. Rate limits has the details.

OAuth 2.1

Claude Desktop and other clients that support Dynamic Client Registration (RFC 7591) need no API key at all. Vike registers the client automatically; you log in once in a browser tab and approve.

The MCP server is on data.vike.io, and sign-in stays on vike.io. An unauthenticated call to https://data.vike.io/mcp is answered 401 with WWW-Authenticate: Bearer resource_metadata="https://data.vike.io/.well-known/oauth-protected-resource", and that document names "authorization_servers": ["https://vike.io"]. So the client is sent to vike.io to sign in, vike.io issues the token, and data.vike.io/mcp accepts it. An X-API-KEY header needs none of this.

Discovery metadata is published at https://vike.io/.well-known/oauth-authorization-server:

Field	Value
`issuer`	`https://vike.io`
`registration_endpoint`	`https://vike.io/oauth/register`
`authorization_endpoint`	`https://vike.io/oauth/authorize`
`token_endpoint`	`https://vike.io/oauth/token`
`scopes_supported`	`mcp:tools`

Access tokens are prefixed vk_oat_ and go in an Authorization: Bearer header. Connected apps are listed — and can be revoked — under Account → API Keys → Connected Apps.

Getting started walks through the Claude Desktop connector flow step by step.

Credential decisions are cached

The verdict of a credential check is cached briefly, keyed on a hash of the credential and never on the credential itself. Two windows matter to you as a user:

A valid credential is trusted for up to 45 seconds before it is re-checked against the account record. This is also the worst case for revocation: a deleted or deactivated key, or a revoked OAuth token, can keep working for a few seconds afterwards. It is a deliberate trade — the blast radius is a few seconds of extra reads on a data API — but it means revocation is not instantaneous, and any page that says it is is wrong.
An invalid credential is remembered as invalid for up to 8 seconds. If you just fixed a typo'd key, give it a few seconds before concluding the new one is broken too.

A check that fails for an infrastructural reason rather than a credential one is deliberately never cached, so a transient outage cannot turn into a multi-second rejection of a credential that is actually valid.

Keeping a key safe

Put it in an environment variable or a secret store, not in source control. It grants read access to your whole quota.
Rotate by creating the new key first, switching over, then deleting the old one — deletion takes a few seconds to propagate through the cache above.
If a key leaks, delete it. A deleted key stops authenticating within the 45-second window.

Rejections and their exact wire shapes are on Errors — including the WWW-Authenticate header on the 401 an unauthenticated MCP call gets, which is where an OAuth client starts discovery.