# Free trials for agents: the dust-amount x402 rail

> How an autonomous agent tries a paid x402 API with no account and no code change — a symbolic dust-amount rail in the 402 challenge, signed like a paid call and never settled.

Published 2026-07-11 · Updated 2026-08-16 · HTML version: https://invoket.com/blog/free-trials-for-agents-the-zero-amount-rail

---

An agent should be able to *try* a paid API exactly the way it *buys* it. Invoket
implements free trials as **one extra rail in the standard `402` challenge, at a
symbolic dust amount**: the agent signs it with the same x402 SDK it uses to pay,
replays the request, and the call is granted **without ever being settled** —
**once per day, per endpoint, per payer address**. The grant identity is the
wallet, not an IP and not an API key. No new protocol primitive, no signup, no
separate trial code path. Which endpoints currently offer one is published live in
[`/catalog`](https://api.invoket.com/catalog) (`metadata.trial`) — never in a
hardcoded list. This article explains the mechanics and compares them with the
other trial patterns in the x402 ecosystem.

## Why the classic free tier is an awkward fit for agents

A traditional API trial assumes a human: create an account, confirm an email,
open a dashboard, copy a key, sometimes enter a card "for verification". An
autonomous agent has none of that — it has an HTTP client and a wallet. Every
account step is a place where the loop breaks and a human has to intervene,
which is precisely the friction pay-per-call was designed to remove (see
[Why an API key does not work for an autonomous agent](/blog/why-agents-pay-per-call-instead-of-api-keys)).

What an agent actually needs from a trial is narrow: **one real
request-and-response on the production path**, cheap enough to burn on
evaluation. It wants to confirm that the endpoint answers the question it has,
in the shape it expects, before committing a budget to it. Anything beyond that
— quotas dashboards, trial keys, welcome emails — is human furniture.

## The mechanics: one more entry in `accepts`

The [x402 specification](https://github.com/coinbase/x402/blob/main/specs/x402-specification-v2.md)
already contains everything a trial needs. A `402 Payment Required` response
carries an `accepts` array with **one entry per rail** the server will take —
each entry a self-describing offer with a `scheme`, a `network`, an `asset`, an
atomic `amount` and a `payTo`. Multi-rail is normal: a server may offer USDC on
Base and USDC on Solana side by side, and the client picks the entry it can
settle.

A trial is simply one more entry in that array — a copy of the first paying rail,
with the amount replaced by a symbolic **dust amount**:

```json
{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<atomic amount>",
      "payTo": "<recipient>"
    },
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "<stablecoin contract>",
      "amount": "<dust amount>",
      "payTo": "<recipient>"
    }
  ]
}
```

Every value above is a placeholder on purpose — the real asset, amounts and
recipient are served live by the gateway and read from
[`/catalog`](https://api.invoket.com/catalog), never copied into an article. What
matters is the *relation* between the two entries: the trial amount sits orders of
magnitude below the cheapest price on the grid, far enough down that no client can
mistake it for a real one.

Because a dust-amount entry is an ordinary `PaymentRequirements` object, **an
unmodified x402 client already knows what to do with it**: select the rail, sign
the payload locally, attach it as the payment header, replay. There is no
extension to parse, no trial token to fetch, no second SDK.

### Why dust and not zero

The original design used a literal `"0"`, and it does not survive contact with a
facilitator. The CDP facilitator's `/verify` rejects it — an undocumented minimum
amount, which we measured somewhere between 100 and 1,000 atomic units, and which
also rules out the obvious fallback of a single atomic unit. A zero-amount rail is
spec-shaped but unverifiable, so it can never reach the grant.

Dust is the workable substitute: above the facilitator's floor, an order of
magnitude below the lowest real price, and — this is the part that makes it
free — **never submitted for settlement**. The amount exists to make the
requirement verifiable, not to be charged.

## The trial loop *is* the production loop

Run end to end against an Invoket endpoint that offers a trial, the loop looks
like this:

1. **Discover** the endpoint in [`/catalog`](https://api.invoket.com/catalog)
   and check `metadata.trial` to see whether a trial is currently offered.
2. **Probe** — send the bare request. Probing is always free: an unpaid request
   only returns the `402` challenge, and no money moves.
3. **Read `accepts`** — one of the rails carries a dust amount, far below the
   published price.
4. **Sign and replay** — same wallet, same signature scheme, same header as a
   paid call.
5. **`200`** — the real response body, granted without settlement. Nothing is
   broadcast, nothing moves, and the signed authorization expires unused. There is
   no `PAYMENT-RESPONSE` header on a trial call, which is how a buyer can verify
   from the outside that it was not charged.

The grant is **one free call per day, per endpoint, per payer address**. The
identity that gets the trial is the same identity that would pay: the wallet
address that signs. That is the deliberate difference from IP- or key-based
trials — the trial call is a **full rehearsal of the paid integration**. (An IP
ceiling does exist, but only as depth: a payer address is free to generate, an IP
less so, so the gateway also caps how many trials it hands out per IP per day
across all endpoints. It gates the *offer*; the grant itself is still counted per
address.) When the agent later pays for real, nothing in its code changes; the
gateway simply offers the real price, and the same loop settles it. The
[Quickstart](/docs/quickstart) shows the probe → sign → replay code, and
[For agents](/docs/for-agents#free-trial) documents the trial surface.

## How the rest of the market does trials

Other x402 sellers have converged on three different patterns.

**Free tiers embedded in `extensions`.** [relai.fi](https://relai.fi/blog/free-tier-for-api-providers)
(March 2026) lets a provider configure per-buyer free calls at the relay: while
the quota lasts, calls return `200` directly with `X-Free-Calls-Remaining`
headers; once exhausted, the caller gets a standard `402` with the tier
described under `extensions.freeTier`. This is convenient — the first calls
need no signature at all — but the free path runs *outside* the payment loop,
and a client needs to understand the extension to explain what happened.

**One call per IP.** Some services listed in the
[awesome-x402 registry](https://github.com/xpaysh/awesome-x402) grant a trial
per IP address. An IP is a weak identity for agents: fleets share NAT and
serverless egress, so the grant is exhausted by a neighbor or multiplied by
rotation, and the trial identity has no relation to the identity that will pay.

**Trial credits behind issued keys.** Broker-style services hand out instant
API keys with trial credits, then point to paid x402 URLs when the credits run
out. It works, but it reintroduces the account and key lifecycle that
pay-per-call removed.

| Approach | Trial identity | Client change needed | Trial path = paid path |
|---|---|---|---|
| Dust-amount rail (Invoket) | Payer wallet address | None — standard x402 client | Yes — same sign-and-replay |
| `extensions` free tier | Per-buyer, tracked at the relay | Extension-aware client for full UX | No — free calls skip payment |
| Per-IP grant | IP address | None | No — unpaid direct response |
| Trial keys / credits | Issued API key | Key handling | No — key path, then x402 |

The dust-amount rail is the variant that adds **no new primitive**: it reuses
the `accepts` array, the signature and the replay exactly as the spec defines
them, and simply stops before the settle. Any agent that can pay can trial —
including agents that
have never heard of Invoket before finding an endpoint in a registry (see
[How does an agent find a paid API with no human in the loop?](/blog/machine-readable-discovery-x402-bazaar-mcp)).

## Which endpoints have a trial right now

That is authority data, and it moves — so it lives in the gateway, not here.
Read [`/catalog`](https://api.invoket.com/catalog) and check `metadata.trial`
on each resource. The catalog is the single source of truth for prices, rails
and trials alike; an article describes the mechanism, it never settles the
call. If you want to try the loop today, start from the
[Quickstart](/docs/quickstart) — the probe is free everywhere, and where a
trial is offered, the first `200` is too.

## Sources

- x402 protocol and the `accepts` / `PaymentRequirements` structure —
  [x402 specification v2 (coinbase/x402)](https://github.com/coinbase/x402/blob/main/specs/x402-specification-v2.md),
  [x402.org](https://www.x402.org/).
- Free tier embedded in `402` extensions —
  [relai.fi: Give your first users a free trial](https://relai.fi/blog/free-tier-for-api-providers)
  (March 12, 2026).
- Per-IP and credit-based trial patterns —
  [awesome-x402 registry](https://github.com/xpaysh/awesome-x402).
- Settlement evidence on the wire (`PAYMENT-RESPONSE` present only after a
  settlement attempt) —
  [Paid 200s and unbilled 4xx](/blog/paid-200s-and-unbilled-4xx-the-x402-settlement-line).
- Minimum verifiable amount on the CDP facilitator — measured against its
  `/verify` while implementing the trial path (2026); undocumented upstream.
- Invoket trial surface — [For agents](/docs/for-agents#free-trial),
  [live catalog](https://api.invoket.com/catalog).