Skip to main content
Every paid Cred Protocol endpoint is machine payable. An agent that calls a paid endpoint with no credentials gets back a 402 Payment Required that advertises three ways to pay; it picks one, attaches the payment to the retry, and gets the data. Nothing to sign up for.

API key

Metered against a plan. Authorization: Bearer <api_key>

x402

USDC on Base, SKALE or Tempo. X-PAYMENT: <signed payment>

MPP

Tempo, Stripe crypto deposit, or Cred credit. Authorization: Payment <credential>

Pricing

Everything is priced in Cred Units (CU), 1 CU = $0.01. The same price applies whether you pay with an API key, x402 or MPP. Agent-registry reads (/api/v2/agents, /agents/count, /agents/search, /agents/{id}) and /api/v2/health are free. The /mcp/* REST endpoints and MCP tools use the same prices — see MCP Services and GET https://api.credprotocol.com/mcp/tools.

The 402 response

Call any paid endpoint without credentials:
The body is human/LLM readable; the headers are what payment SDKs consume. Pick whichever rail your agent supports and retry.

x402

x402 is a one-round-trip USDC micropayment. The X-PAYMENT-REQUIRED header carries base64 PaymentRequirements (scheme exact, price in USDC, payTo address, one entry per accepted network). Sign a USDC transfer authorization with your wallet and retry with it in X-PAYMENT; the payment settles through the facilitator during the request and the response includes X-Payment-Transaction / X-Payment-Network. Networks: Base (8453), Base Sepolia (84532), SKALE Base (1187947933), SKALE Base Sepolia (324705682), and Tempo. SKALE is gasless with sub-second finality.
Full details, including per-network USDC contracts, are in the x402 section of the Authentication guide. Try it interactively at credprotocol.com/try.

MPP (Machine Payments Protocol)

MPP uses standard HTTP auth semantics: the server lists challenges in WWW-Authenticate: Payment …, the client fulfils one and sends the resulting credential in Authorization: Payment <base64url>, and the server returns a receipt in the Payment-Receipt response header. Each challenge has an id, a method, an intent (charge or credit) and a base64url request describing what to pay: The credential you send back is:
base64url-encoded into Authorization: Payment <credential>.
Receipts. Successful paid responses include Payment-Receipt: <base64url> decoding to {"status":"success","challengeId":"ch_…","method":"tempo","reference":"<tx hash or ref>","timestamp":"…"}. MPP over MCP. The MCP server (https://api.credprotocol.com/mcp) speaks the MPP MCP transport: a paid tool called without credentials returns JSON-RPC error -32042 whose data is the challenge; put the credential in _meta["org.paymentauth/credential"] on the retried tools/call and the receipt comes back in the result’s _meta["org.paymentauth/receipt"]. See MCP Services.

Validator (ERC-8004 trust assessments)

POST https://validator.credprotocol.com/v1/validate/{address} is $0.05 and accepts x402 (USDC on Base) and Cred credit; GET /v1/payment-methods lists what’s currently enabled. See ERC-8004 Validation.

Choosing a rail

  • You already have a plan → API key. Simplest, and usage shows up in the console.
  • Autonomous agent with a funded wallet → x402 (Base/SKALE/Tempo) or MPP tempo. One request, settles inline.
  • Agent that can’t hold crypto → MPP stripe (USDC deposit on Tempo via a Stripe-managed address).
  • Agent with on-chain reputation but no float → MPP cred: a Cred Score ≥ 640 unlocks session credit, settled afterwards.
Errors: 402 = no/insufficient payment (body explains); 401 = credentials present but invalid; 429 = rate limited. See Error Handling.