STAGINGThis is a preview of nitrograph.com. Actions here hit the production API.
Docs / the trusted interface for every API

Concepts

Five primitives. Everything else is composition.

Service

A service is any paid API that an agent can transact with on one of Nitrograph's rails. Each service has a stable slug, a primary rail it settles on (plus the full set of rails it supports), a cost contract, and a canonical integration surface.

Services are ingested continuously from:

  • the x402 Bazaar (Coinbase CDP)
  • the MPP directory (mpp.dev/api/services)
  • per-rail crawlers as they ship
  • manual curation for high-signal services

Today there are 11,000+ ranked services in the catalog — a long tail of x402 endpoints plus a curated set of MPP services. Ugly auto-generated slugs are normal for x402; clean names are normal for MPP. Both are indexed identically, and structural quality signals keep auto-generated spam from outranking real services.

Service map

The service map is what makes Nitrograph more than a directory. For every service in the catalog we run a probe fleet, structured tests against the real endpoint, and publish what we find.

A service map has three shapes:

  • Gotchas: version drift, schema quirks, undocumented caps, param combinations that silently return empty, auth edge cases
  • Patterns: step sequences that reliably achieve a common intent (e.g. "build list of N decision-makers at size-range companies")
  • Cost + auth contracts: the rail, the per-call or per-session cost, and the paywall shape your agent has to handle

Your direct traffic is never in the graph. The map comes from our probes and from generalized outcome reports, not from watching you.

Rail

A rail is a payment protocol the catalog understands end-to-end. Live today:

  • x402: native HTTP stablecoin payments, pay-per-call, receipts on-chain. USDC on Base, Polygon, and Solana.
  • MPP: Machine Payments Protocol. Session-based streaming payments on Tempo, co-designed by Stripe and Tempo.

Coming in phase 2:

  • TAP: Trusted Agent Protocol, identity-bound agent transactions
  • A2A: agent-to-agent settlement

A service declares a primary display rail; the catalog also tracks the full set of rails a service supports, and filters match against that set. See Payment rails for details.

Invocation

A managed invocation is Nitrograph running the call instead of your agent: quote → hold → pay upstream → validate → settle or refund. You authorize a quoted price; Nitrograph pays the provider over x402 from its treasury, a versioned validation ruleset checks the work, and your prepaid credits are charged only on a validated pass. Refunds are automatic on failure. Retries are idempotent. Every settled outcome feeds the trust graph that ranks future searches.

Credits are an append-only micro-USD ledger — top-ups via Stripe, statements exportable, every settlement backed by a signed receipt. Full detail at Invoke & credits.

Receipt

Every settlement and refund writes a signed receipt: a content-addressed, Ed25519-signed JWS object (nitrograph.receipt.v1) recording payer, payee, subject, outcome, amount, and the validation ruleset version. Receipts make the marketplace auditable — your statement is provable, not just displayed — and are designed to anchor to the Nitrograph network once its receipt layer certifies.

One derived structure sits on top of these primitives: certification (benchmarked, human-reviewed supplier tier; the routing pool for intent-based invocation). Rank itself lives in discover, computed per task from settled, validated outcomes - price is displayed, never ranked.