Skip to main content
Use the HTTP API from servers, workers, CLIs, and MCP—not from end-user browsers. Responses return the same trust receipt ID (qHash) as the SDK. For product checkout, publish a gate and pass its gateId; NEUS resolves the check policy, billing, and checkout server-side. Base URL: https://api.neus.network

​
Browsers

Send end users through the JavaScript SDK or Hosted Verify. If a web client needs behavior outside those surfaces, your backend should call NEUS so secrets stay off the client and CORS stays predictable.

​
Reads vs writes

​
Endpoints

The SDK’s getGate() / fulfillGate() wrap the gate endpoints above.
Scope note: This reference covers the core HTTP proof and verification surface. Gate endpoints (/api/v1/profile/gates/{gateId}, .../fulfill, /api/v1/profile/gates/discoverable) and POST /api/v1/payments/verify (x402 pay-per-call settlement) are product checkout endpoints documented in Hosted Gate Checkout and x402. Three resources support x402 pay-per-call: GET /api/v1/proofs/check, POST /api/v1/verification, and POST /api/v1/verification/access/grant.
Same-origin in the product app: https://neus.network/api/v1/gates/{gateId} and .../fulfill return the same gate contract for browser calls. Server integrations should call api.neus.network paths directly (or use the SDK).

​
Examples

By wallet
Paged responses include proofs, totalCount, hasMore, and continuation fields:
  • nextCursor — preferred for owner vaults and large histories (keyset paging).
  • nextOffset — used when the merged vault is multi-wallet or cursor is unavailable.
Pass cursor (not offset) on the next request when nextCursor is present:
Public and unlisted proofs: often callable without auth. Private proofs: only with allowed access (Authentication). Check
When gateId is set, the response includes a per-requirement data.gate block — gate.allRequiredSatisfied === true is the readiness signal for checkout, and gate.reusedVerifierProofs feeds options.reusedVerifierProofs on submit. Full lifecycle: Hosted Gate Checkout. Direct verifierIds checks are for advanced protocol tooling. Product access checks should use gateId. Create a proof (raw HTTP, advanced) Most products use the SDK or https://neus.network/verify. Raw HTTP is a fixed two-phase flow:
  1. Build the final JSON body.
  2. POST /api/v1/verification/standardize with that body.
  3. Sign the returned signerString.
  4. POST /api/v1/verification with the same body plus signature.
If step 4 rejects the signature, repeat step 2 on the same payload and compare signerString before retrying step 4. Catalog

​
Auth

  • Reads: public and unlisted proofs are often open; private proofs require permitted access.
  • Writes: follow Authentication (signature, session, or app-attributed rules).

​
Next

Get started

Account, app, billing.

Authentication

Keys, delegation, signing.

Errors

HTTP error codes.
Last modified on July 23, 2026