Forge identical twins of your API responses.

Drop in a response from BigCommerce, Shopify, Piano, Stripe, or one of seven other platforms. DoppelForge returns a doppelgänger - identical structure, safe values - ready to paste into a blog post, support ticket, Stack Overflow answer, or your favorite LLM.

Why this exists

Real API responses are leaky. They carry emails, prices, tokens, customer IDs - anything you'd never want in a public gist. But hand-redacting every field is tedious, error-prone, and breaks the shape of the data.

DoppelForge solves both problems at once. The output looks identical to the original. The values don't put anyone at risk.

Same shape. Safe values. Counterfeit, with consent.

The name

DoppelForge is a portmanteau. Doppel from the German doppelgänger - an apparition or counterpart that looks identical to a living person. Forge from Latin faber, smith - a verb that means both to create through skilled craft (a blacksmith forges iron) and to counterfeit convincingly (forge a signature). Both meanings apply. DoppelForge forges doppelgängers of your API responses: counterfeits skilled enough to pass as real, while keeping every byte of sensitive data behind the workshop doors.

What you get

How to use it

1. Open the tool. The two-pane editor loads with the original on the left and the forged twin on the right.
2. Paste a real API response. JSON or XML, from any supported provider. Auto-detection promotes the right field map; you can also pick a provider manually from the sidebar.
3. Copy the doppelgänger. Send it onward with confidence - no real names, emails, phones, addresses, or IDs go with it.
4. Tweak fields if needed. The field-controls panel lets you toggle individual fields on or off if a particular value should pass through untouched.

Why it's different from redact or find/replace

• Schema-aware. Knows that customer_group_id is a non-PII business field and shouldn't be touched, while data[].email is PII and should be faked. A regex can't make that distinction.
• Referentially consistent. The same customer_id appearing at data[0].id and nested in orders[5].customer_id becomes the same fake ID everywhere - so the LLM (or downstream parser) can still reason about joins.
• Realistic fakes. Faker generates believable names and emails. The string "REDACTED" doesn't pattern-match to anything useful.

Supported providers

Seventeen providers, 220 endpoints. Each provider ships with hand-curated field maps that distinguish PII from business identifiers across multiple endpoints, plus webhooks and (where applicable) GraphQL, CSV exports, and form-encoded payloads.

• Auth0 - users, tenants, clients, roles, organizations, logs
• BigCommerce - customers, addresses, subscribers, orders, carts, products, transactions, refunds
• Braintree - customers, transactions, subscriptions, disputes, payment methods, merchant accounts
• HubSpot - contacts, companies, deals, tickets, products, line items, quotes, lists, forms
• Mailchimp - lists, members, campaigns, webhooks
• PayPal - orders, subscriptions, invoices, payment captures, refunds, webhooks
• Piano.io - users, accesses, subscriptions, terms, offers, resources, conversions, payments
• Recharge - customers, subscriptions, charges, orders, addresses, payment methods
• Salesforce - contacts, accounts, leads, opportunities, cases (REST + GraphQL)
• SendGrid - contacts, lists, segments, mail send, suppressions, events
• ShipperHQ - rate quotes, requests (REST + GraphQL)
• Shippo - addresses, parcels, shipments, rates, transactions, tracking, webhooks
• Shopify - customers, orders, products, draft orders, fulfillments, discounts, inventory, gift cards
• Square - customers, orders, payments, webhooks
• Stripe - customers, charges, payment intents, subscriptions, invoices, payouts, refunds, disputes
• Twilio - messages, calls, conferences, recordings, phone numbers
• Zendesk - tickets, ticket comments, users, webhooks

Unknown endpoints fall back to a generic pattern detector - still useful, just lower fidelity. Adding a new provider is one YAML file per endpoint; no engine changes required. See how to contribute.

Security & privacy

Privacy is the product, so it's enforced by construction - not by promise. Three layers:

1. No network code in the bundle. The application source contains zero fetch(), XMLHttpRequest, WebSocket, EventSource, or navigator.sendBeacon calls. The build deliberately strips Vite's modulepreload polyfill so that no fetch() remains in the production bundle to grep for.
2. CSP-enforced at the browser. The deployed site ships with a strict Content Security Policy: connect-src 'none', frame-ancestors 'none', object-src 'none'. Even a hypothetically compromised dependency couldn't open a network connection - the browser would refuse it before any bytes left your machine.
3. CI-gated. Every commit runs a bundle audit step that fails the build if any of those network primitives sneak back in. The privacy claim has automated enforcement, not just code review.

No analytics, no telemetry, no error reporting libraries are dependencies. The only thing that ever crosses the network is the initial download of the static bundle from Cloudflare Pages.

Don't trust the deployed site? Run it locally: git clone, cd web, npm install, npm run dev.

What's stored on your device

DoppelForge uses localStorage on this origin only. Nothing is sent off-device, ever. Every key the app writes is namespaced under doppelforge.; the table below is the complete list.

Want everything gone in one shot? The "Forget everything" button in the footer of the app wipes every doppelforge.* key from this browser and reloads. Use it when you're done, on a shared machine, or just to prove the privacy claim to yourself.

No cookies. No sessionStorage. No IndexedDB. No service worker. No navigator.userAgent sniffing.

How to contribute

Most contributions to DoppelForge are new field maps for endpoints we don't yet cover. That's the durable, high-leverage work - the engine itself is intentionally thin, and the field-map library is the long-lived community asset. The smith builds the tool; the community builds the catalog.

Add support for a new endpoint

Drop a single YAML file at providers/<provider>/endpoints/<slug>.yaml. It declares the endpoint metadata, a signature for auto-detection, and a field-by-field obfuscation map using a typed vocabulary (email, fullName, id, preserve, auto, …). No engine code changes. Webhooks, GraphQL, CSV exports, and form-encoded bodies are all supported.

The full schema, type vocabulary, conventions, and best practices for marking PII fields live in CONTRIBUTING.md.

Request a new provider

Open a new provider request on GitHub with the platform name, docs URL, and the endpoints you most want to see covered. A sanitized sample response makes forging the field map dramatically faster.

Report a field-map bug

If a real response from a supported endpoint comes back with PII leaked or its shape broken, open a field-map bug. Include a sanitized example of the input and the unexpected output.

Under the hood

• Stack: React 19 · Vite · TypeScript
• Editor: CodeMirror 6
• Fake data: @faker-js/faker
• Parsing: fast-xml-parser, native JSON
• Field maps: YAML (js-yaml)
• Hosting: Cloudflare Pages (static, no Functions)

MIT licensed. View the full source on GitHub →