x402 Agent Identity: Give Your Paid Service a Public Name

x402 lets software pay for a resource. A headless domain gives the service behind that resource a public name that customers and other agents can return to. Its records help callers find the official API, learn who operates it, and locate the evidence behind its payment-related claims.

Someone might discover your service in a catalog, use it through an agent, and return later through another application. They should be able to recognize what they bought and find it again.

x402 already has mechanisms for discovery, wallet authentication, and signed transaction artifacts. Headless Domains can connect those mechanisms to the identity of the work you run. You do not need to discard your existing API or payment implementation.

What x402 already provides

The x402 payment flow starts with a resource request. When payment is required, the server returns HTTP 402 with payment instructions. A compatible client supplies a payment payload, which the service processes through its configured payment scheme, with or without a facilitator.

A provider can use this to sell API access, content, or a tool invocation without making every buyer complete a conventional account-and-checkout flow. Additional access requirements depend on the service.

Three optional extensions affect how you connect that payment flow to a public identity.

Bazaar helps clients find payable resources

The Bazaar discovery extension lets participating services describe paid endpoints and MCP tools for discovery through supporting facilitators. Clients can inspect information such as capabilities, pricing, and schemas. Availability depends on the integration; enabling x402 alone does not guarantee a listing everywhere.

SIWX lets a client prove wallet control

Sign-In-With-X, or SIWX, supports wallet authentication. A configured service can use it for repeat access to purchased resources or for routes that require authentication without payment.

That establishes something useful about the wallet. An application still needs evidence to associate it with a particular named agent or operator. Several agents might share a payment service, and one agent might use different wallets over time.

Signed offers and receipts provide evidence from a signer

The Signed Offers & Receipts extension supports signed transaction artifacts using EIP-712 or JWS. Its documentation also addresses how verifiers establish that a signing key is authorized for a service identity.

The signer and payment recipient are separate roles. A service can use a dedicated signing key while receiving funds at another address. Verification should establish the expected relationship rather than demand that both addresses match.

Make the service recognizable across applications

A catalog entry, wallet proof, and signed offer each help with a particular interaction. Your customer also needs to understand how they relate to the service they intended to use.

Suppose your agent produces accessibility reports. It has a paid API, documentation on your company website, and a listing in a discovery catalog. The report generator is the product customers remember. Its API host and payment infrastructure are implementation details that may change.

A headless domain gives that product a maintained public reference. Its records can point to the current service information, manifest, documentation, and contact route. Customers and compatible agents have somewhere to begin when they encounter a new endpoint claiming to represent it.

Your integration must verify the relationship between the named service, its endpoint, and any signing or payment identities it relies on. Matching descriptions across pages do not establish that relationship by themselves.

One named service, several technical identities

Consider accessreport.factory, a fictional name for the accessibility-report service. This is an illustration, not a registered customer example; availability has not been checked.

The operator publishes the service description and links to its API at https://api.example.com/accessibility. Its x402 implementation supplies payment requirements. Where signed offers are enabled, the client verifies the offer and the signer's authorization using the mechanism that implementation supports.

The public name, API URL, offer signer, and payment recipient do not have to be the same identifier. What matters is whether a caller can establish their relationship.

• Public name: identifies the report service customers recognize.
• API endpoint: receives the request for a report.
• Authorized signer: issues signed offers or receipts where supported.
• Payment recipient: receives funds under the selected payment arrangement.

If the operator moves the API, it can update the public records while retaining the name. Clients should review the changed destination before sending credentials, customer data, or payment. Name continuity makes the change easier to locate and explain; it does not automatically approve it.

Keep historical verification evidence separately. Today's profile cannot establish which signer or payment arrangement was authorized when an earlier purchase occurred. Our payment receipts guide covers the evidence to retain around a purchase.

Connect your x402 service to a headless domain

Start with the service customers actually buy. Give it a clear description, identify its operator, and publish the official route to its documentation and API.

Headless Domains provides hosted manifests and Markdown capability information linked through TXT records, as described in our manifest documentation. Use supported fields and linked operator documentation to describe your service. Where the platform schema does not define a payment or verification field, link to the appropriate document instead of inventing a platform API property.

For an x402 service, make the following information easy to find:

• The paid API or tool documentation and the output customers are buying.
• The implemented x402 schemes and extensions, including any client requirements.
• The documented relationship between the service, its payment provider, and its signing identities where applicable.
• Support, commercial terms, and notices about changed or retired interfaces.

Publish service information, not buyer budgets, private receipts, access tokens, or signing secrets. The live payment exchange remains responsible for the actual offer. A descriptive price in a profile should not override the payment requirements the client is evaluating.

Headless Domains' resolver gives compatible clients an HTTPS route to inspect the name and its linked information. The x402 request still goes to your service. Registering a name does not install payment middleware, or authorize spending.

For the buying application's approval checks, use Before Your Agent Pays an API. As the provider, give buyers the information they need to recognize your offering and evaluate those interfaces.

Choose a name that fits what you sell

A repeatable production service might fit .factory. A business process could fit .bpo, while a conversational offering might suit .chatbot. Other Headless Domains namespaces include .agent, .boss, .protocol, and .manifest.

Choose for the work people recognize. Any of these naming choices can sit alongside your service's compatible payment implementation.

Your API can remain on its existing conventional domain. The headless name gives the agent-operated offering an identity that connects its public surfaces. A useful paid service should be easy to find again, even when the customer arrives through another application.

Common questions

Does x402 require a headless domain?

No. A headless domain is a public identity for the service or agent using x402. The payment protocol works independently of that naming choice.

Does SIWX identify the agent running behind a wallet?

SIWX proves wallet control. Associating that wallet with a named agent, its operator, or a particular run requires additional verified information from the systems involved.

Does listing x402 in a manifest enable payments?

No. The service must implement the payment flow, and the client must support it. The manifest helps callers discover what the operator has made available.

Give your paid service a name customers can return to

If your agent already sells a useful output, connect its public name to the place that delivers it. Keep the API, payment documentation, and operator information consistent so the next customer can understand what they are buying and where to get it.

Share the Headless Domains getting-started instructions with your assistant and ask it to help choose a name for your service, explain the registration options, and plan its public records before taking action.