Web Resource Ledger

Web Resource Ledger (WRL)

Cryptographic evidence of web content -- capture what a page looked like, when, with proof anyone can verify.

Submit a URL, get back a screenshot, rendered HTML, HTTP headers, and an Ed25519-signed WACZ bundle. The verification URL works for anyone -- no account needed. Deploy on your own infrastructure; your captures, your keys, your evidence.

WRL was built almost entirely by an LLM (Claude) with a human directing the work. Every phase -- from MVP to production -- is documented in docs/evolution/. The prompts, agent debates, decisions, and outcomes are all public.

For comprehensive guides on authentication, verification, batch captures, and MCP integration, see docs.webresourceledger.com.

Status: Production service, single-operator deployment. All three roadmap acts are complete. The API is pre-1.0 but functional, deployed, and serving real traffic.

What you get

A single API call produces:

• Dual screenshots (PNG) -- before and after cookie consent dismissal, so both the banner presence and the underlying page content are preserved
• Rendered HTML -- the DOM after JavaScript execution
• HTTP response headers -- the server's response at capture time
• Signed WACZ bundle -- all artifacts packaged, hashed, and signed with Ed25519
• Verification URL -- a shareable link anyone can use to confirm authenticity
• FRE 902(13) certification PDF -- GET /v1/captures/{captureId}/certificate returns a signed PDF describing the capture process and integrity evidence, designed to support a Rule 902(13) self-authentication foundation

Content Security

WRL screens every submitted URL against threat intelligence databases before capture begins:

• URLs identified as threats (malware, phishing, etc.) are rejected at submission time with a 422 response.
• Existing captures are re-scanned daily. Captures that fail re-screening are quarantined: metadata remains accessible, artifact downloads return 451.
• Screening degrades gracefully -- if the threat intelligence service is unavailable, captures proceed normally. The threatCheck field on a capture record reflects the outcome: pass, fail, or unavailable.

Configure the service via GOOGLE_WEB_RISK_API_KEY in your environment (see step 8b below). The key is optional; omitting it disables screening and all captures report threatCheck: unavailable.

Usage

Requires a running WRL instance. See Setup below.

export WRL_API_KEY=your_tenant_api_key

Tenant keys are created via the admin API (see step 8a). For deployments using the legacy static key, WRL_API_KEY is your CAPTURE_API_KEY value.

The examples below use api.webresourceledger.com. Replace with localhost:8787 for local dev or your own deployment URL if self-hosting.

Step 1: Submit a capture

curl -X POST https://api.webresourceledger.com/v1/captures \

-H "Authorization: Bearer $WRL_API_KEY" \ -H "Content-Type: application/json" \ -d '{"url": "https://example.com"}'

{

"id": "cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6", "statusUrl": "https://api.webresourceledger.com/v1/captures/cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/status", "note": "Use GET /v1/captures to list and search your captures." }

Your captures are always accessible. Use GET /v1/captures to list them, or save the capture ID for direct access.

Step 2: Poll for completion

curl https://api.webresourceledger.com/v1/captures/cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6/status

Poll until status is complete or failed. The response includes a captureUrl when complete.

Step 3: Retrieve artifacts

curl https://api.webresourceledger.com/v1/captures/cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

Returns metadata and signed artifact URLs (screenshot, html, headers, wacz) plus a verifyUrl.

Step 4: Verify the bundle

curl https://api.webresourceledger.com/v1/verify/cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6

Returns a JSON verification result with up to four checks: artifactHashes, bundleHash, signature, and (for new captures) timestamp. The timestamp check verifies an RFC 3161 independent timestamp obtained at capture time. Legacy captures return three checks. The verifyUrl from step 3 also renders as a human-readable page in browsers.

Capture URLs are directly shareable -- anyone with the capture ID can access the capture and its artifacts. No tokens needed.

Sharing: Capture URLs are inherently shareable. Anyone with the URL can access the capture record and all artifacts. For proof-of-authenticity, share the verifyUrl which renders as a human-readable verification page.

Offline verification

For independent, offline verification -- including full CMS/PKCS#7 certificate chain validation -- use the CLI tool:

npx @w-r-l/verify capture.wacz --origin https://api.webresourceledger.com

See packages/verify/ for details.

Finding captures

GET /v1/captures lists your captures (requires your API key). Use it to browse and recover capture IDs.

curl https://api.webresourceledger.com/v1/captures \

-H "Authorization: Bearer $WRL_API_KEY"

{

"data": [ { "id": "cap_a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6", "status": "complete", "url": "https://example.com", "createdAt": "2024-01-15T10:30:00.000Z", "completedAt": "2024-01-15T10:30:45.123Z" } ], "pagination": { "cursor": null, "hasMore": false, "limit": 20 } }

Optional query parameters: limit (1-100, default 20), cursor (for paging), status (pending, complete, failed, or quarantined).

Captures are rate-limited to 10 per minute per IP. Verification is limited to 60 per minute per IP. Error responses use RFC 9457 application/problem+json format. For full details, see openapi.yaml.

Detailed guides: See Getting Started for a complete walkthrough, or browse the API Reference for the full endpoint catalog.

Setup

Prerequisites

• Wrangler CLI installed and authenticated
• Node.js 22+ (see .nvmrc)
• Cloudflare account with R2 and Browser Rendering enabled

1. Install dependencies

npm install

2. Create D1 database

wrangler d1 create wrl-metadata

Update the database_id in wrangler.toml under [[d1_databases]] with the returned ID. Then apply migrations:

wrangler d1 migrations apply wrl-metadata

2a. Create KV namespace (rate limiting)

KV is used only for rate limit counters. Create the namespace:

wrangler kv namespace create wrl-kv

Update wrangler.toml with the returned id and preview_id.

3. Create R2 bucket

wrangler r2 bucket create wrl-captures

wrangler r2 bucket create wrl-captures-preview

4. Configure capture API key (legacy fallback)

CAPTURE_API_KEY is a static bearer token that acts as a fallback when no tenant key is found in D1. For new deployments, consider setting up the admin API (step 8a) and creating tenant keys instead. For existing deployments, this key continues to work during migration.

In the usage examples above, this is $WRL_API_KEY.

Generate a key:

openssl rand -hex 32

Set the production secret:

wrangler secret put CAPTURE_API_KEY

For local dev, add to .dev.vars:

CAPTURE_API_KEY=<hex string from the command above>

Security: Never commit this value to version control. .dev.vars is already in .gitignore.

5. Configure signing key

WRL signs WACZ bundles with Ed25519. The signing key is optional -- if SIGNING_KEY is not set, captures complete successfully but without WACZ bundles (screenshot, HTML, and headers are still stored).

Generate a key pair:

node scripts/generate-signing-key.js

The script prints a private key (PKCS8 DER, base64) and the corresponding public key (raw, base64). The public key is embedded automatically in every signed bundle for verification -- no separate distribution needed.

Set the production secret:

wrangler secret put SIGNING_KEY

Paste the private key (PKCS8 DER, base64) when prompted

For local dev, add to .dev.vars:

SIGNING_KEY=<base64 string from the script>

Security: Never commit the private key to version control. .dev.vars is already in .gitignore.

6. Configure IP hash seed (recommended)

IP_HASH_SEED is an HMAC seed used to hash IP addresses before they appear in logs. Without it, log entries have no IP correlation for abuse analysis.

Generate a seed:

openssl rand -hex 32

Set the production secret:

wrangler secret put IP_HASH_SEED

For local dev, add to .dev.vars:

IP_HASH_SEED=<hex string from the command above>

7. Configure Coralogix log ingestion (required for production observability)

CORALOGIX_SEND_KEY is the API key for structured log ingestion to Coralogix. Without it, the Worker runs normally but logs go to console only -- no structured log ingestion occurs. For fork developers who do not use Coralogix, this key is effectively optional.

Find your send key in the Coralogix dashboard under Settings > Send Your Data > API Keys.

Set the production secret:

wrangler secret put CORALOGIX_SEND_KEY

For local dev, structured logs are emitted to the console. No key is needed for wrangler dev.

8. Configure CORS origins (optional)

CORS_ORIGINS is a comma-separated list of allowed origins for CORS preflight responses. Only needed if browser-based clients will call the API directly.

Set it as an environment variable in wrangler.toml (not a secret):

[vars]

CORS_ORIGINS = "https://app.example.com,https://www.example.com"

If omitted, cross-origin requests from browsers are blocked. Server-to-server requests are unaffected.

8a. Configure admin key (required for per-tenant key management)

ADMIN_KEY is the bearer token for the admin API (/v1/admin/keys). It grants the ability to create, list, and revoke per-tenant API keys. It does not grant capture or read access.

Generate a key:

openssl rand -hex 32

Set the production secret:

wrangler secret put ADMIN_KEY

For local dev, add to .dev.vars:

ADMIN_KEY=<hex string from the command above>

Once deployed, create your first tenant key:

curl -X POST https://api.webresourceledger.com/v1/admin/keys \

-H "Authorization: Bearer $ADMIN_KEY" \ -H "Content-Type: application/json" \ -d '{"tenantId": "default", "scopes": ["capture"], "name": "default-key"}' | jq .

Use the returned key value as $WRL_API_KEY going forward. See OPERATIONS.md for the full migration runbook.

Security: Never commit this value to version control. .dev.vars is already in .gitignore.

8b. Configure content security screening (optional)

GOOGLE_WEB_RISK_API_KEY enables URL threat screening before capture and during daily re-scans. Without it, all captures report threatCheck: unavailable and no URLs are blocked.

Obtain a key from the Google Cloud Console with the Web Ris