I made my API machine-payable with x402 — AI agents pay per call in USDC, no account, no key

Most public APIs force you to pick a tier: free-with-limits, or "sign up for a key and start a trial." Both assume a human in the loop. The agent economy doesn't work like that. An agent can't click through a checkout, can't fill a KYC form, and shouldn't hold a standing API key that someone could abuse.

So I made the data I serve machine-payable: an agent (or a human, or a script) makes one HTTP call, pays a few cents in USDC on-chain, and gets the data back. No account. No API key. No billing portal. One transaction, one response.

This is x402 — an open pay-per-call standard that rides on the HTTP 402 "Payment Required" status code. I put it on remote-jobs-api.tten.no, a free, keyless API that normalizes live remote-job listings across 15 boards into one stable schema. Here's how it actually works, and what it means if you're building something that needs to buy data from another machine.

The shape of the problem

A normal "pay to use" API is designed for a human who will come back tomorrow, the day after, and the day after. So it needs identity (an account), a credential (an API key), and a billing relationship (a subscription or a metered invoice). None of those exist cleanly for a one-off machine call.

An agent that wants "what remote jobs are live right now" needs:

No identity — it shouldn't have to be a registered customer.
No standing credential — a leaked key is a standing attack surface.
Pay-as-you-go at the transaction level — pay exactly for this call, nothing standing.

x402 is built for exactly that. The server says "this costs $0.01, here's how to pay," the client pays on-chain, the server verifies and settles through a facilitator, and returns the data.

What the free tier gives you (still free, still keyless)

The base endpoint stays anonymous and free — you can always poke at the shape without paying:

curl https://remote-jobs-api.tten.no/v1/jobs?limit=10

That returns up to 10 normalized postings with a consistent shape: title, company, location, salary, remote_policy, source, posted_at, url. Good enough to see if the data is what you need.

The machine-payable tier

The full feed (all 15 sources, currently half a million live listings) sits behind /x402/jobs. Call it unpaid and you get a 402 — not a 403, not an "upgrade required" page. A structured payment requirement:

curl https://remote-jobs-api.tten.no/x402/jobs
# => HTTP 402
{
  "x402Version": 1,
  "error": "Payment Required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "10000",
      "payTo": "0xA223...",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "extra": { "name": "USDC", "version": "2", "assetTransferMethod": "eip3009" }
    },
    { "network": "solana", "asset": "Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8LLwX" }
  ]
}

Two rails: USDC on Base and USDC on Solana. The client picks one, signs a payment (an EIP-3009 transfer on Base, or the Solana equivalent), sends it back as a PAYMENT header, and the facilitator verifies and settles it. Once settled, the same call returns the real data. A malformed or failed payment gets a 402 back — never a 500.

The whole thing is stdlib-only on the server side — no web3 SDK, no new dependency. The "pay" is just a signed header the client attaches; the facilitator does the on-chain leg.

Why this is different from a key

One call, one payment, no relationship. Nothing is stored, nothing to revoke, nothing that leaks.
The price is in the response. A machine can read $0.01 out of the 402 and decide whether it's worth it, before it pays.
No human in the loop for the transaction. This is the part that actually unblocks agents. The only thing a human ever does is make sure the paying wallet has some USDC in it.

What I'm curious about

What would you price a per-call data endpoint at, and where's the line where "pay per call" starts costing more than "just sign up"?
If you're building an agent that buys from other APIs, how do you handle a 402 you've never seen before — do you trust the payTo address, check the price first, cap it?
Is the two-network choice (Base + Solana) actually useful, or does one rail dominate?

It's open source and on PyPI:

pip install remote-jobs-api

Run your own against your own feeds, or hit my instance. Feedback welcome.

DEV Community