Overview
The Agentic API is the x402-paid surface for Brickken agentic methods. It covers ERC-8004 identity, reputation, and agent-owned ERC-20 operations on Base, plus ERC-8226 RAMS mandates on Ethereum Sepolia. Every agentic operation is a two-step flow:- Prepare the unsigned transaction. In
brickken-relayedmode this is free; inclient-signedandclient-broadcastmodes the operation charge is split between prepare and send. - Send the operation. The remaining x402 USDC charge is collected here.
brickken-relayed(recommended). You do not sign the blockchain transaction. You pay the x402 charge and Brickken’s relayer signs, pays native gas, and broadcasts the operation on your behalf. No EOA, no native gas, no on-chain signing on your side.client-signed. You sign the prepared blockchain transaction with your own private key and submit the signed payload. Use this when you want to retain full self-custody of signing.
Base URLs
Networks
The Agentic API runs on Base, with Base Sepolia for tests. The x402 payment rail is operation-aligned: you pay on the same chain the operation runs on.Authentication Flow
For x402, omitx-api-key.
- Prepare. Call a semantic facade such as
POST /x402/agent/register, orPOST /prepare-transactionswith an eligiblemethod. For relayed execution, passexecutionMode: "brickken-relayed". The response returnstxId,transactions, and anx402Requirementsquote. Relayed preparation is free; client-controlled preparation may return a payment challenge for its share of the operation price. - Send. Call
POST /send-transactions. The API responds402 Payment Requiredwith aPAYMENT-REQUIREDheader describing the exact chain, asset, transfer method, amount, recipient, and timeout. - Sign the x402 payment locally with the payer’s private key, and retry the send with
X-PAYMENT. - Brickken verifies the payment, then (in
brickken-relayedmode) signs and broadcasts the operation. The settlement is returned in thePAYMENT-RESPONSEheader.
For an agent facade, a
400 before a txId is request validation, not an insufficient x402 balance. x402 payment begins only when send-transactions returns 402 Payment Required.PAYMENT-REQUIRED; do not hardcode them client-side. On Base Sepolia the payment rail uses EIP-3009, whose signed authorization carries the transfer, so no separate ERC-20 approve transaction is required. On Base mainnet, follow the advertised token’s transfer method.
In
brickken-relayed mode, x402 payment is mandatory — API keys are not accepted on the send step. The payment is reserved when you pay and only settled after the operation confirms on-chain. If the operation reverts or its authorization expires before confirmation, the reservation is released.Base Sepolia Testing
UsechainId: "84532" (eip155:84532). The Base Sepolia x402 payment asset is Circle USDC:
USDC, version 2, authorization window 300s). Fund the payer with the exact asset advertised by PAYMENT-REQUIRED before signing. The Base Sepolia ERC-8004 registries are:
- Identity:
0x8004A818BFB912233c491871b3d84c89A494BD9e - Reputation:
0x8004B663056A597Dffe9eCcC1965A193B7388713
Discovery
https://api.brickken.com) is the public x402scan target. Sandbox exposes the same discovery routes for QA.
Prepare and Send
The semantic/x402/... routes prepare unsigned transactions and do not submit transactions on-chain by themselves. Agent and token facades default to relayed execution, so their prepare is free; pass a client-controlled mode when you want to sign locally and expect the mode’s prepare charge.
Brickken-relayed (recommended)
Prepare withexecutionMode: "brickken-relayed" and omit signerAddress — Brickken supplies its relayer as the signer.
txId, exactly one transaction { to, data, value }, and x402Requirements. Submit those to send-transactions and complete the x402 payment; Brickken signs and broadcasts:
Client-signed
Prepare with your ownsignerAddress, sign the returned transaction locally, then send the signed payload:
send-transactions x402 batches must contain only x402-eligible prepared transactions, and all transactions in the batch must be on the same chain. A brickken-relayed send carries a single txId and exactly one transaction.
Polling
For relayed operations, poll status withGET /get-transaction-status by txId or operation hash — no API key is required for brickken-relayed transactions. A response of status: "pending" means the operation was broadcast but not yet confirmed; do not pay or resubmit the same txId again. Brickken’s reconciliation settles after confirmation or releases the payment on revert or authorization expiry.
Endpoint Groups
Facade requests use the same body fields as the matching backendmethod, except method is optional and ignored because the path fixes it.
Agent Identity
Register, maintain, and transfer ownership of ERC-8004 agent identities.
Reputation
Give, revoke, and respond to ERC-8004 feedback.
Agent Tokens
Create and operate agent-owned ERC-20 tokens.
RAMS Mandates
Delegate compliance-gated, scoped, capped authority to AI-agent wallets with ERC-8226.
Pricing
Review execution-mode-aware prepare and send prices.
POST /prepare-transactions directly and pass method explicitly. newTokenizedAgent remains a legacy alias for agent registration, but it is not published in x402scan discovery.
The ten RAMS methods (ramsGrantMandate, ramsRevokeMandate, ramsExtendMandate, ramsSetOperator, ramsExecute, ramsSetExecutorAction, ramsFreezeAgent, ramsUnfreezeAgent, ramsGrantPrincipal, and ramsRevokePrincipal) are also eligible through /prepare-transactions. Their semantic facades live under /x402/rams/*.
RAMS facades default to
client-signed, unlike ERC-8004 facades that inject the relayed mode by default. Only the four signature-authorized lifecycle calls may use brickken-relayed; see RAMS Mandates.Common Fields
Response Shape
The prepare response includestxId, transactions, and optional info. For agentRegister, save info.agentUuid for later set-uri, set-metadata, and transfer-ownership calls.