Inspect an x402 endpoint
before integration.

Use the resource path, not the website.

Open Live lookup and paste the complete URL into x402 endpoint URL. A provider's homepage does not search every API on its domain.

This URL had public evidence on Sep 6, 2026. It is an example, not a recommendation.

Select a payment network, then “Inspect evidence.”

Base, BSC, 0G and Robinhood Chain filter mainnet options in the saved challenge; All networks adds testnets and others. Lookup never calls the provider, and a selection cannot change what it accepts or prove settlement.

Read each dimension on its own.

Ownership

Has origin control been verified? An observed card can still be unverified.

Protocol

Did the unpaid response pass x402 v2 checks? This is not a test of the paid result.

Freshness

When was it observed, and is it still within the monitoring window?

Availability

Read the sample count and window. Missing measurements are not a pass.

Install the preflight SDK.

Use Node 20+ or a modern browser. No IFF API key needed.

Pass the checked fetch into your payment client.

The wrapper inspects a 402 before your payment library acts. It holds no wallet key and makes no payment.

import { wrapFetch } from "@ifandonlyif/x402-preflight";

const preflightFetch = wrapFetch(fetch, {
  onDiverged: "throw",
  onStale: "strict",
  onUnobserved: "warn",
});

// Pass preflightFetch as your payment client's fetch.
// Creating this function alone makes no request.

Not a complete checkout. Alternatives: verify(), the HTTP API, or the MCP command.

Decide how your application handles uncertainty.

consistent

The comparison matches. Your payment policy still decides whether to proceed.

diverged

The requirement differs. The example throws before payment logic proceeds.

stale

The observation is old. strict throws on a stale mismatch, but only warns on a stale match.

unobserved

No comparable observation. The example warns; it does not block automatically.

Sign the server's login challenge.

Follow wallet authentication: request a challenge, sign its exact message, submit the signature for access and refresh tokens. Keep tokens private; never send IFF a private key.

Register the exact endpoint URL.

Call POST /api/v3/endpoints with your access token. Save the returned claim_attempt_id and ownership document. Registration starts a claim; it does not grant owner access.

Use public HTTPS on port 443, without credentials, query strings, fragments or redirects.

Publish the ownership file and queue verification.

Serve the returned ownership.document at its exact ownership.verification_url, normally /.well-known/iff-trust.json on the same origin. The challenge expires after 24 hours.

For several endpoints on one origin, keep existing claims and append the new one in the documented claims format.

Call POST /api/v3/endpoints/:id/verify-ownership. A 202 means queued, not verified; check GET /api/v3/endpoints for the outcome.

Wait for monitoring evidence, then add notifications.

Owner access and public evidence are separate. Verified-tier publication needs ownership plus at least three passing observations. Keep the ownership file online for rechecks.

Once verified, configure a webhook for status or requirement changes. Save its one-time secret, check each delivery's signature and timestamp, and deduplicate retries.

Load JSON, not a URL.

Paste the receipt envelope or full API response, or load a JSON file. For an endpoint URL, use Live lookup. Parsing and signature checks run in your browser; issuer recognition may fetch IFF's public key directory.

No receipt? Ask the developer for an IFF response with service_receipt; they can request one via the optional direct-API integration. Ordinary responses do not include it.

Separate a valid signature from a trusted issuer.

A valid signature means the embedded key signed the subject; a directory match can recognize a key. For independent pinning, supply the exact expected issuer and a full sha256: key fingerprint from a separate trusted channel, not from the receipt you are checking.

Read the signed subject, time window, and binding.

Check that the signed URL and result are what you expected. A valid historical signature can belong to an expired receipt. A standalone receipt cannot establish that a surrounding response matches the signed subject.

A receipt signature alone does not verify the referenced observation, log inclusion or chain anchor.