> ## Documentation Index
> Fetch the complete documentation index at: https://docs.proofable.me/llms.txt
> Use this file to discover all available pages before exploring further.

# API

> HTTP endpoints for backends, workers, and CLIs, with the same proof IDs as the SDK and credentials that never reach the browser.

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`](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](../sdks/javascript)** or **[Hosted Verify](../verification/hosted)**. 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](./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](../gates/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](../gates/checkout) and [Pay per call](../gates/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**

```bash theme={"system"}
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:

```bash theme={"system"}
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](./authentication)).

**Check inline requirements**

```bash theme={"system"}
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](../gates/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:

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**

```bash theme={"system"}
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](./authentication) (signature, session, or app-attributed rules).

## Next

<CardGroup cols={2}>
  <Card title="Start here" icon="book" href="/">
    Choose an agent, app, or SDK path.
  </Card>

  <Card title="Authentication" icon="key" href="./authentication">
    Keys, delegation, signing.
  </Card>

  <Card title="Errors" icon="triangle-exclamation" href="./errors">
    HTTP error codes.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.