Payments

RobotDomainSearch premium endpoints accept micropayments via two protocols: x402 and MPP. Both use the HTTP 402 Payment Required challenge-response pattern. Same pricing, two independent payment rails — your agent picks whichever it supports.

No API key. No subscription. No registration. Just pay per request.

Endpoint Price
/v1/valuation/{domain} (quick) $0.02
/v1/valuation/{domain} (full) $0.08
/v1/name-search-presence $0.02
/v1/intel $0.05

The Dual Challenge

When you request a paid endpoint without payment credentials, the server returns 402 Payment Required with challenges for both protocols simultaneously:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="abc123...", realm="robotdomainsearch.com",
  method="tempo", intent="charge", request="eyJhbW91bnQiOiIyMDAwMCI..."
X-PAYMENT-REQUIREMENTS: eyJwcmljZSI6IjAuMDIiLCJjdXJyZW5jeSI6IlVTREMi...
Cache-Control: no-store
  • WWW-Authenticate: Payment ... → MPP challenge (Tempo)
  • X-PAYMENT-REQUIREMENTS: ... → x402 challenge (Base)

Your agent reads whichever header it understands and pays via that protocol. Same price either way.

Option 1: x402 (USDC on Base)

Settlement on Base (chain ID 8453) using USDC.

Flow

  1. Request — Call a paid endpoint without payment headers
  2. 402 Response — Server returns X-PAYMENT-REQUIREMENTS with amount, recipient, and network
  3. Sign payment — Client signs a USDC payment on Base (handled by x402 SDK)
  4. Retry — Client re-sends the request with X-PAYMENT header containing the signed payment
  5. 200 OK — Server verifies payment and returns data

Code Examples

Use the Coinbase x402 client SDK to handle payment automatically:

JavaScript (x402-axios)

import { paymentMiddleware } from "x402-axios";
import axios from "axios";

const client = axios.create();
client.use(paymentMiddleware("YOUR_WALLET_PRIVATE_KEY"));

// Payment is handled automatically on 402
const response = await client.get(
  "https://api.robotdomainsearch.com/v1/valuation/example.com?tier=full"
);
console.log(response.data);

Python (x402-python)

from x402_python import x402_requests

session = x402_requests.Session(
    wallet_private_key="YOUR_WALLET_PRIVATE_KEY"
)

response = session.get(
    "https://api.robotdomainsearch.com/v1/valuation/example.com",
    params={"tier": "full"}
)
print(response.json())

Go (x402-go)

import "github.com/coinbase/x402-go"

client := x402.NewClient("YOUR_WALLET_PRIVATE_KEY")

resp, err := client.Get(
    "https://api.robotdomainsearch.com/v1/valuation/example.com?tier=full",
)

Resources

Option 2: MPP (USDC.e on Tempo)

Settlement on Tempo (chain ID 4217) using USDC.e (bridged USDC, TIP-20 token).

MPP uses standard HTTP Authentication (WWW-Authenticate / Authorization) — the same mechanism as Basic and Bearer auth. It’s formally specified as the “Payment” HTTP Authentication Scheme in draft-ryan-httpauth-payment.

Flow

Step 1: Get the challenge

Request a paid endpoint without credentials:

curl -i https://api.robotdomainsearch.com/v1/valuation/example.com

The server responds with 402 Payment Required and a WWW-Authenticate header:

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="abc123...", realm="robotdomainsearch.com",
  method="tempo", intent="charge", request="eyJhbW91bnQiOiIyMDAwMCI..."

Step 2: Decode the challenge

Base64url-decode the request parameter to get the payment details:

{
  "amount": "20000",
  "currency": "0x20c0000000000000...b9537d11c60e8b50",
  "recipient": "0xYourRecipientAddress",
  "methodDetails": {
    "chainId": 4217
  }
}
  • amount — In the token’s smallest unit (6 decimals). 20000 = $0.02.
  • currency — The USDC.e contract address on Tempo.
  • recipient — The address to pay.
  • chainId — 4217 (Tempo mainnet).

Step 3: Create payment on Tempo

Transfer USDC.e (TIP-20 token, equivalent to ERC-20) on the Tempo blockchain for the specified amount to the specified recipient. Tempo is EVM-compatible — the same ethclient, Transfer events, and address format work as on Ethereum or Base.

Step 4: Build and send credential

Retry the original request with an Authorization: Payment header containing a base64url-encoded credential:

curl -i https://api.robotdomainsearch.com/v1/valuation/example.com \
  -H "Authorization: Payment eyJjaGFsbGVuZ2UiOnsiaWQiOiJhYmMxMjMuLi4i..."

The decoded credential JSON contains the echoed challenge plus payment proof:

{
  "challenge": {
    "id": "abc123...",
    "realm": "robotdomainsearch.com",
    "method": "tempo",
    "intent": "charge",
    "request": "eyJhbW91bnQiOiIyMDAwMCI..."
  },
  "payload": {
    "type": "hash",
    "hash": "0x7a3f..."
  }
}

Step 5: Receive data + receipt

The server verifies the HMAC-bound challenge ID and the on-chain payment, then returns your data with a Payment-Receipt header:

HTTP/1.1 200 OK
Payment-Receipt: eyJtZXRob2QiOiJ0ZW1wbyIsInN0YXR1cyI6InN1Y2Nlc3Mi...
Content-Type: application/json

{
  "domain": "example.com",
  "estimate": { "low": 5000, "mid": 12000, "high": 25000 },
  ...
}

Key Details

  • Token: USDC.e — bridged USDC, TIP-20 standard (equivalent to ERC-20), 6 decimals
  • Chain: Tempo — chain ID 4217, EVM-compatible
  • Challenge binding: HMAC-SHA256 — stateless, tamper-proof. The challenge ID is a cryptographic proof of its contents; no server-side session storage needed.
  • Payment modes: Push (client broadcasts tx, sends hash) or Pull (client signs tx, server broadcasts)
  • Errors: RFC 9457 Problem Details format (see Error Handling below)

Resources

Comparison: x402 vs MPP

Feature x402 MPP
Settlement chain Base (chain ID 8453) Tempo (chain ID 4217)
Token USDC USDC.e (bridged USDC)
HTTP mechanism Custom headers (X-PAYMENT-REQUIREMENTS / X-PAYMENT) Standard HTTP Auth (WWW-Authenticate / Authorization)
Challenge binding Implicit (per route) HMAC-bound challenge IDs
Error format JSON response body RFC 9457 Problem Details
Spec x402.org IETF draft
Ecosystem Coinbase / Base Tempo

Error Handling

Both protocols return 402 Payment Required for payment issues.

MPP errors follow RFC 9457 Problem Details format:

{
  "type": "https://paymentauth.org/problems/payment-expired",
  "title": "Payment Expired",
  "status": 402,
  "detail": "Challenge has expired."
}

MPP Error Types

Error Type Meaning
payment-required No credential provided
payment-insufficient Amount too low
payment-expired Challenge expired
verification-failed On-chain verification failed
invalid-challenge HMAC verification failed (tampering detected)
malformed-credential Could not decode credential

Every MPP error response also includes a fresh WWW-Authenticate challenge header, so the client can immediately retry without making a separate request — one round-trip instead of two on recoverable errors.

Payment Receipt

Successful MPP payments return a Payment-Receipt header confirming the transaction:

Payment-Receipt: eyJtZXRob2QiOiJ0ZW1wbyIsInJlZmVyZW5jZSI6IjB4...

Base64url-decoded:

{
  "method": "tempo",
  "reference": "0x7a3f...",
  "status": "success"
}

This provides a cryptographic proof that the exchange happened — useful for audit trails and dispute resolution.