zkTLS Attestation · Developer docs

zkFetch

Generate a cryptographic proof that a specific HTTPS request was made and returned a specific response, without trusting the party who made it. Credentials stay hidden, chosen response fields are selectively revealed, and proofs verify off-chain in milliseconds or on-chain on any EVM.

View .mdPDF
Jump to quick start →
RESTno SDK required
ECDSAattestor signatures
Groth16zk selective disclosure
EVMon-chain verifiable
01

What it is

zkFetch proxies an HTTPS request through a decentralized attestor. The attestor observes the encrypted TLS session, verifies a zero-knowledge proof of correct decryption, and signs a claim about the response. The result is a portable proof: anyone can confirm what the API returned, and you decide which fields are revealed and which stay hidden.

Prove any API response
a signed claim over exactly what a server returned
Hide secrets
API keys and tokens are cryptographically redacted from the proof
Selective disclosure
reveal only the fields you name, redact everything else
Verify anywhere
off-chain in milliseconds, or on-chain on any EVM
02

Getting started

zkFetch is a REST service you run. Point at your deployment’s base URL, referred to below as $ZKFETCH_URL, and start proving requests. The server holds the Reclaim credentials and the attestor connection, so callers send no API key to zkFetch itself. The only secrets you handle are the ones your own target APIs need, and those stay hidden in privateOptions.headers.

  1. 01Point $ZKFETCH_URL at your deployment.
  2. 02Confirm it is live: GET $ZKFETCH_URL/health reports mode: production.
  3. 03Make your first proven request and store the proof.
  4. 04Hand the skill to your coding agent to wire up the integration.
View .mdPDF
03

Quick start

Confirm the service is in production mode, then make a proven request. Put every credential in privateOptions.headers so it is hidden from anyone who inspects the proof.

check the service is live
curl $ZKFETCH_URL/health
# { "status": "ok", "mode": "production", "reclaim_configured": true }
make a proven request
curl -X POST $ZKFETCH_URL/zkfetch \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://api.example.com/v2/booking/8821",
    "publicOptions": { "method": "GET" },
    "privateOptions": {
      "headers": { "Authorization": "Bearer YOUR_SECRET" },
      "responseMatches": [
        { "type": "regex", "value": "\"status\"\\s*:\\s*\"(?<status>[A-Z]+)\"" }
      ]
    },
    "redactions": [ { "jsonPath": "$.card_number" } ]
  }'

From code, reject anything where verified is not true or metadata.mock is set. The full wrapper pattern is in the skill.

04

Endpoints

GET/healthService status and mode (production vs mock)
POST/zkfetchMake a proven HTTPS request; returns data and proof
POST/verifyVerify a proof’s attestor signatures (fast, primary check)
POST/verify-fullSignatures plus Groth16 zk-SNARK verification
POST/transform-onchainReshape a proof for EVM smart-contract submission

A successful /zkfetch returns data, proof, onchainProof, and verified. Store the entire proof object verbatim; it is what verifiers need.

05

Selective disclosure

Two independent mechanisms, used together. Reveal fields with named regex capture groups, and hide fields with redactions.

Reveal

Each named group in responseMatches becomes a revealed value. Only named groups are disclosed.

{ "type": "regex",
  "value": "\"usd\":(?<price>[0-9.]+)" }
// reveals price: "3631.24", nothing else

Redact

Top-level redactions hide bytes cryptographically. Values are removed, not replaced.

{ "jsonPath": "$.user.email" }
{ "regex": "\"card\"\\s*:\\s*\".*?\"" }
// prove success, hide the body:
{ "regex": ".*" }
06

Verify a proof

Anyone holding a stored proof can confirm it. Signature verification is the standard, fast check; add zk verification only when the application demands maximum assurance.

verify signatures (primary check)
curl -X POST $ZKFETCH_URL/verify \
  -H 'Content-Type: application/json' \
  -d '{ "proof": <stored proof object> }'
# { "success": true, "valid": true, "extractedData": { "status": "CONFIRMED" } }

For smart contracts, /zkfetch already returns an onchainProof. Submit it to a Reclaim verifier contract on Ethereum, Base, Optimism, Polygon, or zkSync Era.

07

Always confirm real proofs

The service has a mock mode. If its Reclaim credentials are missing, a request still returns success: true with a fake proof that proves nothing. Guard every integration.

  • On startup, require GET /health to report mode: production.
  • After every /zkfetch, reject the result if metadata.mock is true or verified is not true.
  • Never treat success: true on its own as evidence of a valid proof.

This page is the short reference. The full integration guide, including every option and common mistake, is the zkfetch skill. Copy it above and hand it to your coding agent.