Skip to main content
Most APIs already have keys, quotas, and rate limits. What they don’t have is a way for an AI agent to buy access without a human in the loop — no Stripe Checkout, no signup form, no API console. This use case wires that missing piece in with a single new endpoint on your side. Agents pay through Nevermined x402, you mint or top up an API key, and the rest of your stack — metering, rate limits, billing analytics — keeps working exactly as it did before.

​
What it looks like in production

Exa is the live reference. Agents POST a Nevermined-issued x402 token to https://admin-api.exa.ai/team-management/nevermined/purchase-key — $7 is charged on a delegated card, Exa returns an API key with $7 of credits, and the agent uses that key against the regular Exa search endpoints. When the key runs out, the agent calls the same purchase endpoint again. Same key, more credits, no human touched it. The whole integration on Exa’s side: one endpoint, zero changes to their existing metering.

​
When to pick this pattern

Pick this — Vend-the-key

  • You already have an API with its own keys, quotas, rate limits
  • One purchase maps to a fixed unit (e.g. $7 → 10K requests)
  • You want integration cost to be a single new endpoint
  • You’d rather not change how you bill on the hot path

Pick the alternative — Full metering

  • You don’t have your own metering yet
  • Per-call settlement with variable cost matches your product
  • You want Nevermined to handle quota tracking end-to-end
  • See Charge credits and Validate requests
Both patterns ride the same x402 protocol. They differ only in where in the request flow the payment happens — at purchase time (this page) or at every call (http-simple-agent-ts style).

​
Build it

The full technical guide — server-side handler in TypeScript, Python, and raw HTTP, plus the optional middleware variant — lives on the API Providers solutions page.

API Providers — implementation guide

5-step flow, code samples, idempotency notes, FAQ. Start here when you’re ready to wire it up.
For a runnable end-to-end example you can clone today:

Tutorial — web-search-paid-api-ts

Express server with /purchase-key + /search that mirrors the Exa pattern against a stub web-search service. Uses the facilitator API directly (not the middleware) so the verify → settle → provision flow is visible. Ships with a copy-paste llms.txt + nevermined.md template.

​
Make it agent-discoverable

A paid API only works for agents if they can find the integration on their own. Convention, lifted from Exa: publish a static llms.txt at your docs root that links to a nevermined.md integration page. Any LLM that knows the llms.txt convention can then read, understand, and act on the integration without you doing anything else.

Agent discoverability

How to publish a llms.txt + nevermined.md that agents will pick up. Includes a copy-paste template.

​
A note on the redemption ordering

When you implement the handler, the safe ordering is verify → settle → provision. Verify checks the token, settle moves the money, provisioning the key happens last because it’s local and easy to make idempotent on retry. If settle fails, no key has been issued — the customer is neither charged nor served. Cleaner outcome than provisioning first and then discovering the settle failed. This isn’t a footnote — getting the ordering wrong leaks quota on declined cards. The tutorial linked above implements it correctly; the deeper solutions page walks through the steps in detail.