Skip to main content

​
Base URL

​
Authentication

Every endpoint except /health needs a Bearer token:
Generate yours at 0xinsider.com/developers. Full details in Authentication.

​
Response envelope

Single-resource endpoints return:
List endpoints add pagination fields:
Errors share the same envelope, with "object": "error". See Errors.

​
Prefixed IDs

Every ID is prefixed with its type, so it’s self-describing in logs and chat transcripts. Trader path endpoints accept raw addresses and valid trd_... wallet IDs. Market path endpoints such as /market/{condition_id}/intel and /market/{condition_id}/snapshot accept either raw provider-backed condition IDs or the mkt_... IDs emitted by V1 responses. Single-record whale trade and radar endpoints accept raw integer IDs or their wt_... / rf_... forms.

​
Rate limits

100 requests per minute per user, sliding window. Batch endpoints have an additional 100-item-unit-per-minute budget. GET /api/v1/usage does not spend primary quota, but it has its own 100 reads/minute guard. See Rate Limits for backoff patterns.

​
Browser CORS

Public REST /api/v1/* endpoints, excluding remote MCP (/api/v1/mcp), are callable from third-party browser origins with Authorization: Bearer .... Do not send cookies or credentials: "include" on public API calls. Remote MCP at /api/v1/mcp is also non-credentialed, but still validates Origin against the 0xinsider/localhost allowlist per the MCP Streamable HTTP DNS-rebinding guidance. Allowed public request headers:
  • Authorization
  • Content-Type
  • If-None-Match
  • Mcp-Session-Id
Browser JavaScript may read these response headers:
  • X-RateLimit-Limit
  • X-RateLimit-Remaining
  • X-RateLimit-Reset
  • Retry-After
  • ETag
  • X-Request-Id
  • X-Request-Cost
  • X-Batch-RateLimit-Limit
  • X-Batch-RateLimit-Remaining
  • X-Batch-RateLimit-Reset
  • Mcp-Session-Id
  • X-Mcp-Error-Code
Credentialed first-party routes such as /api/keys, /api/billing, and auth endpoints remain restricted to configured 0xinsider origins.

​
Trust metadata

Newer builder endpoints attach metadata to provider-owned values. Those endpoints are snapshots, history ranges, batch reads, and reports. The metadata lets you tell provider-backed, cached, partial, stale, and unavailable data apart. Per value, four dimensions:
  • source: where it came from (provider, database, cache, computed, client_input, unavailable).
  • freshness: how current it is (fresh, refreshing, stale, not_live, unknown, unavailable).
  • reconciliation: whether it was cross-checked against the source of truth (provider_backed, db_mirror, computed, partial, not_applicable, unavailable).
  • completeness: whether it reflects the full picture (complete, partial, not_computed, not_applicable, unavailable).
See Trust metadata for what each value means and how to request field-level trust with expand=trust. Rule of thumb: don’t flatten unavailable values into 0, [], or {}. Read the metadata. Surface “unavailable” to your consumer instead of inventing a zero. Provider data that quietly becomes 0 causes silent bugs downstream.