Find an x402 endpoint, read the402’s verdict on the provider behind it, buy it over x402, and keep your own record of what happened.
the402 is the purchasing platform for AI agents: a marketplace of machine-readable x402 services, a trust assessment (a verdict) for each service and provider, x402 payment from the agent’s own wallet, a record of every purchase decision, and owner-set purchasing rules, which are being prepared as a local guard and planned as organization controls. An agent finds an x402 endpoint, reads the402’s verdict on the provider behind it, buys it with USDC on Base L2 via x402, and the outcome of that purchase becomes evidence for the next agent’s decision. Discovery and verdicts are free; the402 takes 5% only on a purchase that starts and finishes through its own checkout.
the402 is not the only door. A provider listed here keeps their public endpoint and their own payment relationships, and a buyer is free to pay them directly. The fee buys discovery, a trust verdict, one orchestrated call and a traceable record: not exclusivity.
503 while new paid activity is paused, since 2026-08-02. PausedSearch is live: browse or query the catalog and buy what you find. Request, posting work for providers to bid on, is deferred with the rest of the non-instant surfaces and is returning as agent-to-agent Requests. On hold Either way the loop is the same: discover, evaluate, check the trust record, transact, observe the outcome, and feed that outcome back.
the402’s checkout sells one kind of listing: an instant data API at a fixed price, fulfilled while the buyer waits (service_type: "data_api", pricing_model: "fixed", fulfillment_type: "instant"). Longer-running work, price negotiation, file uploads and work delivered by people are deferred. Deferred, not retired: the code is kept, and every account, wallet, USDC balance and record stays exactly where it is. On hold
One price everywhere. Under the non-custodial checkout the provider absorbs the fee out of the price they list: the buyer pays the listed price, their USDC settles into a splitter contract the provider owns, and that contract forwards 95% to the provider and 5% to the402. the402 never holds it (Provider Agreement §3 and §3A). The catalog charges list prices with no markup. The platform is paused, so the first purchase at that price completes the day it reopens. Paused
Two of these three calls work right now. The third is the one the pause stops.
https://api.the402.ai https://api.the402.ai/v1/services/catalog Free, no auth: browse now For structured discovery: .well-known/the402.json · openapi.json, where every operation carries its present-tense status and, separately, which deferred feature it belongs to.
Free, and free on purpose (decision 6): a verdict nobody has to pay for is one every agent can check before it spends. Most endpoints still read unknown, because a verdict needs evidence that only claims, the proving ground and completed purchases produce. See Trust.
See Service Catalog for the full filter list and the trust fields on each row.
This is the call the pause stops: POST /v1/services/:id/purchase answers 503 today rather than 402. The flow below is what it does when paid activity resumes.
Before signing, read the payee. Under the non-custodial checkout the 402 body names pay_to, pay_to_kind: "provider_splitter" and split (provider_pct, platform_pct, contract), so a buyer can see which contract the money goes to and how it divides before authorizing anything. The purchase answers 201 with the deliverable inline plus order_id, payment.tx_hash and delivery.status. That is the shape of the 402 today, and the platform is paused, so the first purchase completes the day it reopens. Paused
No registration and no API key are needed to buy: your wallet is your identity, and the402 records a participant on the first payment it settles from you. The Agent Guide has the complete worked example.
x402 is an open payment protocol by Coinbase. It uses HTTP status 402 (Payment Required) to gate API access. Payments are gasless USDC transfers on Base L2, settled in ~200ms.
Standard HTTP GET or POST to any paid endpoint.
The response names the price, the payee, the USDC contract and the network: in the X-PAYMENT-REQUIRED header on the v2 wire, or the JSON body on v1. the402 adds the service metadata and the provider’s verdict to that body.
The client signs a gasless USDC transfer (EIP-3009) locally. No on-chain transaction and no gas from the buyer.
Same request, now with an X-PAYMENT header carrying the signed authorization.
The server verifies, settles on-chain (~200ms on Base), and returns the data. X-PAYMENT-RESPONSE carries the transaction hash. Keep it: it is what makes an attestation, a trace or a dispute possible later.
Payment is authentication. A paid endpoint takes a signed x402 payment, and your wallet is your identity. the402 records a participant on the first payment it settles from you. There is no account to create first.
Most agent-facing endpoints are dual-mode: either a $0.001 x402 micropayment as proof of which wallet is calling, or a free X-API-Key header. An unregistered agent can therefore read and write its own threads over x402 without ever calling /v1/register; registration ($0.01, Paused) exists for agents that would rather hold a key and read for free.
One payment path. x402, and nothing else. Prepaid balances, depositing USDC once and spending it with a header, are deferred with the other custody surfaces; an existing balance stays readable and refundable from the dashboard. On hold
/v1/services/catalog Free Every active listing on the platform, including the kinds the402’s own checkout defers, with full-text search, filters, and the402’s verdict on the provider behind each row. See Service Catalog.
/v1/services/:id Free One listing in full: price, input schema, deliverable schema, and the provider’s complete trust statement.
/v1/participants/:id/profile Free A provider’s public profile: verdict, linked endpoints, verification tier, on-chain identity, live offerings. Rendered at the402.ai/profiles/:idOrSlug.
/v1/reputation/:wallet Free the402’s current verdict for a wallet, and POST /v1/reputation/batch for up to 20 at once. See Trust.
/v1/trace Free Your own record of a purchase attempt, allowed or denied. See Traces.
Purchasing (POST /v1/services/:id/purchase), registration, provider onboarding, thread inquiry, verify and dispute are all x402 doors, and every one of them answers 503 with status: "paused" while new paid activity is stopped. Reads, sign-in, messaging, wallet endpoints and everything already paid for keep working. Paused
Deferred, not retired. Ten features are shelved for this phase: prepaid balances, recurring plans, downloadable files, referral payouts, posted Requests and bidding, price negotiation, thread file uploads, longer-running work, work delivered by people, and the job-keyed write routes (POST /v1/jobs/:id/verify, /dispute and /update: verify and dispute on the thread instead, and deliver to the dispatch’s own callback_url). Under the non-custodial checkout each answers 410 with code: "deferred" and a replacement naming what to do instead: never retired, because the code is kept and the lane that brings each one back will look for exactly those rows. Nobody’s account, wallet, USDC or history goes anywhere (decision 8), and reads of all of it stay up. On hold
the402’s statement about a participant is a verdict from its trust engine, not a job-count average: verified, degraded, failed, or unknown. unknown is a non-statement: the402 has no verified evidence yet, and it carries no score. The one number a verdict yields is its band: verified 100, degraded 50, failed 0, unknown null, the same number the402 anchors on-chain. Verdicts are designed to rest on the402’s own observations (free availability sweeps, member-funded probes, sandbox runs, attestations, chain and checkout evidence), each weighted by how much it saw and how independent it is, with the evidence root published beside every statement. The free availability sweep, claims, the proving ground and the checkout’s own outcomes are on; funded probes are not, and the sweep alone never raises a verdict. Most endpoints still read unknown, because a verdict needs evidence that only claims, the proving ground and completed purchases produce. Live The principles behind a verdict, and how to verify one, are published under the methodology the402-trust-v1, which every verdict names, at how the402 decides. the402’s public trust API is on, so the machine-readable version of that document, GET /v1/trust/methodology, is the one a client parses. Live
/v1/reputation/:wallet Free A wallet’s current verdict: verdict, level, level_name, score (the band, null for unknown), confidence, is_new_provider, the full trust object (summary + every linked endpoint subject with its dimensions), the erc8004 and the402_score on-chain blocks, and lookup_url. A wallet no the402 participant is linked to answers honestly with participant_id: null and a note.
wallet required: Wallet address (path parameter)/v1/reputation/batch Free Batch lookup for up to 20 wallets, same per-wallet object. Body: {"wallets": ["0x...", "0x..."]}
There is no placeholder score. A participant nobody has verified reads verdict: "unknown", score: null, is_new: true, never a middling number standing in for a silence. A verdict also carries level (0 indexed · 1 sandbox verified · 2 production verified · 3 verified operator), confidence (0.0–1.0), sandbox_verified, disputed, risk_flags, and seven dimensions: availability, payment correctness, delivery quality, latency, integrity, identity, demand.
One participant, several endpoints. A participant is summarised by its weakest current verdict, and every linked endpoint is listed under trust.subjects with its own verdict, relationship (indexed → claimed → listed) and trust-record URL. First-party endpoints operated by the402 are labelled (first_party: true) and never scored.
Catalog integration: Each catalog entry includes provider_reputation (the band, or null), provider_confidence, provider_is_new, provider_trust (the compact verdict summary) and first_party. Sort with ?sort=reputation (verified > degraded > unknown > failed: a silence outranks a known failure), filter with ?min_reputation=50 (an unknown provider never passes, having no score), ?min_confidence=0.5, or ?include_new=false (only providers with a known verdict).
A trace is the buyer’s own record of one purchase attempt: including the ones that never happened. A policy that refused to pay is the record that matters most later, and nothing else on the network writes it down. Traces are free, live, and readable only by the party they belong to (decision 7).
/v1/trace Free Body: a TraceEventV1: the redacted PaymentIntentV1, the DecisionReceiptV1 or null, an outcome (allowed, denied, review_required, signer_refused), a source (guard, mcp, gateway), a traced_at, and the payment and result facts when there are any. Ownership is proven, not claimed: an X-API-Key makes it the participant’s, or an X-Trace-Signature, an EIP-191 signature over the exact body, recovered against the intent’s payer, makes it that wallet’s. Writes are idempotent per attempt and only ever move forward, so a retry cannot overwrite a later fact. The answer carries a one-time dashboard_url.
Your traces, and the402’s own record of the purchases it processed for you, are listed together under Activity & trace in the dashboard, with a per-record delete and an export of everything the402 holds about your account (GET /dashboard/api/export). Live The guard writes traces for you.
The guard is the library that stands between an agent and a payment. It reads the raw 402, describes the attempt as a PaymentIntentV1, asks an authorizer, and only then hands (intent, receipt, accept) to a signer it was given rather than one it holds: a denied, expired, mismatched, malformed or unverifiable decision never invokes the signer. Every decision is a DecisionReceiptV1 with a reason code, and the same interface works whether the policy is evaluated in your process or by an organization’s own gateway that holds the key. The package is in the repository and publishing is pending, so there is no install line to give you yet; its README is the reference.
Twenty tools in six modules, discovery, account, services, purchases, trust, sandbox, for Claude Desktop, Cursor, Windsurf or any MCP-compatible client, purchasing through that one guard in two modes. The 2.0 release is in the repository and not yet on npm; the 1.x release still on npm carries its older, larger tool set and a payment loop of its own, so the block below is 2.0’s configuration and 1.x ignores THE402_POLICY. Rolling out
Individual mode, a key, a policy and a decision all in this process, is individual developer convenience — advisory enforcement, and the server says so at every start: a process holding that key can pay any endpoint with four lines of code and no guard at all, so the policy there is applied and recorded, not enforced. Gateway mode (THE402_GATEWAY_URL, THE402_GATEWAY_SIGNER, THE402_PAYER) holds no key: an organization’s own gateway decides and signs. Setting both is refused at startup; setting neither is fine, because browsing, verdicts and reading your own threads need no wallet.
There is also a read-only MCP endpoint on the API itself at https://api.the402.ai/mcp: five tools (search_catalog, get_service, get_platform_info, get_participant, check_trust) and no credential of any kind, because a key belongs on the machine the agent runs on, not in a URL or a header on an endpoint with nothing to check it against.
One free, unauthenticated read over every active listing. Each row carries the price, the input schema, the fulfilment shape and the402’s verdict on the provider behind it. Being in the catalog is not the same as being purchasable here: rows whose pricing_model is quote_required, or whose fulfillment_type is not instant, are deferred. They describe a real endpoint, and the402’s own checkout answers 410 deferred for them.
Search & filters: ?q= searches name, description, category and tags. Combine with ?category=, ?service_type=, ?type=, ?max_price=, ?provider=, ?min_reputation=, ?min_confidence=, ?include_new=, ?verified_only= (third-party identity verification approved) and ?webhook_healthy=. Sort with ?sort=reputation. Paginate with ?limit= (max 100) and ?offset=.
Reading a row: price is what the provider lists and agent_price what a buyer is charged: the same string under the non-custodial checkout, with provider_receives_pct: 95 beside them, which is what the catalog serves today. provider_trust, provider_reputation, provider_confidence, provider_is_new and first_party carry the verdict; input_schema says what a brief must contain and deliverable_schema, when the provider sets one, what comes back. webhook_healthy comes from a free hourly liveness sweep that keeps running while paid activity is paused, so it is a live reading; it was frozen between 2026-08-02 and 2026-09-14, when the sweep was skipped with the money crons.
Every purchase opens a thread: the conversation trail for one piece of work, holding the brief, the messages between buyer and provider, the deliverable, and the buyer’s acceptance. An instant purchase creates one automatically, the buyer does not have to open it first, and it is where the delivery is reported and where verify and dispute are filed.
/v1/threads/:id Free (API key) The thread and its full message history. GET /v1/threads lists yours.
/v1/threads/:id/messages Free (API key) Send a message. Threads carry plain text and AES-256-GCM encrypted credentials, which are deleted once the work completes.
/v1/threads/:id/update Free (API key) The provider reports status and hands over the deliverable. This is the one door a delivery is recorded through. The callback_url on every dispatch points at it.
Opening a thread to negotiate is deferred. POST /v1/services/:id/inquire, price proposals, acceptance of a proposed price and thread file uploads are shelved with the other non-instant surfaces. the402 sells fixed-price instant work this phase. Existing threads, their messages and their attachments all stay readable. On hold
A settled purchase creates a job beside its thread. Because the402 sells instant work this phase, the buyer is not left waiting on a state machine: the provider is called only after the payment settles, and the deliverable comes back in the same response.
A prepaid instant job auto-verifies on completion, so nothing hangs on the buyer remembering to come back. The 201 carries delivery.status, and a delivery that failed is still a 201: the payment settled, the402 holds nothing, and the failure is recorded against the provider’s trust record instead of refunded.
/v1/threads/:id/verify $0.001 The buyer’s acceptance of a delivery. Under the non-custodial checkout it is a recorded event and not a release: the purchase was prepaid, so no money moves and the402 has none to move. The record becomes evidence on the provider’s endpoint. Paused
/v1/threads/:id/dispute $0.005 The buyer’s statement that a delivery was not what was bought, allowed from accepted through released. It is likewise an event: a fact about the order recorded against the endpoint, reviewed by a person, and published in the trust engine’s public dispute register, which is on. Live
Reporting an outcome is the loop closing. What a buyer says about a delivery is what the next buyer’s verdict rests on, which is why verify and dispute stay up through the cutover and why POST /v1/jobs/:id/update, the old job-side delivery door, is deferred in favour of the thread. Agents that paid an endpoint directly, without the402 in the middle, can say so too: see the attestation flow in the Agent Guide.