Anteproof Forecasts API

openapi: 3.2.0
info:
  title: Anteproof Forecasts 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: Forecasts
paths:
  /v1/forecasts:
    get:
      summary: List Forecasts
      description: 'The public forecast log: live (non-backtest) forecasts, newest

        first, with their question text and resolution when one exists.

        A forecast whose question was later voided stays in the log (the

        forecast is part of the record) and carries ``question_status`` =

        "voided" plus the recorded ``voided_reason`` so it is never mistaken

        for an open call.

        ``question`` is the exact wording that was forecast and timestamped;

        ``title`` is a reader-friendly rendering of the same question (see

        foresight_api.titles) and falls back to the text.


        ``entity_kind`` is ``entity.kind`` for the question''s entity — the

        same column ``/v1/entities/{id}`` already publishes — and is null

        when the question has no entity (a market question) or the entity row

        is gone. It is here because ``entity_id`` alone cannot tell a

        dependency question from one about a company: an SEC Form D filer has

        a real ``entity_id`` exactly like tox-dev/tox does, and only the kind

        separates them ("company" vs "repo"). A client that is about

        dependencies -- the homepage''s two lists are -- filters on it; see

        SOFTWARE_ENTITY_KINDS in static/index.html.


        This endpoint itself does NOT filter. The archive is append-only and

        public by design, and an API that silently drops rows from the log is

        a worse answer than a page that curates its own two lists: the record

        has to stay complete for anyone checking it. The field is added so

        the curation can happen where the curation claim is made.


        ``resolved=true`` returns only forecasts whose question has an

        outcome, newest resolution first. That slice is what lets a reader

        check the record against what happened -- including the calls we got

        wrong, which are in it by construction rather than by the luck of a

        window ordered on issue date.'
      operationId: list_forecasts_v1_forecasts_get
      parameters:
      - name: limit
        in: query
        required: false
        schema:
          type: integer
          maximum: 100
          minimum: 1
          default: 25
          title: Limit
      - name: offset
        in: query
        required: false
        schema:
          type: integer
          minimum: 0
          default: 0
          title: Offset
      - name: resolved
        in: query
        required: false
        schema:
          type: boolean
          default: false
          title: Resolved
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                type: object
                additionalProperties: true
                title: Response List Forecasts V1 Forecasts Get
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
      tags:
      - Forecasts
components:
  schemas:
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
            - type: string
            - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
        input:
          title: Input
        ctx:
          type: object
          title: Context
      type: object
      required:
      - loc
      - msg
      - type
      title: ValidationError
  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.'