Proving Your API Data with Signed Receipts — Beyond Payment Verification

The new world of agent-to-agent payments

For the first time, AI agents can autonomously pay for things. The x402 protocol reuses the HTTP 402 Payment Required status code to let a client — whether human or artificial — pay per API call in USDC stablecoin, skip the API keys entirely, and never create an account.

It's genuinely clever. But there's a problem that nobody talks about until an agent starts acting on the data.

On 30 June 2026, we're at an inflection point. Large language models are getting smarter about orchestrating tasks, autonomous agents are being deployed in production, and the ability to pay for services on the fly is becoming table stakes. Yet the current payment proof — the transaction on the blockchain — only confirms one half of the deal: that money changed hands. It says nothing about whether the data you received in return is authentic or tampered with.

An agent can pay perfectly and still act on spoofed data.

The payment proof doesn't prove the data

Let's say you've built an API that charges 0.05 USDC per call. A customer's agent hits your endpoint, the x402 flow completes, USDC transfers, and the agent receives data in response. Your payment system can prove the transaction happened on chain.

But who verified that the response body actually came from you? Not the blockchain. The payment receipt is a certificate of intent, not a certificate of authenticity. An attacker with a network intercept — or even a buggy proxy between the agent and your API — can slip in modified data and the payment proof means nothing.

This is a real gap, and it gets worse at scale. If agents are chaining calls across APIs, each buying data from different providers, they need cryptographic assurance that what they paid for is what they received. Otherwise they're flying blind, staking decisions on data they can't verify.

The solution: signed receipts

The fix is to bind the payment proof to the data itself. When your API issues a response to a paying customer, you sign both the response body and the payment transaction ID with your private key. The customer gets back:

1. The data itself.
2. A receipt that proves the payment happened on chain.
3. Your cryptographic signature binding the two together.

Now the agent can verify independently: this data came from this API, this payment was real, and they match. No trust required beyond verifying your public key once at setup time.

It's not revolutionary — signed receipts are as old as RSA — but it's the missing piece that turns x402 from a payment primitive into a complete verification system.

Building it with Express

Here's how to wire this up. You'll need a keypair (Ed25519 is fine), a way to detect when a call is paid, and middleware to sign the response.

First, set up your keys and dependencies:

npm install express tweetnacl base64-js axios

Generate your keypair and store it securely (never in git):

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const keyPair = nacl.sign.keyPair();
const publicKey = base64js.fromByteArray(keyPair.publicKey);
const secretKey = base64js.fromByteArray(keyPair.secretKey);

console.log('Public Key:', publicKey);
console.log('Secret Key:', secretKey);

Next, create middleware that intercepts responses after a payment check:

const express = require('express');
const app = express();

const verifyPayment = async (req, res, next) => {
  const paymentTxId = req.headers['x-payment-tx-id'];
  
  if (!paymentTxId) {
    return res.status(402).json({
      error: 'Payment Required',
      message: 'Provide a payment transaction ID'
    });
  }
  
  // Verify the tx on chain (sketch version)
  const txValid = await verifyTransactionOnChain(paymentTxId, 'REPLACE_WITH_VAULT_REFERENCE');
  
  if (!txValid) {
    return res.status(402).json({ error: 'Invalid payment' });
  }
  
  req.paymentTxId = paymentTxId;
  next();
};

Now create a response-signing middleware:

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const secretKey = base64js.toByteArray(process.env.API_SECRET_KEY);

const signResponse = (req, res, next) => {
  const originalJson = res.json.bind(res);
  
  res.json = function(data) {
    const payload = JSON.stringify({
      data: data,
      txId: req.paymentTxId,
      timestamp: Date.now()
    });
    
    const message = Buffer.from(payload);
    const signature = nacl.sign.detached(message, secretKey);
    const signatureBase64 = base64js.fromByteArray(signature);
    
    res.setHeader('X-Signature', signatureBase64);
    res.setHeader('X-Payload-Hash', payload);
    
    return originalJson({ data, receipt: { txId: req.paymentTxId, signature: signatureBase64 } });
  };
  
  next();
};

app.use(verifyPayment);
app.use(signResponse);

Finally, add an endpoint:

app.get('/data/:id', (req, res) => {
  const result = { userId: req.params.id, balance: 42, updated: '2026-06-30' };
  res.json(result);
});

app.listen(3000, () => console.log('Listening on :3000'));

On the client side, verify the signature before acting on the data:

const nacl = require('tweetnacl');
const base64js = require('base64-js');

const publicKey = base64js.toByteArray('REPLACE_WITH_YOUR_PUBLIC_KEY');

function verifyReceipt(response) {
  const signature = base64js.toByteArray(response.headers['x-signature']);
  const payload = response.headers['x-payload-hash'];
  const message = Buffer.from(payload);
  
  const isValid = nacl.sign.detached.verify(
    message,
    signature,
    publicKey
  );
  
  if (!isValid) throw new Error('Signature verification failed');
  return response.data;
}

const response = await fetch('http://app.example.com/data/user123', {
  headers: { 'X-Payment-Tx-Id': 'USDC_TXN_ABC123' }
});

const verified = verifyReceipt(response);
console.log('Trusted data:', verified);

Why this matters in production

This pattern unlocks several things. Agents can now trustlessly buy data from APIs they've never seen before. Auditors can verify that a decision chain was based on authentic, paid-for data. And API providers get a crisp, cryptographic proof that they delivered what they promised.

It also scales. One signature covers one response. If you need proof of millions of calls, you can batch them into a Merkle tree on your provider side and issue one umbrella signature per batch. The customer verifies the batch root once and trusts everything under it.

Conclusion

The x402 protocol solved the payment side of autonomous agent APIs. Signed receipts solve the data authenticity side. Together, they make it possible for agents to reliably buy data from untrusted sources and act on it with confidence.

Merits

• Agents can verify data integrity without trusting the API provider beyond the public key.
• Payments and data are cryptographically bound — you can't forge one without the other.
• Scales from single calls to millions via Merkle trees or batch signatures.
• No new infrastructure needed — just standard cryptography and existing blockchains.
• Works with existing x402 payment flows.

Demerits

• Adds latency: every response must be signed (though acceptable for most use cases).
• Requires secure key management on the provider side — leaked secret keys invalidate trust.
• Clients must implement signature verification (not trivial for beginners).
• Doesn't prevent API providers from signing false data (trust is in the public key, not the provider's honesty).
• Adds complexity to the API contract — clients and servers must agree on payload format.

Caution

The names app.example.com, REPLACE_WITH_VAULT_REFERENCE, REPLACE_WITH_YOUR_PUBLIC_KEY, and all transaction IDs shown here are placeholders. Never hardcode secret keys, API secrets, or real credentials in your code. Always test signature verification with a local test environment before deploying to production. Store private keys in a secrets vault (HashiCorp Vault, AWS Secrets Manager, or similar), never in environment variables or source control. Proceed at your own risk and validate the implementation thoroughly in a testnet environment before accepting real payments.

Frequently asked questions

• What happens if an API provider's private key is compromised?
• Can I batch multiple API calls into a single signed receipt?
• How do I verify a signature in languages other than JavaScript?
• Do I need to sign every field in the response or just the data?
• What's the performance overhead of signing and verifying signatures?
• Can this work with APIs that charge a fixed subscription instead of per-call?
• How do agents handle signature verification failures in production?
• Is Ed25519 the only signing algorithm I should use, or are others acceptable?

Tags

#x402 #web3 #api #usdc #cryptography #agents #authentication #blockchain