Summary: Reclaim Protocol is best understood not as just another identity-verification app or generic zkTLS brand, but as a productized middleware stack for turning HTTPS-delivered account data into reusable claims. The official docs split the system into provider definitions for specific websites, client-side extraction and redaction of the needed fields, cryptographic proof generation over the source HTTPS response, attestor / witness infrastructure that participates in or signs parts of the verification flow, and SDK-level delivery surfaces such as QR flows, browser extension flows, app redirects, callback URLs, and onchain verifiers. The reusable mechanism insight is that Reclaim packages the messy middle layer between lower-level web-proof primitives like TLSNotary and app-specific verification outcomes: provider reverse engineering, claim-request orchestration, attestor deployment, proof transport, and verifier integration become the real control surfaces.
What it does:
Lets applications request proofs about user data that originates on third-party websites such as university portals, payroll systems, airline programs, banks, and public or API-key-protected APIs
Uses provider definitions to specify which HTTPS request matters, what fields to extract, and what regex / JSON-path conditions must be satisfied for a claim
Generates privacy-preserving proofs client-side so only the needed fact is revealed rather than the entire document or webpage
Ships SDK flows for web and mobile integrations, including QR-based flows, browser-extension support, portal / iframe flows, app redirects, status URLs, callback URLs, and proof verification helpers
Exposes a zkFetch mode for proving facts about ordinary API responses, not only interactive website sessions
Maintains lower-layer attestor / witness infrastructure that intermediates secure data exchange and signs user claims with minimal disclosure
Supports backend and onchain verification surfaces rather than limiting claims to one hosted consumer app
Key claims:
The official homepage frames Reclaim as a response to AI-forgeable document workflows: instead of uploading PDFs or screenshots, users log into the source system and generate cryptographic proof directly from the source website. That makes the project more analytically useful as verification middleware than as a generic KYC or identity label.
The docs are especially valuable because they expose the intermediate control layer. Reclaim says a site-specific provider identifies the relevant HTTPS request, then uses regex and JSON-path rules to isolate only the needed field. This means the decisive governance surface is often not the eventual proof object, but the provider template and its extraction logic.
The same docs explicitly say unsupported websites can be added by reverse engineering the site and that the developer portal includes tooling to automate much of that work. That is an important sign that Reclaim is partly a provider-definition and claim-authoring platform, not just a fixed verification API.
The attestor-core repository makes the lower layer more concrete: an attestor server sits between the user and the internet, leverages TLS properties plus zero-knowledge proofs, and signs the resulting claim data so the client can present it elsewhere. This is a more specific architecture than the broader homepage marketing alone suggests.
The JavaScript SDK README shows that Reclaim has productized the proof-transport layer as well. A claim request can become a request URL, QR code, status URL, browser-extension flow, embedded iframe, or verifier-app redirect. That makes Reclaim a useful comparison point for systems where proof generation is open but proof delivery UX quietly recentralizes user and developer behavior.
zkFetch is analytically important because it shows Reclaim is not limited to identity-style account facts. The docs frame it as a fetch-like interface that returns (request, response, zkproof) tuples with optional redaction, pushing Reclaim toward a more general offchain-fact attestation layer.
The corpus should keep Reclaim because it adds a missing productized branch between lower-layer web-proof primitives and higher-layer credential or payment systems. Without it, TLSNotary, Primus, vlayer, zkTLS Protocol, and payment-proof systems are too easy to flatten into one generic web proofs bucket.
Whitepaper: The docs link both an official whitepaper and a formal security analysis, but the strongest readable primary materials in this pass were the official homepage, docs, SDK materials, and core-attestor repository collected in ../whitepapers/reclaim-primary-sources-2026-05-11.md.