Developers

Build against one live data contract

PubFi publishes public catalog reads and exact capability detail before authentication. Use the selected route's current schema, readiness, and billing mode for execution.

Runtime first

The minimum reliable integration loop

Discover, inspect, select, and execute without collapsing those decisions into one opaque call.

  1. Enumerate the full catalog

    Follow every opaque next_cursor until it is absent. Do not combine partial or conflicting generations.

    Open the catalog
  2. Read exact capability detail

    Confirm raw path, method, request, response, readiness, and per-method billing before execution.

  3. Select in the client

    The client agent evaluates the returned contracts. PubFi does not infer intent or rank providers.

  4. Execute in one lane

    Send the exact path and method with the selected account credential or x402 payment proof. Never mix lanes.

Machine-readable

Public developer entry points

Use the artifact that owns the question before you add credentials.

Runtime OpenAPI

The Rust-generated OpenAPI 3.1 document for current PubFi HTTP routes.

Open OpenAPI

Hosted MCP

The public discovery manifest for catalog reads and protected execution tools.

Open MCP manifest

Agent guide

The current machine-readable boundary and execution guide.

Read agents.md

Authentication guide

A concise Markdown guide to public, account, OAuth, and x402 lanes.

Read auth.md

API lifecycle

Stable within the public REST major

PubFi publishes lifecycle changes before they affect an integration.

/v1 is the stable public REST major

PubFi does not silently remove routes or introduce breaking contract changes within the /v1 major.

Deprecations stay explicit

Future deprecations are documented and marked in Runtime OpenAPI. An affected response uses the Deprecation header when deprecation is scheduled. It uses the RFC 8594 Sunset header only after a removal date is committed.

No current removal is scheduled

No current /v1 route is scheduled for removal.

Access paths

Choose the lane the live route permits.

Public reads, account execution, accountless x402, and custom delivery keep separate authentication and billing boundaries.

  1. No account

    Public discovery and contracts

    Read Discovery, the complete Registry capability catalog, exact capability detail, Runtime OpenAPI, and public MCP catalog tools.

    No authentication is required for these read-only public resources.

    Open Developers
  2. Credits or account-bound :free

    Registered account

    Use a PubFi API key for HTTP execution or a PubFi API key or Supabase OAuth access token for protected hosted MCP tools.

    The selected credential must resolve to an admitted billing account. Exact :free variants remain account-bound and charge no Credit.

    Open app
  3. Exact live route quote

    Accountless x402

    Use the explicit HTTP or MCP x402 endpoint for a route that the live Registry currently enables for accountless payment.

    Do not send a Bearer credential. The unsigned request receives an exact payment challenge, and the signed retry uses the environment-matched x402 lane.

    Read the x402 guide
  4. Custom terms

    Custom delivery

    Use a separately scoped delivery when a production program needs custom source integration, data packaging, service levels, or support.

    Access, commercial terms, and delivery boundaries are confirmed in writing for the selected program.

    Discuss custom delivery

Authentication and access

PubFi authentication and payment lanes

Choose one lane for each request. PubFi rejects conflicting credentials and does not fall back from one lane to another.

  1. Public catalog and capability reads require no authentication.

  2. Registered HTTP execution uses a PubFi API key. Protected hosted MCP tools accept one PubFi API key or one valid PubFi MCP OAuth access token.

  3. Account-bound :free routes still require an admitted account credential and charge zero Credits.

  4. Accountless x402 uses the explicit x402 endpoint and rejects Bearer credentials.

  5. Provider credentials, account billing state, and payment material stay server-side.

Client boundary

Keep selection and orchestration in the client.

PubFi executes an exact selected route. It does not replace these developer-owned decisions.

You need PubFi to choose the provider

PubFi does not infer intent, rank capabilities, or select a route. The client agent owns that decision.

You need one universal request or response schema

Each capability keeps its exact route-specific request and response contract. PubFi does not flatten all providers into one schema.

You need automatic supplier purchase or settlement

PubFi accountless x402 is a seller-side payment lane for approved PubFi routes. It is not supplier procurement, wallet custody, or automatic provider payment.