Anteproof Anchor API

openapi: 3.2.0
info:
  title: Anteproof Anchor API
  description: 'Read-only access to the Anteproof forecast archive: live forecasts, question detail, and the full calibration/launch-gate audit trail. Anteproof is a product of Recoilix LLC.'
  version: 0.1.0
tags:
- name: Anchor
paths:
  /v1/anchor/latest:
    get:
      summary: Anchor Latest
      description: 'The latest daily anchor: the receipt that commits the forecast

        log''s chain head to OpenTimestamps and an RFC 3161 TSA, plus where to

        fetch it and its proofs from. The receipt is written by a separate

        job (packages/anchor) into the public log repo; this box serves the

        file when it mounts that checkout read-only and answers ``receipt:

        null`` with the same pointer URLs when it does not — the repo is

        authoritative either way. ``chain_head`` is LIVE, so it normally sits

        ahead of the receipt''s ``head_id``. See foresight_api.anchor.'
      operationId: anchor_latest_v1_anchor_latest_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                additionalProperties: true
                type: object
                title: Response Anchor Latest V1 Anchor Latest Get
      tags:
      - Anchor
components:
  securitySchemes:
    clerkSessionBearer:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: 'A Clerk session token, sent as `Authorization: Bearer <jwt>`. The signature (RS256, against the configured Clerk JWKS) and the expiry are verified; the issuer and the authorized party are also checked where they are configured. An operation marked with this scheme refuses a request that does not carry a valid session token. An Anteproof API key is not accepted in its place.'
    anteproofApiKey:
      type: apiKey
      in: header
      name: X-API-Key
      description: 'An Anteproof API key (`ap_…`), created at https://anteproof.com/account. On the public operations in this document — the ones that list no security requirement — it may be sent either as `X-API-Key: ap_…` or as `Authorization: Bearer ap_…`. It is OPTIONAL on those: a request without it is served just the same, and a request with a live key is counted against the account''s monthly allowance (the reply then carries X-Api-Calls-Used, X-Api-Calls-Limit and X-Api-Calls-Reset). It is not a session credential: an operation marked `clerkSessionBearer` refuses it with 401, live key or not. An `ap_…` key that is invalid or revoked is refused with 401 on any operation in this document; otherwise the key is optional. Because no operation requires one, no operation in this document lists this scheme. The MCP endpoint at /mcp, which this document does not describe, requires a credential — an API key or an OAuth sign-in — for every call except discovery: a POST whose JSON-RPC messages are all `initialize`, `notifications/initialized`, `ping` or `tools/list` is served without one.'
    stripeWebhookSignature:
      type: apiKey
      in: header
      name: Stripe-Signature
      description: 'Stripe''s webhook signature: `t=<unix>,v1=<hex hmac-sha256 of "<t>.<body>">`, checked against this endpoint''s signing secret with a five-minute tolerance on `t`. A request whose signature does not verify is refused with 401. This operation receives Stripe''s callbacks.'