Provider Hub

Why Verify Your Endpoints

Unverified endpoints exist in our database because our agents discovered them while crawling the x402 ecosystem. They get tested, but agents treat them with less confidence. Verified endpoints, on the other hand, show up first in directory results, carry a trust badge, and include richer metadata like uptime history and response validation scores.

The difference matters when agents decide where to spend money. Given two endpoints that do the same thing, agents will pick the verified one every time. Verification is also how you unlock features like automatic refunds, failure notifications, and per-endpoint configuration. It costs nothing to verify. You just deploy the SDK, and the act of deploying it proves you control the endpoint.

The SDK

The @zauthx402/sdk is a lightweight Express middleware that sits in front of your x402 payment layer. It observes HTTP traffic without touching your payment flow. Requests come in, the SDK logs headers and bodies, your x402 middleware handles payment validation as usual, your route runs, and the SDK captures the response on the way out. All of that telemetry gets reported back to zauth asynchronously, so there's no added latency to your responses.

It works with any x402 implementation. Coinbase's @x402 packages, custom setups, whatever you're running. The SDK doesn't care about your payment logic. It just watches traffic and reports what it sees. It parses both V1 and V2 x402 payment headers, supports EVM and Solana networks, and validates response quality so you can catch issues before your users do.

import { zauthProvider } from '@zauthx402/sdk/middleware'

// Add BEFORE your x402 middleware
app.use(zauthProvider('your-api-key'))

// Your existing x402 setup continues unchanged
app.use(x402Middleware(...))
app.get('/api/paid', ...)

You grab your API key from the Provider Hub after connecting your wallet. One line of middleware, and every x402 request flowing through your server starts showing up in your dashboard with full telemetry: request params, response bodies, timing data, payment details, and validation results.

AI / LLM Setup

Using an AI coding assistant like Claude, Cursor, or Copilot? Hand it the self-contained instructions below and it can wire up the Provider Hub SDK for you in one pass. Everything it needs — the package name, the exact middleware placement, and where the API key comes from — is in a single block, with no back-and-forth required.

Integrate the zauth Provider Hub SDK into this Express app.

1. Install: npm install @zauthx402/sdk
2. Import the middleware:
   import { zauthProvider } from '@zauthx402/sdk/middleware'
3. Register it BEFORE the existing x402 payment middleware so it can
   observe traffic without altering payment logic:
   app.use(zauthProvider(process.env.ZAUTH_API_KEY))
4. Leave all existing x402 middleware and routes unchanged.
5. Read the API key from the ZAUTH_API_KEY environment variable. Do not
   hard-code it. The key is generated at https://zauth.inc/provider-hub
   after connecting a wallet (SDK panel -> Generate API key).

Constraints: the SDK is observe-only and must not modify request/response
bodies or payment validation. Telemetry is reported asynchronously, so add
no awaits on the response path.

Prefer a machine-readable map of the whole platform? zauth publishes an llms.txt file (the llmstxt.org standard) that points agents at every product and doc page. The only value the assistant cannot generate for you is the API key — grab it from the Provider Hub once and drop it into your environment.

Dashboard

Once your SDK is reporting data, the Provider Hub becomes your operations center. You get a live view of every endpoint the SDK has detected, grouped by domain. Each endpoint shows its current status (working, failing, flaky), success rate over time, average response times, and the price agents are paying per call.

Our agents periodically re-test your endpoints to keep uptime data fresh, and those results feed directly into the dashboard. If an endpoint starts failing, you get notified by email so you can fix it before agents start routing around your service. The hub also shows your full refund history, so you can see exactly which calls triggered refunds and why.

Automatic Refunds

Things break. Servers go down, APIs return garbage, timeouts happen. When an agent pays for your endpoint and gets a bad response, that's a terrible experience. The SDK includes built-in response validation that checks whether what you returned actually makes sense. If a response comes back empty, malformed, or as a server error after payment was accepted, the SDK can automatically refund the caller from your own hot wallet.

You supply your EVM and/or Solana private keys to the SDK, and it handles refund execution on-chain. The SDK detects which network the original payment came in on and routes the refund accordingly. You set safety limits per refund, per day, and per month so you stay in control of how much goes out. You can also configure refund behavior per endpoint: strict validation for some routes, lenient for others, or disable refunds entirely on endpoints where you don't want them. Providers with good refund policies naturally attract more agent traffic because agents know they won't burn money on failed calls.

Getting Started