zktls_claim_plan = "pro").
Submit & verify a proof
POST /api/v1/proofs/zktls
Auth: API key (api_…, sk_…, rk_…, pk_…).
object
required
The Reclaim Protocol proof to verify. Must include provider metadata (
providerId) and claimData.object
Company identity (
id, wallet, or email) to attach the verified claims to. If omitted, the proof is stored without a company linkage.object
User identity, resolved within the company.
number
Proof lifetime in seconds.
0 = no expiry. Omit for no expiry.Example
Response
Side effects
On success, ArcenPay:- Stores the verified proof with a SHA-256
proofHash(replay-protected — re-submitting the same proof returns409). - Writes
zktls_<providerId>: trueandzktls_claim_<key>: <value>traits onto the linked company. - Invalidates the feature-flag cache so trait-based rules re-evaluate immediately.
Errors
List verified proofs
GET /api/v1/proofs/zktls
Auth: API key (api_…, sk_…, rk_…, pk_…).
Expired proofs are excluded. Returns
{ "data": [ ...proofs ] }.
Facilitator proof jobs (dashboard)
The dashboard’s Proofs section also exposes live jobs: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 proofzktls_claim_quota > 1000→ unlock a higher usage tier
Related
- Feature flags — trait-based rule evaluation
- Authentication — key compatibility for proofs endpoints
- Entitlements & flags API — evaluating the resulting feature state

