How to pay

Every job here is one HTTP POST. Send it without payment and the reply is 402 Payment Required carrying the exact terms; send it again with proof of payment and the reply is your result. There is no account, no API key, no signup and no minimum spend.

Two rails are accepted, and they settle differently. Rail A is a plain USDC transfer from any wallet, proved afterwards with the transaction hash — nothing to sign, nothing to implement. Rail B is x402: a signed EIP-712 authorization in a header, verified offline, no transaction needed up front. If you are a person, use Rail A. If you are an agent, use Rail B.

What is for sale

Prices are integer US cents converted to USDC base units at 6 decimals. Both numbers are in the agent card, so a machine never has to do the conversion. Your request body is checked BEFORE payment, so a malformed request costs nothing — you get 400 and can fix it and retry with the same funds.

The facts every payment needs

Send the token at that exact contract address on that exact chain. USDC on any other chain, bridged USDC, or a different token will not be seen, and there is no way to return it.

Rail A — pay from any wallet, then quote the transaction

This is the low-barrier path: any wallet that can send USDC on base can buy. You pay the network fee for your own transfer and nothing else, and the payment settles the moment we see the receipt — there is no authorization to expire.

1. Send the USDC

Send at least the offer's price in USDC (0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) on eip155:8453 to 0x3c5BbDEf29f7B6bc5973c77f90c5A3f02D829Eee. Any wallet will do. Amounts, if you prefer to paste them:

2. Wait for the transaction to confirm

We read the receipt from a base node. A transaction the node does not know yet — still pending, or sent on another chain — comes back as RPC_ERROR, because the node reports an unknown transaction as an error rather than as an empty receipt. Wait a few seconds and try again; a refused attempt consumes nothing.

3. POST the job with the transaction hash

curl -X POST https://short.desknav.ai/jobs/summarize \
  -H 'Content-Type: application/json' \
  -H 'X-Payment-Tx: 0x<transaction-hash>' \
  -d '{"text": "Paste the document to summarize here."}'

A successful reply looks like this:

{
  "invoiceId": "inv_<ulid>",
  "offerId": "summarize",
  "status": "settled",
  "rail": "direct",
  "txHash": "0x<transaction-hash>",
  "output": {
    "offerId": "summarize",
    "result": "The summary text.",
    "model": "<the model that ran it>",
    "inputThreatLevel": "low"
  }
}

• One transaction buys one job. The hash is the claim key, so a second attempt with the same hash comes back REPLAYED_TX (or 409 REPLAYED if two attempts race for it — the claim is atomic). Claim your transfer promptly.
• Split payments are summed. Every USDC transfer to the pay-to address inside one transaction counts toward the price.
• Overpayment is not refunded and does not carry over. Send the price.
• Your transfer never expires. A confirmed transaction can be claimed whenever you get to it.
• If you send both headers, X-Payment wins and X-Payment-Tx is ignored.

When Rail A refuses

The reply is 402 with {"error":"PAYMENT_REJECTED","reason":"<code>"}. The code says exactly what to do:

Rail B — x402, for agents and developers

You sign an EIP-712 USDC TransferWithAuthorization and put it in a header. We verify it offline and do the work immediately; we redeem it on chain afterwards and pay that gas ourselves. No transaction, no approval and no gas is needed from you at request time — but the USDC must still be in your wallet when we redeem.

1. Ask, and read the 402

curl -i -X POST https://short.desknav.ai/jobs/summarize \
  -H 'Content-Type: application/json' \
  -d '{"text": "Paste the document to summarize here."}'

The reply is 402. Its body carries the terms, and the same document is repeated as raw JSON in the X-Payment-Required response header:

{
  "error": "PAYMENT_REQUIRED",
  "x402Version": 1,
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "100000",
      "payToAddress": "0x3c5BbDEf29f7B6bc5973c77f90c5A3f02D829Eee",
      "usdcAddress": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "requiredDeadlineSeconds": 1800,
      "resource": "https://short.desknav.ai/jobs/summarize"
    }
  ],
  "offerId": "summarize",
  "priceCents": 10
}

Read every value out of accepts rather than hardcoding it. maxAmountRequired is in USDC base units, not cents and not whole tokens.

2. Sign against this exact domain

The domain is the token's own, not ours. Getting one character of it wrong produces a signature that recovers to a different address, which comes back as BAD_SIGNATURE.

{
  "name": "USD Coin",
  "version": "2",
  "chainId": 8453,
  "verifyingContract": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
}

That domain hashes to 0x02fa7265e7c5d81118673727957699e4d68f74cd74b7db77da710fe8a2c7834f. It is the same value the token returns from DOMAIN_SEPARATOR() on chain — compare yours before you spend a signature on it.

The type, which must be encoded in exactly this field order:

{
  "TransferWithAuthorization": [
    { "name": "from",        "type": "address" },
    { "name": "to",          "type": "address" },
    { "name": "value",       "type": "uint256" },
    { "name": "validAfter",  "type": "uint256" },
    { "name": "validBefore", "type": "uint256" },
    { "name": "nonce",       "type": "bytes32" }
  ]
}

3. The deadline rule

Settlement is asynchronous: we redeem your authorization in a later sweep, so an authorization that closes before that sweep is worth nothing to us and we will not do work for it. The 402 asks for 1800s (requiredDeadlineSeconds). By the time your request arrives, at least 1680s of that window must still be left, or the reply is DEADLINE_TOO_SOON — the difference is arrival grace for the round trip and clock skew, not spare room to sign a shorter window.

• Sign validBefore = now + 1800 and you are always inside the rule.
• Signing a short window to limit exposure does not work here: below 1680s remaining it is refused outright, before any work happens.
• Keep the balance in your wallet until the transfer lands. If the balance is gone at redemption, the on-chain transfer fails and the work has already been delivered.

4. Send the envelope

The X-Payment header carries this JSON, either raw or base64-encoded — both are accepted. Base64 is safer in a header: a raw JSON envelope with a non-ASCII character in it cannot be sent.

{
  "x402Version": 1,
  "scheme": "exact",
  "network": "base",
  "payload": {
    "signature": "0x<65-byte-signature>",
    "authorization": {
      "from": "0x<your-wallet>",
      "to": "0x3c5BbDEf29f7B6bc5973c77f90c5A3f02D829Eee",
      "value": "100000",
      "validAfter": "<unix-seconds>",
      "validBefore": "<unix-seconds>",
      "nonce": "0x<32-random-bytes>"
    }
  }
}

• Every numeric field is a decimal string, not a JSON number. A number would already have lost precision.
• Do not add asset, token or chainId keys that disagree with the terms above: a contradicting asset is WRONG_ASSET and a contradicting chain is UNSUPPORTED_NETWORK, even though neither can change what you signed.
• network may be base or eip155:8453; both normalize to the same chain.

As one command:

curl -X POST https://short.desknav.ai/jobs/summarize \
  -H 'Content-Type: application/json' \
  -H 'X-Payment: {"x402Version":1,"scheme":"exact","network":"base","payload":{"signature":"0x<65-byte-signature>","authorization":{"from":"0x<your-wallet>","to":"0x3c5BbDEf29f7B6bc5973c77f90c5A3f02D829Eee","value":"100000","validAfter":"<unix-seconds>","validBefore":"<unix-seconds>","nonce":"0x<32-random-bytes>"}}}' \
  -d '{"text": "Paste the document to summarize here."}'

A successful reply is 200:

{
  "invoiceId": "inv_<ulid>",
  "offerId": "summarize",
  "status": "delivered",
  "output": {
    "offerId": "summarize",
    "result": "The summary text.",
    "model": "<the model that ran it>",
    "inputThreatLevel": "low"
  }
}

status is delivered, not settled: the work is done and the authorization is ours to redeem. Rail A returns settled instead, because the money had already moved before the request.

5. A working client, in viem

Node 20+ and npm i viem. This is the whole protocol: probe, sign what the 402 asked for, replay.

import { privateKeyToAccount } from "viem/accounts";

const ENDPOINT = "https://short.desknav.ai/jobs/summarize";
const BODY = {"text": "Paste the document to summarize here."};

const account = privateKeyToAccount(process.env.PRIVATE_KEY as `0x${string}`);
const headers = { "Content-Type": "application/json" };
const body = JSON.stringify(BODY);

// 1. Probe. The 402 body carries the terms; never hardcode them.
const probe = await fetch(ENDPOINT, { method: "POST", headers, body });
if (probe.status !== 402) throw new Error(`expected 402, got ${probe.status}`);
const { accepts } = await probe.json();
const terms = accepts.find((a: any) => a.scheme === "exact");
if (!terms) throw new Error("no acceptable payment scheme");

// 2. Sign a TransferWithAuthorization for exactly those terms.
const now = Math.floor(Date.now() / 1000);
const validAfter = now - 60;
const validBefore = now + terms.requiredDeadlineSeconds;
const nonce = ("0x" + Buffer.from(crypto.getRandomValues(new Uint8Array(32))).toString("hex")) as `0x${string}`;

const signature = await account.signTypedData({
  domain: {
    name: "USD Coin",
    version: "2",
    chainId: 8453,
    verifyingContract: terms.usdcAddress,
  },
  types: {
    TransferWithAuthorization: [
      { name: "from", type: "address" },
      { name: "to", type: "address" },
      { name: "value", type: "uint256" },
      { name: "validAfter", type: "uint256" },
      { name: "validBefore", type: "uint256" },
      { name: "nonce", type: "bytes32" },
    ],
  },
  primaryType: "TransferWithAuthorization",
  message: {
    from: account.address,
    to: terms.payToAddress,
    value: BigInt(terms.maxAmountRequired),   // BigInt here...
    validAfter: BigInt(validAfter),
    validBefore: BigInt(validBefore),
    nonce,
  },
});

// 3. Replay the identical request with the envelope attached.
const envelope = {
  x402Version: 1,
  scheme: terms.scheme,
  network: terms.network,
  payload: {
    signature,
    authorization: {
      from: account.address,
      to: terms.payToAddress,
      value: terms.maxAmountRequired,          // ...decimal STRINGS on the wire.
      validAfter: String(validAfter),
      validBefore: String(validBefore),
      nonce,
    },
  },
};

const paid = await fetch(ENDPOINT, {
  method: "POST",
  headers: {
    ...headers,
    "X-Payment": Buffer.from(JSON.stringify(envelope)).toString("base64"),
  },
  body,
});
console.log(paid.status, await paid.json());

When Rail B refuses

The reply is 402 with {"error":"PAYMENT_REJECTED","code":"<code>"} and the terms again in accepts, so a conforming client can correct itself and retry. Note the field is code on this rail and reason on Rail A.

Every other way a request can fail

Reading all of this as a machine

• https://short.desknav.ai/.well-known/agent-card.json — every offer, both prices, both rails, the pay-to address and the chain, in one document.
• https://short.desknav.ai/offers — the live catalog, ids and prices only.
• GET https://short.desknav.ai/jobs/<offer-id> — one offer's terms, including the accepts array, without having to trigger a 402.
• https://short.desknav.ai/docs.md — this page as Markdown.
• GET https://short.desknav.ai/health — liveness. It says nothing about wallets or balances.