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

# The Proof object

> Data model and reference for verified Reclaim Protocol zkTLS proofs gating Web3 features on verified Web2 data.

zkTLS proofs — currently powered by Reclaim Protocol — let you gate Web3 features on **verified Web2 facts**: someone's real subscription status on a SaaS product, API usage limits, bank statements, or any claim Reclaim can prove. ArcenPay verifies the proof, stores it, and merges the verified claims into the company's traits so feature-flag rules can evaluate them (for example, `zktls_claim_plan = "pro"`).

## Submit & verify a proof

`POST /api/v1/proofs/zktls`

Auth: API key (`api_…`, `sk_…`, `rk_…`, `pk_…`).

<ParamField body="proof" type="object" required>
  The Reclaim Protocol proof to verify. Must include provider metadata (`providerId`) and `claimData`.
</ParamField>

<ParamField body="companyKeys" type="object">
  Company identity (`id`, `wallet`, or `email`) to attach the verified claims to. If omitted, the proof is stored without a company linkage.
</ParamField>

<ParamField body="userKeys" type="object">
  User identity, resolved within the company.
</ParamField>

<ParamField body="expiresIn" type="number">
  Proof lifetime in seconds. `0` = no expiry. Omit for no expiry.
</ParamField>

### Example

```bash theme={null}
curl -X POST https://api.arcenpay.com/api/v1/proofs/zktls \
  -H "Authorization: Bearer sk_live_xxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "proof": {
      "providerId": "http-google",
      "claimData": {
        "provider": "http",
        "parameters": { "url": "https://api.acme.com/v1/me" },
        "context": "{\"extractedParameters\":{\"plan\":\"pro\",\"quota\":\"1000\"}}",
        "extractedParameterValues": { "plan": "pro", "quota": "1000" }
      },
      "signatures": [...]
    },
    "companyKeys": { "id": "company_123" },
    "expiresIn": 0
  }'
```

### Response

```json theme={null}
{
  "data": {
    "id": "zkp_123",
    "providerId": "http-google",
    "providerName": "Reclaim Protocol",
    "claims": { "plan": "pro", "quota": "1000" },
    "verifiedAt": "2026-09-17T10:00:00.000Z",
    "expiresAt": null,
    "companyId": "cm_abc123",
    "userId": null
  }
}
```

### Side effects

On success, ArcenPay:

* Stores the verified proof with a SHA-256 `proofHash` (replay-protected — re-submitting the same proof returns `409`).
* Writes `zktls_<providerId>: true` and `zktls_claim_<key>: <value>` traits onto the linked company.
* Invalidates the feature-flag cache so trait-based rules re-evaluate immediately.

### Errors

| Status | Meaning                                                                   |
| ------ | ------------------------------------------------------------------------- |
| `422`  | Proof missing provider metadata, or verification failed                   |
| `503`  | Reclaim verifier not installed in the backend (`@reclaimprotocol/js-sdk`) |
| `409`  | Proof already used (replay detected)                                      |

## List verified proofs

`GET /api/v1/proofs/zktls`

Auth: API key (`api_…`, `sk_…`, `rk_…`, `pk_…`).

| Query        | Type   | Description                           |
| ------------ | ------ | ------------------------------------- |
| `companyId`  | string | Filter proofs for a company           |
| `providerId` | string | Filter by provider                    |
| `limit`      | number | Results per page, max 200, default 50 |

Expired proofs are excluded. Returns `{ "data": [ ...proofs ] }`.

## Facilitator proof jobs (dashboard)

The dashboard's **Proofs** section also exposes live jobs:

| Endpoint                            | Auth              | Purpose                                          |
| ----------------------------------- | ----------------- | ------------------------------------------------ |
| `GET /api/v1/proofs/active`         | Dashboard session | Currently active proof jobs from the facilitator |
| `GET /api/v1/proofs/history?limit=` | Dashboard session | Recent proof jobs (JSON or CSV)                  |

## Using proof claims in feature flags

Once claims are written to a company's traits, feature-flag conditions can reference them. Common patterns:

* `zktls_claim_plan == "pro"` → grant plan-based entitlements from a Web2 SaaS proof
* `zktls_claim_quota > 1000` → unlock a higher usage tier

See [Feature flags and rules engine](/concepts/feature-flags) for rule syntax.

## Related

* [Feature flags](/concepts/feature-flags) — trait-based rule evaluation
* [Authentication](/api/authentication) — key compatibility for proofs endpoints
* [Entitlements & flags API](/api/entitlements-flags) — evaluating the resulting feature state