One verification stack.
Two ways to sign.

Human approval → agent key → purchase

1. 01You choose a service and approve a scope.
2. 02Your agent gets a key for that approval only.
3. 03ENS402 resolves, verifies and screens each purchase.
4. 04Privy or your signer signs. The merchant settles and returns data.

A key cannot create wallets, raise limits or approve a different service. A new service or recipient needs human approval. Endpoint updates continue only if the new exact URL was already approved. The resource API supports GET and bounded JSON POST requests at the ENS-published URL. POST orders require a UUID v4 orderId and a merchant supporting ENS402 request binding: the signed USDC nonce commits to the endpoint and exact body. Authentication headers are never forwarded.

Call the hosted API from an agent

The SDK is currently a workspace package in this repository, not a published npm release. Import its platform entry point from a linked checkout. Keep the API key in the agent runtime, outside prompts and browser bundles.

import { ENS402Client } from '@ens402/sdk/platform';

const client = new ENS402Client({
  baseUrl: 'https://ens402.vercel.app',
  apiKey: process.env.ENS402_AGENT_KEY!,
});
// Persist this ID before making the request.
const id = crypto.randomUUID();
const result = await client.purchase({ id, approvalId });
// If the connection drops, query this ID. Do not make a new payment.
const status = await client.execution(id);

For your signer, use purchaseWithSigner({ id, approvalId, approval, signer }). The local approval is independently checked before signing. Advanced clients can call prepare and submit separately.

POST /api/v1
Authorization: Bearer <agent key>
Content-Type: application/json

{"action":"execute","id":"<persisted UUID>","approvalId":"<approved UUID>"}

Agent operations: inspect, execute, prepare-external, submit-external, execution, balance, cancel and reconcile. An uncertain or submitting payment retains its budget until an actual USDC transfer and nonce are reconciled. A valid signature can still be submitted by someone who already possesses it after an app-level revocation.

Example: buy a subname for a recipient

Approve the ENS service pointing to /api/merchant/register. Purchase with a JSON POST order. The merchant settles Base Sepolia USDC and registers the native Sepolia subname directly to the recipient. No resolver is included, so the merchant retains no resolver administrator role.

await client.purchase({
  id: crypto.randomUUID(), approvalId,
  request: { method: "POST", body: JSON.stringify({
    orderId: crypto.randomUUID(),
    label: "alice", recipient: "0x..."
  }) }
});

Keep both IDs when recovering. Check GET /api/merchant/registration-orders/<orderId> for payment and registration transactions. A paid but incomplete order requires operator recovery, never another payment. Setup needs an enabled parent registry, a funded Sepolia worker with ROLE_REGISTRAR, a published service and a Base Sepolia USDC payer. This is a subname purchase, not arbitrary .eth registration.

Run the core yourself

Use @ens402/sdk/ens, /http, /intercepta and an independent signer. Your infrastructure supplies authentication, request transport, nonce persistence and settlement checks. Neither our database nor a Privy account is required for the core. A Skill explains this workflow to an agent; code and wallet policies enforce it.

What runs where?