Saxeo Services

Saxeo Services is the seller side of x402. You publish a service — a hosted agent, or an HTTPS endpoint you already run — at a public Saxeo URL. A buyer reads the terms, pays your wallet directly on-chain, and replays the call with an X-PAYMENT header. Saxeo verifies that transfer, executes or forwards the call under your own controls, and signs a metadata-only receipt.

Saxeo is the verification and execution layer here, not a payment processor.

Non-custodial, deliberately

Funds move buyer → seller. They never touch Saxeo, Saxeo takes no cut at settlement, and Saxeo never moves credits between two accounts. This is the same posture as the Payment Rail, and it is a design constraint rather than a policy: holding a buyer's money for a seller, or debiting one account's prepaid credit to fund another's, is money transmission.

That has one consequence worth stating plainly:

A buyer cannot pay for a service with a Saxeo API key or prepaid balance. Service payments are always on-chain, from the buyer's own wallet. A Saxeo key buys Saxeo's own compute (inference, sandboxes); it does not buy other people's services.

The seller's own compute still bills the seller normally: an agent-backed service runs under that agent's bounded key, budget, policy, and circuit breaker, exactly as a scheduled run would.

Publish a service

POST /v1/services (session-authed).

curl https://www.saxeonetwork.tech/__api/v1/services \
-H "Authorization: Bearer $SAXEO_SESSION_TOKEN" \
-H "Content-Type: application/json" \
-d '{
  "slug": "summarize-pdf",
  "name": "Summarize a PDF",
  "description": "Returns a three-line summary.",
  "kind": "agent",
  "agent_id": "agt_…",
  "price_usd": 0.25,
  "payee_chain_id": 42161,
  "payee_address": "0xYourLinkedWallet…",
  "listed": true
}'

Manage them with GET /v1/services, PATCH /v1/services/manage/:slug (price, description, listed, enabled), DELETE /v1/services/manage/:slug, and GET /v1/services/manage/:slug/calls.

Buy a service

Three public endpoints, no credential needed:

The flow is the ordinary x402 shape, with the seller as payTo:

# 1. Ask, unpaid — you get 402 and the terms
curl -i -X POST https://www.saxeonetwork.tech/__api/v1/services/summarize-pdf/invoke \
-H 'content-type: application/json' -d '{"url":"https://…"}'

# 2. Pay the seller directly on-chain (the payTo in accepts[])

# 3. Replay with the transaction
curl -X POST https://www.saxeonetwork.tech/__api/v1/services/summarize-pdf/invoke \
-H 'content-type: application/json' \
-H 'x-payment: {"chain_id":42161,"tx_hash":"0x…"}' \
-d '{"url":"https://…"}'

On Solana the transfer must carry the service id in the transaction memo — that is how the payment is attributed, exactly as account-id memos work for USDT deposits.

An agent service receives your request body as SAXEO_INPUT and answers with {output, exit_code, receipt}. An endpoint service forwards your body verbatim and relays the seller's response, status and content type included.

What the receipt proves

Every delivered call mints a signed v:1, kind: "service" receipt in the x-sable-receipt / x-sable-receipt-sig / x-sable-receipt-signer response headers. It carries the service and call ids, the price and the amount actually paid, the chain and transaction, the payer, input_fp and output_fp (sha256 prefixes), the latency and the status. Verify it at POST /v1/receipts/verify like any other Saxeo receipt.

It proves the call was paid for and served, and binds the request and the response by hash. It does not certify that the answer was correct or useful, and Saxeo does not vouch for any seller.

Payment, once

One on-chain payment buys one delivered call. The claim is recorded before execution, so two concurrent replays of one transaction cannot both run — the second gets 409.

If delivery fails (your endpoint is unreachable or 5xx, the agent cannot run), the call is marked failed and the payment is not consumed: the buyer retries with the same transaction rather than paying twice. That is the sandbox idempotency-key lesson applied to money.

Privacy

services and service_calls have no column that could hold a request or a response. Only sha256-prefix fingerprints are stored, and only fingerprints go on the receipt — the same privacy contract as the rest of the gateway. Output is returned to the buyer once and never persisted. The seller's endpoint URL and its Authorization header value are AES-GCM-sealed at rest, opened only when Saxeo dials the endpoint.

Directory, not a marketplace

The public directory lists what sellers chose to publish, ordered by delivered calls. Saxeo does not match buyers to sellers, arbitrate disputes, hold escrow, or rank by quality. Listing is opt-in; delivered-call counts state volume, not merit.

Webhooks

Subscribe to service_called to be told when a buyer paid for and received a call. The payload carries the service, call id, price, amount paid, chain, transaction, status and latency — never the request or the response.