generated: '2026-09-02'
method: searched
source: >-
  https://x402-list.com/api/v1/openapi.json (components.securitySchemes is
  absent and no top-level `security` is declared), the auth prose at
  https://x402-list.com/api ("No authentication required for read access"), the
  machine-readable https://x402-list.com/.well-known/api-onboarding
  (account.required false, registration mechanism "open", credentials []), and a
  live unauthenticated GET https://x402-list.com/api/v1/stats that returned
  HTTP 200 with no credential of any kind.
description: >-
  There is nothing to authenticate with. x402 List issues no API keys, runs no
  OAuth, and has no account system — the onboarding descriptor lists an empty
  credentials array and calls the registration mechanism "open". This is the
  correct and complete auth profile, not a thin one: the OpenAPI declares no
  securitySchemes because there are none to declare, and an agent can call every
  read operation on first contact with zero setup.
  What replaces authentication is PAYMENT. Past the free quota, and on the two
  paid write operations, the API answers HTTP 402 with an x402 v2
  PaymentRequired envelope and the caller retries carrying a PAYMENT-SIGNATURE
  header signed by their own wallet. Authorization for the owner-update flow is
  separate again and is domain-proof based rather than credential based.
auth_required_for_reads: false
schemes: []
securityScheme_count: 0
openapi_security_declared: false
payment_authorization:
  protocol: x402 (HTTP 402 Payment Required), version 2
  request_header: PAYMENT-SIGNATURE
  challenge_header: PAYMENT-REQUIRED
  challenge_body_schema: PaymentRequired (components.schemas.PaymentRequired)
  receipt_header: PAYMENT-RESPONSE
  network: Base (EVM), USDC
  applies_to:
    - Metered reads past 2,000 GET/day per IP ($0.01/request)
    - POST /api/v1/assess ($0.25)
    - POST /api/v1/suggestions ($0.10)
    - POST /api/v1/submit, only for free-compute-host URLs ($1.00) or a resubmission within 14 days ($0.50)
  key_custody: >-
    The caller signs. The hosted MCP server states in its own initialize
    instructions that it "holds no keys", and the paid MCP tool takes
    payment_signature_b64 as a tool argument rather than reading a stored wallet.
ownership_authorization:
  flow: one-time domain proof
  operations: [requestServiceUpdate, verifyServiceOwnership, reissueOwnershipToken]
  mechanism: >-
    requestServiceUpdate returns a one-time token (returned once, never stored in
    clear). The owner publishes it as a line of a plain-text file at
    {base_url origin}/.well-known/x402list.txt on the CURRENTLY listed domain,
    then calls verifyServiceOwnership. The token expires after 72 hours and a
    verified request still goes to manual human review.
  docs: https://x402-list.com/api
docs: https://x402-list.com/api