Concepts

The moving parts, once.

x402 (the payment protocol)

x402 uses HTTP 402 Payment Required. The first request to a paid URL returns 402 with an accepts list describing how to pay. The caller picks one option, signs a stablecoin authorization, and retries with an X-PAYMENT header. The server verifies the signature, settles it on-chain, then serves the response and returns an X-PAYMENT-RECEIPT.

• Scheme: exact (a fixed price per call) — the only scheme for beta.
• Asset: USDC. Atomic units use the destination chain’s precision (see Networks — 6 decimals on Base and Solana, 7 on Stellar).
• Routing key: every option is identified by (scheme, network), e.g. exact + eip155:8453.

Relays vs MCP wrappers

A dataset is a third shape that reuses the API-relay rails: an endpoint whose origin returns a download link instead of inline data, so a buyer pays once for a file rather than per query. See Selling datasets.

Parameters reach the origin

A buyer’s inputs are forwarded to the origin: any {placeholder} in the origin URL is filled and the rest pass through as query string. So a buyer calling /r/acme/profile?iso3=USA reaches an origin like …/countries/USA/profile. (How a buyer supplies them: query params on the relay URL, or the params arg of the connector’s call_endpoint.)

Buying through the connector — custody & budgets

The same authenticated connector that sells can also buy (see Buying with the connector). Two axes:

Custody — who signs/holds the funds:

• Custodial — the platform signs x402 from a managed wallet it holds for your account (works for agents that can’t sign crypto, like Claude). The default.
• BYO / agent-owned — you quote_endpoint, sign the x402 yourself, and pass the signed payment; settlement is non-custodial.
• Delegated — a capped spending key (spk_…) hands bounded spend to a separate agent process.

Budgets — how much autonomy:

• A buy job is a capped credential for a task (total budget + per-call ceiling
  • expiry), implemented as a spending key. The agent buys freely within it.
• An account policy is a standing guardrail (max per call + confirm-above threshold) applied to every buy.
• Anything over the policy needs explicit confirmation in chat.

Data samples & free trials (what a buyer sees before paying)

Because payment is the auth — buyers have no account and every real call costs — a buyer (usually an agent) needs to judge an endpoint before paying. There are two distinct, complementary things on offer, and they should never be confused:

The sample is synthetic by default. Its structure is real (derived from the origin), but the values are fabricated, so no real data is given away for free. A sample carries three independent state axes so an agent can decide how much to trust it:

• protection — what the example contains: synthetic (fabricated values, the default), redacted (real values masked, shape kept), or real (the actual captured response, for open data).
• provenance — how the schema was obtained: live (inferred from a real call to the origin), declared (the provider supplied a schema / example), or mcp_introspected (from a free MCP tools/list).
• freshness — fresh or stale relative to the endpoint’s refresh window.

A buyer reaches the sample two ways, both free and unauthenticated: the schema.json route, and the 402 body itself (see Buying). For how samples are provisioned, see Publishing.

Trust signals on a listing

Beyond the sample, each listing carries two earned trust signals so a buyer (or agent) can rank listings by track record, not just price:

• verified — the origin returned 2xx the last time we probed it (the ”✓ Verified working” badge).
• reliability — delivery track record over recent paid traffic: success_rate (delivered, including cached fallbacks, ÷ attempted), avg_latency_ms (mean origin round-trip), and sample_size over a rolling window_days. It’s null until an endpoint has paid traffic, and the UI hides the badge below a handful of calls so a tiny sample never reads as a verdict.

The splitter (non-custodial settlement)

Each chain has one immutable splitter contract. When a payment settles, the buyer’s USDC moves directly to the splitter, which atomically pays two legs in the same transaction:

• provider leg → the provider’s payout wallet (their full price)
• fee leg → datapoint.market’s protocol fee (charged on top, always visible)

datapoint.market never custodies funds; the splitter holds nothing between calls. A relayer wallet (operated by datapoint.market) only pays gas to submit the settlement — it never holds USDC.

Fees

Providers keep 100% of their price. The protocol fee is added on top and is shown in the 402 so the buyer sees the full amount before paying.

Networks & environments

• Networks are CAIP-2 ids: eip155:8453 (Base mainnet), stellar:pubnet (Stellar mainnet), plus their testnets eip155:84532 / stellar:testnet.
• Environment of an endpoint is test (settles on a testnet — sandbox/trial) or live (settles on mainnet — real money). An endpoint’s networks must all match its environment. A test endpoint and its live twin are separate endpoints.

Which networks actually settle depends on deployment config — check GET /x402/base/supported and GET /x402/stellar/supported, and note that a network only settles if its splitter/asset/relayer are wired. See Networks.

Accounts & authentication

Buyers never authenticate — they pay. Providers authenticate one of three ways:

1. Session cookie — magic-link email login (the web dashboard).
2. OAuth access token — “connect in Claude”: the management MCP runs an OAuth 2.0 + PKCE flow so an MCP client logs in with the provider’s account. See Connect in Claude.
3. Automation key (empk_…) — a bearer secret for programmatic/agent use. Mint one in the dashboard, or bootstrap with a wallet signature (/auth/wallet/challenge → sign → /auth/wallet/verify) — an agent can get a provider account with no email.

The management MCP (POST /mcp) accepts either an OAuth token or an empk_ automation key.

Origin auth (calling your real endpoint)

If your origin needs a credential, attach it when creating/editing the endpoint: auth_type of bearer | api_key | basic | custom plus the value (and a header name for api_key/custom). It’s encrypted at rest and injected server-to-server when the relay forwards — never exposed to buyers.

Next: pick a guide — buying, publishing, or connect in Claude.