API

Send requirements straight to the proof check endpoint. Publish a listing only when you need managed checkout, pricing, or fulfillment. Proof IDs match the SDK (qHash in responses). Base URL: https://api.proofable.me OpenAPI: https://api.proofable.me/openapi.json Public HTTP is versioned on the path as /api/v1. Breaking changes ship as a new path version. The current public surface stays /api/v1. Deprecations are announced in the changelog. Retired paths will send Deprecation and Sunset headers.

Browsers

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

Reads vs writes

Operation	Typical use
GET (below)	Eligibility and proof reads
POST `/api/v1/verification`	Create a proof (Authentication); prefer the SDK or Hosted Verify unless you need raw HTTP

Endpoints

Path	Method	Purpose
`/api/v1/proofs/check`	POST	Evaluate inline requirements without publishing them
`/api/v1/proofs/check`	GET	Compatibility checks by verifier or persisted `gateId`
`/api/v1/profile/gates/{gateId}`	GET	Public gate snapshot (requirements, price, schedule)
`/api/v1/profile/gates/{gateId}/fulfill`	POST	Deliver gate reward after verify (+ payment). See Gate checkout
`/api/v1/profile/gates/discoverable`	GET	List public, discoverable gates
`/api/v1/proofs/by-wallet/{address}`	GET	List by wallet
`/api/v1/proofs/{qHash}`	GET	Fetch by `qHash`
`/api/v1/proofs/revoke-self/{qHash}`	POST	Owner revokes their own proof
`/api/v1/verification`	POST	Create proof (server)
`/api/v1/verification/access/grant`	POST	Create a signed private-proof sharing capability
`/api/v1/verification/standardize`	POST	Phase 1 of raw HTTP: returns `signerString` for the exact body you will submit
`/api/v1/verification/verifiers`	GET	Verifier catalog
`/api/v1/health`	GET	Service health

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 Gate checkout and Pay per call. Two resources support x402 pay-per-call: POST /api/v1/verification and POST /api/v1/verification/access/grant. Checking an existing proof is free. MCP connect stays OAuth.

Same-origin in the product app: https://proofable.me/api/v1/gates/{gateId} and .../fulfill return the same gate contract for browser calls. Server integrations should call api.proofable.me paths directly (or use the SDK).

Examples

By wallet

curl "https://api.proofable.me/api/v1/proofs/by-wallet/0x...?limit=50"

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:

curl "https://api.proofable.me/api/v1/proofs/by-wallet/0x...?limit=1000&cursor=<nextCursor>"

Public and unlisted proofs: often callable without auth. Private proofs: only with allowed access (Authentication). Check inline requirements

curl --request POST "https://api.proofable.me/api/v1/proofs/check" \
  --header "Content-Type: application/json" \
  --data '{"subject":{"accountId":"0x..."},"requirements":[{"verifierId":"proof-of-human"}],"includeQHashes":true}'

The response uses the same data.gate evaluator as persisted checkout. In new SDK integrations, read the normalized top-level result.satisfied, result.missing, and result.proofs fields. For an optional published listing, pass its gateId with GET. Listing and checkout integrations may use data.gate.allRequiredSatisfied and data.gate.reusedVerifierProofs for fulfillment compatibility. Full lifecycle: Gate checkout. Create a proof (raw HTTP, advanced) Most products use the SDK or https://proofable.me/verify. Raw HTTP is a fixed two-phase flow:

Build the final JSON body.
POST /api/v1/verification/standardize with that body.
Sign the returned signerString.
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

curl https://api.proofable.me/api/v1/verification/verifiers

Auth

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

Start here

Choose an agent, app, or SDK path.

Authentication

Keys, delegation, signing.

Errors

HTTP error codes.

Overview

MCP

JavaScript SDK

HTTP API

Verifier catalog

Standards

Browsers

Reads vs writes

Endpoints

Examples

Auth

Next

Start here

Authentication

Errors

​Browsers

​Reads vs writes

​Endpoints

​Examples

​Auth

​Next

Start here

Authentication

Errors

Browsers

Reads vs writes

Endpoints

Examples

Auth

Next