> ## Documentation Index > Fetch the complete documentation index at: https://docs.0xinsider.com/llms.txt > Use this file to discover all available pages before exploring further. # Pick of the Day ledger > Returns the pre-game commitment for every published pick, so the public track record can be checked by someone who was not watching when the pick dropped. One entry per (pick_date, pick_rank), ascending by pick_date then pick_rank, in one of three states. `sealed` is a live pick: the hash, the algorithm, the seal instant and the kickoff, and nothing that states a side or a price. `opened` is a settled pick: the nonce and the exact canonical payload the hash was taken over. `uncommitted` is a pick with no commitment -- published before the scheme existed, or one that reached kickoff unsealed -- named rather than omitted. To verify an opened entry: serialize nothing. Take the bytes of the `payload` object exactly as received, append the `commitment_nonce` decoded from hex, and sha256 the result; it equals `commitment_hash`. The payload is canonical JSON -- keys sorted by UTF-8 byte value, no insignificant whitespace, decimals as strings at full stored precision, timestamps whole-second UTC with a literal Z -- and it is served byte for byte as it was hashed. This is a proof contract, not the archive's display contract: nothing here is formatted for rendering, so an entry changes only when the pick does. A commitment is never written after kickoff and never rewritten by an outcome correction; `resolved_at` moving under an unchanged `commitment_hash` is a corrected market re-mapping an already-settled pick. The pre-game commitment for every published pick, one entry per `pick_date` and `pick_rank`, ascending. Before a pick's game starts we publish `sha256(canonical_json(payload) || nonce)` over its date, slot, market, side, price, and kickoff; when it settles we publish the nonce and the payload, so anyone can confirm the pick existed, unchanged, before the game. For outcomes and the hit rate, use [Pick of the Day archive](/api-reference/endpoint/get-pick-of-the-day-archive). ## The three states Read `state` first. The shapes are disjoint. | `state` | What the entry carries | | ------------- | -------------------------------------------------------------------------------------------------------------------------------- | | `sealed` | A live pick: `commitment_hash`, `commitment_algo`, `sealed_at`, `kickoff`, `permalink`. No nonce, no payload, no side, no price. | | `opened` | A settled pick: the sealed fields plus `commitment_nonce`, `payload`, `outcome`, `resolved_at`, `matchup`, `category`. | | `uncommitted` | No commitment: published before the scheme existed, or reached kickoff unsealed. `pre_commitment` is `true`; no hash, no nonce. | `entry_count`, `sealed_count`, `opened_count`, and `uncommitted_count` come from the same pass. `uncommitted_count` only stops growing; no pick is ever retro-sealed. ## Verify an opened entry 1. Take the bytes of the `payload` object exactly as received. Do not reserialize it. 2. Append `commitment_nonce` decoded from hex. 3. SHA-256 the concatenation. It equals `commitment_hash`. The payload is canonical JSON, served byte for byte as hashed: keys sorted by UTF-8 byte value, no insignificant whitespace, decimals as strings at full stored precision, timestamps whole-second UTC with a literal `Z`. ## Example ```bash theme={null} curl -H "Authorization: Bearer $OXINSIDER_API_KEY" \ "https://api.0xinsider.com/api/v1/pick-of-the-day/ledger" ``` ## What it does not return * The backed side of a live pick. A pick payload is low entropy, so publishing the nonce early would hand out the side. * A commitment written after kickoff. A pick that reached kickoff unsealed stays `uncommitted` forever. * The outcome inside the hash. A corrected market re-maps a settled pick, so `resolved_at` can move under an unchanged `commitment_hash`. * Anything formatted for display. An entry changes only when the pick does, never with archive copy. ## Cache it Send the `ETag` back as `If-None-Match`. An unchanged ledger answers `304 Not Modified` with an empty body. ## OpenAPI ````yaml GET /api/v1/pick-of-the-day/ledger openapi: 3.1.0 info: x-generated-rate-limit-policy-from: web/src/lib/rate-limit-facts.ts via web/scripts/generate-api-policy.ts title: 0xinsider API description: >- Follow provider-exposed large-trade activity from Polymarket. Polymarket wallet-attributed trades can add grades, P&L, strategy, and diagnostic-score context when sufficient source data exists. Fields can be null or unavailable. Normal API requests use a 30-second server timeout that returns HTTP 408 Request Timeout with the standard error envelope (error.code request_timeout) when exceeded. Every /api/v1 failure answers that envelope, including a body that is not JSON or does not fit the request schema (400 invalid_body), a query or path value that does not parse (400 invalid_query, invalid_path), a missing Content-Type: application/json (415 unsupported_media_type), a body over 1048576 bytes (413 payload_too_large) and a method the path does not serve (405 method_not_allowed), each with error.param naming the field where one is known and meta.request_id equal to X-Request-Id. Public REST /api/v1/* endpoints, excluding /api/v1/mcp, use Bearer-token based non-credentialed browser CORS: any Origin may call with Authorization, Content-Type, If-None-Match, Idempotency-Key, and Mcp-Session-Id request headers. Remote MCP at /api/v1/mcp is non-credentialed, but still validates Origin against the 0xinsider/localhost allowlist per MCP Streamable HTTP DNS-rebinding guidance. Successful browser CORS preflight responses advertise Access-Control-Max-Age: 86400. Browser JavaScript may read RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, the legacy X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After, ETag, X-Request-Id, X-Request-Cost, X-Usage-Accounting, X-Batch-RateLimit-Limit, X-Batch-RateLimit-Remaining, X-Batch-RateLimit-Reset, Mcp-Session-Id, and X-Mcp-Error-Code response headers. Rate-limit headers describe the budget a request was counted against: the API key's per-minute window on an authenticated call, and the per-IP budget on a public route or on a refused credential (401, 402, 403, 423), so a client looping on a bad or lapsed key still sees how much room it has. Conditional GET: these operations return a weak ETag and answer If-None-Match with 304 Not Modified and an empty body: GET /api/v1/health, GET /api/v1/insider-radar, GET /api/v1/insider-radar/{id}, GET /api/v1/large-positions, GET /api/v1/leaderboard, GET /api/v1/leaderboard/trending, GET /api/v1/market/{condition_id}/candles, GET /api/v1/market/{condition_id}/intel, GET /api/v1/market/{condition_id}/snapshot, GET /api/v1/markets/explore, GET /api/v1/markets/sharp-money-flows, GET /api/v1/markets/smart-money-flows, GET /api/v1/pick-of-the-day, GET /api/v1/pick-of-the-day/archive, GET /api/v1/positions, GET /api/v1/sports-edge-observations, GET /api/v1/sports-edge-signals, GET /api/v1/trader/{address}, GET /api/v1/trader/{address}/context, GET /api/v1/trader/{address}/pnl, GET /api/v1/trader/{address}/position-timeline, GET /api/v1/traders/{trader}/position-timeline, GET /api/v1/whale-trades, GET /api/v1/whale-trades/history, GET /api/v1/whale-trades/{id}, GET /api/v1/whale-trades/{id}/counterparties/executions, GET /api/v1/whale-trades/{id}/counterparties/executions/{execution_id}/makers. Credentialed first-party routes such as /api/keys, /api/billing, and auth endpoints remain restricted to configured 0xinsider origins. Protected V1 responses, except the zero-cost /api/v1/usage route, after handler execution carry X-Usage-Accounting: persisted, failed, or unknown. This reports the usage-record write; it does not change the handler result. Do not replay a successful mutation to repair an unknown usage record. Before execution, unavailable accounting capacity returns HTTP 503 with error.reason=request_accounting_unavailable; honor Retry-After. Public API responses add the browser-readable Server-Timing header: Processing time in milliseconds, for example api;dur=12.345. Includes API authentication, quota admission, handler work and response construction. Excludes network transit and streamed body or export-file transfer. The engineering budget is strictly below 250 ms; this header reports observations, not a latency guarantee or a new timeout. version: 1.0.0 contact: name: 0xinsider email: support@0xinsider.com url: https://0xinsider.com servers: - url: https://api.0xinsider.com description: >- Production (live data). Authenticate with a live key (oxi_sk_live_...); requires an active Pro subscription. A sandbox key (oxi_sk_test_...) is answered with 401 invalid_api_key and error.reason sandbox_api_key. - url: https://0xinsider.com/sandbox description: >- Sandbox. No credential required and no production data: every documented operation answers with its documented example or a deterministic sample of its response schema. Add ?sandbox_status= to receive one of the error responses the operation documents (for example 429 with Retry-After). Request bodies and parameters are not validated, streams and file downloads are not simulated, and nothing is stored. A sandbox key (oxi_sk_test_..., issued with no account by POST https://api.0xinsider.com/api/v1/agents/register) is optional: on an operation that requires a credential, a well-formed key is answered with X-Oxi-Sandbox-Key: valid and a malformed one with 401 invalid_api_key. security: - bearerAuth: [] - oauth2: - read tags: - name: Traders description: Trader intelligence, batch lookups, timelines, and export readiness. - name: Positions description: Current prediction-market position snapshots from backend-owned mirrors. - name: Large Positions description: Largest current open positions from graded traders (Polymarket-only). - name: Whale Trades description: Recent and historical large trade intelligence. - name: Leaderboard description: Ranked trader discovery and category/strategy leaderboards. - name: Pick of the Day description: >- One sourced sharp-money call a day: the side profitable wallets are backing, with pre-game odds, the holders, and the track record. - name: Markets description: Market search, discovery, snapshots, and smart-score flow. - name: Content description: Search across 0xinsider editorial content. - name: Insider Radar description: Suspicious trading pattern flags. - name: Events description: Durable public event replay streams. - name: Streaming description: Resumable real-time Server-Sent Events stream of live feed envelopes. - name: Webhooks description: Signed builder webhook destinations and delivery controls. - name: Usage description: Developer API budget and usage introspection. - name: Onboarding description: >- Self-serve agent registration: a sandbox key with no account, and the path to live access. - name: System description: Health and operational status checks. - name: MCP description: Remote Model Context Protocol transport. - name: Reports description: Daily, weekly, monthly, and trader export report snapshots. - name: Account description: Identify the account and credential authenticated for a paid API request. externalDocs: description: 0xinsider API docs url: https://docs.0xinsider.com paths: /api/v1/pick-of-the-day/ledger: get: tags: - Pick of the Day summary: Get the Pick of the Day commitment ledger description: >- Returns the pre-game commitment for every published pick, so the public track record can be checked by someone who was not watching when the pick dropped. One entry per (pick_date, pick_rank), ascending by pick_date then pick_rank, in one of three states. `sealed` is a live pick: the hash, the algorithm, the seal instant and the kickoff, and nothing that states a side or a price. `opened` is a settled pick: the nonce and the exact canonical payload the hash was taken over. `uncommitted` is a pick with no commitment -- published before the scheme existed, or one that reached kickoff unsealed -- named rather than omitted. To verify an opened entry: serialize nothing. Take the bytes of the `payload` object exactly as received, append the `commitment_nonce` decoded from hex, and sha256 the result; it equals `commitment_hash`. The payload is canonical JSON -- keys sorted by UTF-8 byte value, no insignificant whitespace, decimals as strings at full stored precision, timestamps whole-second UTC with a literal Z -- and it is served byte for byte as it was hashed. This is a proof contract, not the archive's display contract: nothing here is formatted for rendering, so an entry changes only when the pick does. A commitment is never written after kickoff and never rewritten by an outcome correction; `resolved_at` moving under an unchanged `commitment_hash` is a corrected market re-mapping an already-settled pick. operationId: getPickOfTheDayLedger parameters: - name: If-None-Match in: header required: false description: >- Conditional GET validator from a previous ETag. Matching values return 304 Not Modified with an empty body. schema: type: string responses: '200': description: Pick of the Day commitment ledger headers: ETag: description: >- Stable validator for the current Pick of the Day ledger payload. Re-send it via If-None-Match for conditional GETs. schema: type: string RateLimit-Limit: $ref: '#/components/headers/RateLimit-Limit' RateLimit-Remaining: $ref: '#/components/headers/RateLimit-Remaining' RateLimit-Reset: $ref: '#/components/headers/RateLimit-Reset' X-RateLimit-Limit: $ref: '#/components/headers/X-RateLimit-Limit' X-RateLimit-Remaining: $ref: '#/components/headers/X-RateLimit-Remaining' X-RateLimit-Reset: $ref: '#/components/headers/X-RateLimit-Reset' X-Request-Id: $ref: '#/components/headers/X-Request-Id' X-Usage-Accounting: $ref: '#/components/headers/X-Usage-Accounting' Server-Timing: $ref: '#/components/headers/Server-Timing' content: application/json: schema: type: object required: - object - data - meta properties: object: type: string const: pick_of_the_day_ledger data: $ref: '#/components/schemas/PickOfTheDayLedger' meta: $ref: '#/components/schemas/ResponseMeta' examples: success: summary: One entry in each state value: object: pick_of_the_day_ledger data: entries: - state: uncommitted pick_date: '2026-06-22' pick_rank: 1 pre_commitment: true outcome: win matchup: Spain vs. France category: Soccer resolved_at: null permalink: https://0xinsider.com/pick-of-the-day/2026-06-22/1 payload: backed_price: '0.6100' condition_id: >- 0xabc1230000000000000000000000000000000abc7f7f7f7f7f7f7f7f7f7f7f7f kickoff: '2026-06-22T19:00:00Z' pick_date: '2026-06-22' pick_outcome_index: 0 pick_outcome_label: Spain pick_rank: 1 platform: polymarket - state: opened pick_date: '2026-09-20' pick_rank: 1 commitment_hash: >- 44d18fa5e2aa3a2bf3c971dcc9317c8ccbdfd5480a4773b6d8ffd5fbeeea84dc commitment_nonce: >- 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f commitment_algo: sha256(canonical_json(payload)||nonce) sealed_at: '2026-09-20T17:00:04.318271Z' resolved_at: '2026-09-21T02:41:09.552310Z' kickoff: '2026-09-20T23:05:00Z' payload: backed_price: '0.545000' condition_id: '0xabc' kickoff: '2026-09-20T23:05:00Z' pick_date: '2026-09-20' pick_outcome_index: 1 pick_outcome_label: Lakers pick_rank: 1 platform: polymarket outcome: win matchup: Lakers vs. Warriors category: Basketball permalink: https://0xinsider.com/pick-of-the-day/2026-09-20/1 entry_count: 2 sealed_count: 0 opened_count: 1 uncommitted_count: 1 meta: request_id: req_example cached: false cost: 1 '304': description: >- Not Modified. Returned when If-None-Match matches the current Pick of the Day ledger payload. headers: ETag: description: Validator for the unchanged Pick of the Day ledger payload. schema: type: string RateLimit-Limit: $ref: '#/components/headers/RateLimit-Limit' RateLimit-Remaining: $ref: '#/components/headers/RateLimit-Remaining' RateLimit-Reset: $ref: '#/components/headers/RateLimit-Reset' X-RateLimit-Limit: $ref: '#/components/headers/X-RateLimit-Limit' X-RateLimit-Remaining: $ref: '#/components/headers/X-RateLimit-Remaining' X-RateLimit-Reset: $ref: '#/components/headers/X-RateLimit-Reset' X-Request-Id: $ref: '#/components/headers/X-Request-Id' X-Usage-Accounting: $ref: '#/components/headers/X-Usage-Accounting' Server-Timing: $ref: '#/components/headers/Server-Timing' x-empty-body: true '401': description: Missing or invalid API key content: application/json: schema: $ref: '#/components/schemas/ApiError' '402': description: >- Active Pro subscription required. The key is valid but the account has no active Pro subscription; error.reason is subscription_inactive and error.message names the reactivation URL (https://0xinsider.com/billing). Permanent until a person reactivates: no Retry-After, never retry on a schedule. content: application/json: schema: $ref: '#/components/schemas/ApiError' '403': description: Account access denied content: application/json: schema: $ref: '#/components/schemas/ApiError' '408': description: >- The handler did not answer inside the server's 30-second timeout. error.code is request_timeout. On GET and HEAD the response carries Retry-After and error.retry_at; on a mutation it carries neither, because the request may have completed on the server: check its state before repeating it, and reuse its Idempotency-Key. content: application/json: schema: $ref: '#/components/schemas/ApiError' '423': description: Account is locked content: application/json: schema: $ref: '#/components/schemas/ApiError' '429': description: >- Rate limit exceeded. Three independent budgets. (1) 100 requests/minute per user (sliding window), on every authenticated route. (2) On the BATCH routes only: 2500 batch item units/minute per user, reserved before any item is executed. A batch with N requested items costs N item units, including duplicate and invalid items. 2500 = 100 requests x 25 items per batch, which is the most item work a key can buy through the request limiter at all: a caller may spend their entire 100-request minute on full 25-item batches without the item budget being what stops them. The REQUEST budget is the effective ceiling, and batching is never the more expensive choice. The item budget can still deny at a sliding-window boundary (both counters carry the previous window forward with a floor, and the item counter runs 25x the request counter), so honor a 429 from either. Over-quota batches return 429 with Retry-After plus RateLimit-Limit, RateLimit-Remaining, and RateLimit-Reset before any item work is done. (3) The monthly quota: Pro includes 250,000 authenticated requests per UTC calendar month, whatever the billing cadence. Over 250,000: with pay as you go on, requests keep answering and the excess bills at USD 0.20 per 1,000 on a monthly invoice, up to 1,000,000 requests a month; without it, from 1 October 2026 the next request answers 429 rate_limited with error.reason monthly_quota_exceeded and a Retry-After to the month's reset, and from the same day a pay-as-you-go account answers the same past 1,000,000. A refused request is not counted. Every authenticated response carries X-Monthly-Quota-Limit, X-Monthly-Quota-Remaining, and X-Monthly-Quota-Reset (unix seconds, the first of next month). (4) The per-address budget: 1200 requests/minute per IP, shared by every caller behind one address and counted before authentication, on every route. A 429 from it carries error.reason ip_rate_limited and describes that bucket in RateLimit-*; a throttled address (sustained over-limit traffic) carries error.reason ip_throttled with a Retry-After of minutes to days, and a request before it does not shorten the cooldown. Every 429 is the standard error envelope with meta.request_id equal to X-Request-Id. headers: Retry-After: description: Seconds until rate limit resets. schema: type: integer RateLimit-Limit: $ref: '#/components/headers/RateLimit-Limit' RateLimit-Remaining: $ref: '#/components/headers/RateLimit-Remaining' RateLimit-Reset: $ref: '#/components/headers/RateLimit-Reset' X-RateLimit-Limit: schema: type: integer X-RateLimit-Remaining: schema: type: integer X-RateLimit-Reset: schema: type: integer X-Request-Id: schema: type: string content: application/json: schema: $ref: '#/components/schemas/ApiError' '503': description: >- Redis-backed authenticated rate limiter unavailable; retry after the per-process outage cooldown headers: Retry-After: description: >- Seconds until the middleware will probe the Redis-backed rate limiter again. schema: type: integer X-Request-Id: schema: type: string content: application/json: schema: $ref: '#/components/schemas/ApiError' x-codeSamples: - lang: curl label: cURL source: |- curl -sS \ -H "Authorization: Bearer $OXINSIDER_API_KEY" \ 'https://api.0xinsider.com/api/v1/pick-of-the-day/ledger' components: headers: RateLimit-Limit: description: >- Request limit of the budget this request was counted against, for its current window: the API key's per-minute sliding window on an authenticated call; the per-IP budget on a public route and on a refused credential (401, 402, 403, 423), which never reaches the per-key limiter. Standard RateLimit header spelling. schema: type: integer example: 100 RateLimit-Remaining: description: >- Requests remaining in that budget's current window after this response. Standard RateLimit header spelling. schema: type: integer example: 84 RateLimit-Reset: description: >- Seconds until that budget's current window resets. Standard RateLimit header spelling. schema: type: integer example: 42 X-RateLimit-Limit: description: >- Request limit of the budget this request was counted against, for its current window: the API key's per-minute sliding window on an authenticated call; the per-IP budget on a public route and on a refused credential (401, 402, 403, 423). schema: type: integer example: 100 X-RateLimit-Remaining: description: Requests remaining in that budget's current window after this response. schema: type: integer example: 84 X-RateLimit-Reset: description: Unix timestamp when that budget's current window resets. schema: type: integer example: 1710772860 X-Request-Id: description: >- Server-generated request identifier for support and tracing. On every /api/v1 response, including 304, 408, CORS preflights and every error, and always equal to meta.request_id in the body. It is the key of the request's usage accounting row and of every log line the request emitted, so quote either form to support. A client-supplied X-Request-Id request header is ignored: the value is never adopted or echoed. schema: type: string example: req_550e8400 X-Usage-Accounting: description: >- Usage-record persistence for a protected V1 handler response. persisted: confirmed row; failed: write failed; unknown: completion could not be confirmed. Independent of handler success; do not replay successful mutations to repair accounting. Absent before accounting admission and on public routes. The zero-cost /api/v1/usage route also omits it. schema: type: string enum: - persisted - failed - unknown Server-Timing: description: >- Processing time in milliseconds, for example api;dur=12.345. Includes API authentication, quota admission, handler work and response construction. Excludes network transit and streamed body or export-file transfer. The engineering budget is strictly below 250 ms; this header reports observations, not a latency guarantee or a new timeout. schema: type: string example: api;dur=12.345 schemas: PickOfTheDayLedger: type: object description: >- The commitment ledger: every published pick, ascending, in the state its commitment is actually in. The counts are derived from entries in the same pass that builds it. required: - entries - entry_count - sealed_count - opened_count - uncommitted_count properties: entries: type: array description: >- One entry per published (pick_date, pick_rank), ascending by pick_date then pick_rank. items: $ref: '#/components/schemas/PickOfTheDayLedgerEntry' entry_count: type: integer description: Number of entries, all states included. sealed_count: type: integer description: Entries committed to and not yet settled. opened_count: type: integer description: Entries committed to and verifiable now. uncommitted_count: type: integer description: >- Entries carrying no commitment, so provable by nothing: the honest size of the unprovable part of the record. It only stops growing; no pick is ever retro-sealed. ResponseMeta: type: object required: - request_id - cached - cost properties: request_id: type: string description: >- Unique request ID (req_ prefix). The same value as the X-Request-Id response header, the request's usage accounting row and its log lines. cached: type: boolean cache_age_s: type: integer nullable: true description: >- Cache age in seconds. Omitted when the response was not cached, and also when it was cached but its age cannot be established (an entry stored before its cache carried a computed instant). Never a placeholder: an unknown age is reported as no value rather than as the cache TTL. cost: type: integer description: >- Advisory request weight (relative compute cost). 1 for simple reads; higher for heavier endpoints. Not a credit/price. ranking_generation: type: integer nullable: true description: >- Committed PostgreSQL-owned leaderboard generation for the returned rows and cursor. Present on GET /api/v1/leaderboard; omitted on endpoints that do not read this ranking. ranking_as_of: type: string format: date-time nullable: true description: >- Authoritative RFC3339 timestamp from cache_generations.updated_at for ranking_generation. It is read in the same repeatable-read snapshot as the leaderboard rows and is not request time, cache write time, or row insertion order. directional_source: type: string enum: - live - degraded description: >- Which path produced the team-directional read on this response. Only present on endpoints that compute one (today: GET /api/v1/sports-edge-signals). "live" means the read RAN. "degraded" means it FAILED, so nothing was measured and the ranking fell back to raw conviction. The flag describes the READ, not its consequence: a read that ran and found nothing groupable also leaves the directional fields null, and that is honestly "live" -- the per-signal nulls already say "nothing to enrich here", so this snapshot-level flag carries only what they cannot, namely whether the read ran at all. A degraded response is cached on the shorter degraded TTL so it self-heals. Reported SEPARATELY from ranking_source because the two degradations are independent -- a smart-money DB miss weakens the ranking DATA, a directional failure removes a ranking WEIGHT -- and a consumer down-weighting a degraded response needs to know which input it lost. Omitted on endpoints that compute no directional read. ranking_source: type: string enum: - live - db_only description: >- Which ranking-data path produced this response. Only present on endpoints that can degrade a ranking (today: GET /api/v1/sports-edge-signals). "live" is the normal path (the current holder pile from the provider batch); "db_only" is the degraded fallback (a truthful but weaker trader_markets ranking) served when the live sharp-money ranking batch is unavailable (a smart-money DB read failure, not a Polymarket outage) and cached on a shorter TTL, so a consumer can down-weight or skip it. Omitted on endpoints that never degrade. category_skill_source: type: string enum: - live - partial - degraded - unavailable description: >- Whole filtered snapshot category-evidence status before pagination. Operational live always remains partial source coverage. category_skill_model_version: type: string category_skill_taxonomy_version: type: string category_skill_platform: type: string const: polymarket category_skill_scope: type: string const: observed_goldsky_primary_taker_fill category_skill_source_coverage: type: string enum: - partial_whale_threshold_fills - graded_wallet_fills category_skill_observation_started_at: type: string format: date-time category_skill_model_operationally_degraded: type: boolean description: >- Whole-model operational readiness captured with the category model snapshot. Present on category-enriched responses even when the filtered signal list is empty. When true, category_skill_source is degraded and sports-edge-signals uses the shorter degraded cache TTL. category_skill_status_counts: type: object required: - live - insufficient - stale - unknown - degraded properties: live: type: integer minimum: 0 insufficient: type: integer minimum: 0 stale: type: integer minimum: 0 unknown: type: integer minimum: 0 degraded: type: integer minimum: 0 category_skill_base_payload_hash: type: string pattern: ^[0-9a-f]{64}$ description: >- SHA-256 of the funded signal membership/order/rank/cursor vector immediately before category-skill enrichment. Sports-edge-signals only. category_skill_enriched_base_payload_hash: type: string pattern: ^[0-9a-f]{64}$ description: >- Independent SHA-256 recomputation over the same base fields immediately after category-skill enrichment. Equality with category_skill_base_payload_hash proves shadow enrichment did not change funded inputs. Sports-edge-signals only. ApiError: type: object required: - object - error - meta properties: object: type: string const: error error: type: object required: - code - message properties: code: type: string description: >- FROZEN: an existing value never changes meaning. request_timeout (408, #16146) was added the way insufficient_scope was: the handler did not answer inside the server's 30-second timeout. Retry-After and retry_at ride on it only for a safe method (GET, HEAD); a timed-out mutation may have completed, so check its state and reuse its Idempotency-Key. enum: - bad_request - invalid_api_key - subscription_required - forbidden - insufficient_scope - not_found - account_locked - rate_limited - rate_limit_unavailable - internal_error - request_timeout message: type: string doc_url: type: string nullable: true param: type: string nullable: true retry_at: type: string format: date-time nullable: true description: >- The recommended next request instant (RFC3339), always in the future. Present on every retryable error: `pick_not_released`, `rate_limited`, `rate_limit_unavailable`, and `read_model_warming`. Omitted otherwise. The absolute twin of `Retry-After`; prefer the header for the sleep duration. For `pick_not_released`, the earliest of the next scheduled release, the next automatic selector attempt, the operating-window start, or about 60 seconds. See that response. reason: type: string enum: - cursor_expired - unknown_endpoint - pick_not_released - trader_not_tracked - read_model_warming - database_unavailable - request_accounting_unavailable - idempotency_in_progress - webhook_delivery_in_progress - webhook_secret_rotation_not_prepared - webhook_secret_rotation_overlap_active - sandbox_api_key - api_key_in_query - subscription_inactive - monthly_quota_exceeded - invalid_query - invalid_path - invalid_body - unsupported_media_type - payload_too_large - method_not_allowed - ip_rate_limited - ip_throttled nullable: true description: >- ADDITIVE (#7209). The specific, actionable cause behind `code`, when there is one more specific than the code itself. `code` keeps its published values, so existing clients are unaffected; new clients branch on `reason`. Omitted when the code already says everything we know. pick_not_released: no Pick of the Day is published for the current product day; schedule one request against retry_at instead of polling. unknown_endpoint: the PATH is not a route on this API -- read GET /api/v1, do not retry. trader_not_tracked: the wallet is real and the URL is right, but the trader is outside the HOT/WARM sync tiers -- stop asking for this wallet. cursor_expired: pagination went stale mid-walk -- re-request the first page and continue. read_model_warming: the requested endpoint cannot serve its read model yet; exact causes are endpoint-specific and can include a cold or contended refresh or a dependency that prevented refresh. database_unavailable: the API's database or its connection pool is temporarily unreachable (a connection-class failure, not a query fault); code stays rate_limit_unavailable, nothing is rate-limited, retry after Retry-After / retry_at. idempotency_in_progress: retain the exact Idempotency-Key and request body, then retry shortly. webhook_delivery_in_progress: retry the URL or signing-secret configuration change after the destination's active request completes. request_accounting_unavailable: accounting capacity is unavailable before the handler executes; retry after Retry-After / retry_at. sandbox_api_key: the credential is a sandbox key (oxi_sk_test_) from POST /api/v1/agents/register, which only the sandbox server accepts -- call the sandbox base URL with it, or get a live key or OAuth access token; do not retry it here. api_key_in_query: the key was sent as a ?token= query parameter, which no route reads because URLs land in logs and history; the key itself was not checked -- resend it as Authorization: Bearer. subscription_inactive: the key is valid but the account's Pro subscription has lapsed (402 subscription_required); permanent until a person reactivates at https://0xinsider.com/billing, which the message names -- stop retrying on a schedule and surface the link. The key owner is emailed once per lapse. monthly_quota_exceeded: the account has used the requests Pro includes for the UTC calendar month (429 rate_limited); retry_at and Retry-After name the first of next month, the only retry that can succeed, and the message names https://0xinsider.com/developers, where pay as you go for requests over the quota is turned on. The X-Monthly-Quota-Limit, X-Monthly-Quota-Remaining and X-Monthly-Quota-Reset headers on every authenticated response say how close the account is. invalid_query, invalid_path, invalid_body (400 bad_request, #16146): a query parameter, a path segment or the JSON body did not parse or does not fit the route's schema, so no handler ran; param names the field when the parser named one (a query key, a path segment, a JSON path such as traders[0], or body); fix the request, never retry it as sent. unsupported_media_type (415 bad_request, param content-type): send the body with Content-Type: application/json. payload_too_large (413 bad_request, param body): the body is over 1048576 bytes. method_not_allowed (405 bad_request): the path is a route but not with this method; the Allow header names the methods it serves. ip_rate_limited (429 rate_limited, #16380): the per-address budget every caller behind one IP shares, counted before authentication, is spent; not the key's own window, and the RateLimit-* headers describe that bucket. ip_throttled (429 rate_limited): the address is in a cooldown after sustained over-limit traffic; Retry-After is minutes to days, and a request before it does not shorten the cooldown. meta: $ref: '#/components/schemas/ResponseMeta' PickOfTheDayLedgerEntry: description: >- One ledger entry. Read `state` to know which shape you have; the three are disjoint. oneOf: - $ref: '#/components/schemas/PickOfTheDayLedgerSealedEntry' - $ref: '#/components/schemas/PickOfTheDayLedgerOpenedEntry' - $ref: '#/components/schemas/PickOfTheDayLedgerUncommittedEntry' discriminator: propertyName: state mapping: sealed: $ref: '#/components/schemas/PickOfTheDayLedgerSealedEntry' opened: $ref: '#/components/schemas/PickOfTheDayLedgerOpenedEntry' uncommitted: $ref: '#/components/schemas/PickOfTheDayLedgerUncommittedEntry' PickOfTheDayLedgerSealedEntry: type: object description: >- A published pick that has not settled. Carries the commitment and nothing that states a side or a price: no nonce, no payload, no outcome. Publishable the instant the pick releases. required: - state - pick_date - pick_rank - commitment_hash - commitment_algo - sealed_at - kickoff - permalink properties: state: type: string const: sealed pick_date: type: string format: date description: ET product day the pick belongs to (YYYY-MM-DD). pick_rank: type: integer description: 1-based daily slot within the product day. commitment_hash: type: string description: >- sha256(canonical_json(payload) || nonce), lowercase hex, no 0x prefix. Publishable the moment the pick releases: without the nonce it is not invertible. commitment_algo: type: string const: sha256(canonical_json(payload)||nonce) description: >- The construction the hash was taken with, stated in the response so a verifier never has to guess the serialization. sealed_at: type: string format: date-time description: >- When the hash was frozen. Always strictly before kickoff: a pick that reaches kickoff unsealed stays unsealed forever, because a seal written after the game started would be a backdated proof. kickoff: type: string format: date-time description: >- The frozen provider kickoff in the canonical payload form: whole seconds, UTC, literal Z. This exact string reappears inside payload.kickoff when the pick opens. permalink: type: string format: uri description: The pick's public page. PickOfTheDayLedgerOpenedEntry: type: object description: >- A settled pick whose commitment is open: the nonce plus the exact payload the hash was taken over. Concatenate the payload bytes as received with the decoded nonce and sha256 them to reproduce commitment_hash. required: - state - pick_date - pick_rank - commitment_hash - commitment_nonce - commitment_algo - sealed_at - resolved_at - kickoff - payload - outcome - matchup - category - permalink properties: state: type: string const: opened pick_date: type: string format: date description: ET product day the pick belongs to (YYYY-MM-DD). pick_rank: type: integer description: 1-based daily slot within the product day. commitment_hash: type: string description: >- sha256(canonical_json(payload) || nonce), lowercase hex, no 0x prefix. Publishable the moment the pick releases: without the nonce it is not invertible. commitment_nonce: type: string description: >- The 32-byte nonce the hash was taken over, lowercase hex, no 0x prefix. Secret while the pick is live: a pick payload is low entropy, so a published nonce on a live pick would hand out the backed side. commitment_algo: type: string const: sha256(canonical_json(payload)||nonce) description: >- The construction the hash was taken with, stated in the response so a verifier never has to guess the serialization. sealed_at: type: string format: date-time description: >- When the hash was frozen. Always strictly before kickoff: a pick that reaches kickoff unsealed stays unsealed forever, because a seal written after the game started would be a backdated proof. resolved_at: type: - string - 'null' format: date-time description: >- When outcome was LAST written to a settled value, or null when that instant is unknown. It moves with a corrected market re-mapping an already-settled pick, while commitment_hash stays untouched -- which is how a mirror that keeps history sees a correction. kickoff: type: string format: date-time description: >- The frozen provider kickoff in the canonical payload form: whole seconds, UTC, literal Z. This exact string reappears inside payload.kickoff when the pick opens. payload: $ref: '#/components/schemas/PickOfTheDayCommitmentPayload' outcome: type: string enum: - win - loss - void description: >- How the pick settled. Never pending: a pending pick is a sealed entry. matchup: type: string description: Frozen matchup, for a reader. category: type: string description: >- Frozen canonical sport bucket used for selection calibration (Basketball, MMA), not the exact public league identity; the archive owns that. permalink: type: string format: uri description: The pick's public page. PickOfTheDayLedgerUncommittedEntry: type: object description: >- A published pick with no commitment: it predates the scheme, or it reached kickoff unsealed. Nothing here is evidence of WHEN the pick was made. It is emitted rather than skipped, because a ledger with holes where the unprovable picks were would silently flatter the record. Once the pick settles, payload names its market, side and price, so the outcome can still be checked against the market's own resolution. required: - state - pick_date - pick_rank - pre_commitment - outcome - matchup - category - resolved_at - payload - permalink properties: state: type: string const: uncommitted pick_date: type: string format: date description: ET product day the pick belongs to (YYYY-MM-DD). pick_rank: type: integer description: 1-based daily slot within the product day. pre_commitment: type: boolean const: true description: 'Always true: this pick has no commitment and never will.' outcome: type: string enum: - pending - win - loss - void description: How the pick settled, or pending. matchup: type: string description: Frozen matchup, for a reader. category: type: string description: >- Frozen canonical sport bucket used for selection calibration (Basketball, MMA), not the exact public league identity; the archive owns that. resolved_at: type: - string - 'null' format: date-time description: >- When outcome was LAST written to a settled value, or null when that instant is unknown. It moves with a corrected market re-mapping an already-settled pick, while commitment_hash stays untouched -- which is how a mirror that keeps history sees a correction. payload: description: >- The pick's market, side and price once it has settled; null while it is pending, and null for a settled pick whose stored row lacks one of these columns. Not hashed: nothing was committed over these values, which is what pre_commitment: true says. oneOf: - $ref: '#/components/schemas/PickOfTheDayUncommittedPayload' - type: 'null' permalink: type: string format: uri description: The pick's public page. PickOfTheDayCommitmentPayload: type: object description: >- The frozen identity of the pick, exactly as the hash was taken over it. Served byte for byte as it was hashed -- keys sorted by UTF-8 byte value, no insignificant whitespace -- so a verifier concatenates and hashes with nothing to reconstruct. Property order below is the wire order. The outcome is deliberately NOT part of it: surviving a corrected outcome unchanged is the case the commitment exists for. Worked example: {"backed_price":"0.545000","condition_id":"0xabc","kickoff":"2026-09-20T23:05:00Z","pick_date":"2026-09-20","pick_outcome_index":1,"pick_outcome_label":"Lakers","pick_rank":1,"platform":"polymarket"} with the nonce 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f hashes to 44d18fa5e2aa3a2bf3c971dcc9317c8ccbdfd5480a4773b6d8ffd5fbeeea84dc. required: - backed_price - condition_id - kickoff - pick_date - pick_outcome_index - pick_outcome_label - pick_rank - platform properties: backed_price: type: string description: >- Frozen pre-game price of the backed side, 0..1, as the plain decimal text of the stored NUMERIC at full stored precision, trailing zeros included. A string, never a number: a float round-trip would change the bytes and break the hash. Deliberately not normalized -- 0.545000 stays "0.545000". condition_id: type: string description: Provider condition id of the backed market. kickoff: type: string format: date-time description: >- Frozen provider kickoff, whole seconds, UTC, literal Z. Fixed precision, never a shortest-lossless rendering. pick_date: type: string format: date description: ET product day (YYYY-MM-DD). pick_outcome_index: type: integer enum: - 0 - 1 description: Index of the backed outcome within the market. pick_outcome_label: type: string description: Frozen display label of the backed outcome. pick_rank: type: integer description: 1-based daily slot. platform: type: string description: Provider platform. PickOfTheDayUncommittedPayload: type: object description: >- A settled uncommitted pick's market, side and price. The same eight fields as PickOfTheDayCommitmentPayload, in the same key order, so a settled pick's side and price sit under payload whatever the entry's state. It is NOT a commitment: no hash was taken over it before the game, and it proves nothing about when the pick was made. required: - backed_price - condition_id - kickoff - pick_date - pick_outcome_index - pick_outcome_label - pick_rank - platform properties: backed_price: type: string description: >- Frozen pre-game price of the backed side, 0..1, as the plain decimal text of the stored NUMERIC at full stored precision, trailing zeros included -- rendered exactly as the commitment payload renders it. condition_id: type: string description: Provider condition id of the backed market. kickoff: type: - string - 'null' format: date-time description: >- Frozen provider kickoff, UTC, literal Z; null when no kickoff was frozen. Whole seconds render exactly as the commitment payload does; a sub-second instant keeps its fraction rather than being truncated, since nothing here is hashed. pick_date: type: string format: date description: ET product day (YYYY-MM-DD). pick_outcome_index: type: integer enum: - 0 - 1 description: Index of the backed outcome within the market. pick_outcome_label: type: string description: Frozen display label of the backed outcome. pick_rank: type: integer description: 1-based daily slot. platform: type: string description: Provider platform. securitySchemes: bearerAuth: type: http scheme: bearer description: >- API key or OAuth 2.1 access token in the Authorization header as `Bearer oxi_sk_live_...` or `Bearer oxi_at_...`. Data calls require an active Pro subscription and return live data. A 401 carries WWW-Authenticate: Bearer resource_metadata="https://api.0xinsider.com/.well-known/oauth-protected-resource" (RFC 6750 section 3, RFC 9728). oauth2: type: oauth2 description: >- OAuth 2.1 authorization code flow with PKCE S256 for apps and MCP clients acting for a user. Public clients only (no client secret): register with RFC 7591 at https://api.0xinsider.com/oauth/register or present an https client ID metadata document URL as client_id. Authorization server metadata: https://api.0xinsider.com/.well-known/oauth-authorization-server. The access token (oxi_at_..., one hour) is sent as `Authorization: Bearer`; refresh tokens rotate on every use. A route outside the token's scopes answers 403 insufficient_scope. Walkthrough: https://0xinsider.com/auth.md. flows: authorizationCode: authorizationUrl: https://0xinsider.com/oauth/authorize tokenUrl: https://api.0xinsider.com/oauth/token refreshUrl: https://api.0xinsider.com/oauth/token scopes: read: >- Read markets, traders, large trades, positions, reports, search, the event stream and every MCP tool webhooks: Create, list, verify, rotate and delete webhook endpoints export: Start, poll and download trader exports usage: Read the caller's API usage counters ````