Getting started with your DROP module.

Step 1: Connect to DROP

Subscribe in CalPrivacy. Paste the API key here.

Open ai.trustsuperset.com/drop/api-key.

Two things have to happen before Superset can pull anything from California: subscribe to identifier lists in CalPrivacy's Data Broker Portal, and paste the resulting API key into Superset.

Subscribe to identifier lists

DROP has six consumer identifier lists. Subscribe to every list you could plausibly use to match a consumer, and you need at least one to use DROP at all.

Subscribe to the lists that match what you actually store. Don't store phone numbers? Don't subscribe to PHONE. Every list you subscribe to is one you're committing to match against on every batch, so be honest with yourself about what you've got.

Generate your Sandbox API key

The portal issues two API keys, Sandbox and Production, generated separately. The DROP module in Superset has the same two environments, switched with the Sandbox / Production toggle at the top of the module, and each stores its own key.

Start with a Sandbox key. California's Sandbox is the only environment that grades your matching performance, so it's the right place to prove your setup before real consumer data is in scope. The Production key comes in Step 4, once your Sandbox runs are clean.

In the Data Broker Portal, log in with your registered account, navigate to Sandbox Environment, confirm your list selection, and generate a new API key.

Copy that key. Back in Superset on the API Key & Lists page, paste it into the Paste API key field and hit Continue. Your API key is encrypted in transit and at rest.

Step 2: Set up your matching endpoint

The bridge between Superset and your data.

Open ai.trustsuperset.com/drop/endpoint.

Three legs to this: Superset forwards California's deletion requests to your endpoint in batches → your endpoint matches them against your records and returns a status code per request → Superset uploads the result to CalPrivacy. You own the middle leg.

To be crystal clear about whose endpoint this is: it's yours. You're giving Superset a URL on your own backend, and Superset pushes California's requests to it. Sandbox and production each keep their own endpoint configuration (Step 4 covers the production side), and both use the same authorization headers you set here.

What Superset sends you

Every day, Superset pulls the latest deletion requests from DROP and forwards them to your endpoint in batches. Recommended size: 500 records per request. Each record has exactly one populated identifier field. Every other field is null.

Example request body:

{
  "batch_id": "c2e4a6fa-8d44-4f6f-9ef9-7d4f1f1d8e6a",
  "sync_record_id": "c2e4a6fa-8d44-4f6f-9ef9-7d4f1f1d8e6a",
  "environment": "sandbox",
  "list_type": "EMAIL",
  "request_count": 500,
  "requests": [
    {
      "id": "7a3d9c73-39d8-40a5-bfcb-31d123456789",
      "drop_id": 679,
      "ndz": null,
      "email": "KA18MT/ph6IHYjzT9zwETySDQyvSh87YuoSBpOQtkhE=",
      "phone": null,
      "maid": null,
      "nvin": null,
      "ctvid": null
    }
  ]
}

Parse requests[]. Use id as Superset's canonical record ID in your response. Treat drop_id as California's work item ID. You'll need it if you ever audit a specific request back to the state.

The environment field tells you which pipeline a batch came from: sandbox identifiers are synthetic test data, production identifiers are real consumer requests. You can also use {{environment}} in your endpoint URL or headers to route the two apart on your side.

How matching works

For each record, hash your records using SHA-256 with Base64 output, following California's normalization rules, then compare against the hash Superset sent you. Normalization rules differ per identifier type. The full canonicalization rules live in CalPrivacy's official spec.

The most common normalization bugs are also the cheapest to catch: skipping transliteration on accented characters, holding onto whitespace, forgetting to lowercase before hashing. The Sandbox in Step 3 is built to surface those before they cost you a real consumer.

What you send back

Return JSON with one update per request. Each update needs just the Superset request id and the DROP outcome code. Four possible outcomes per record, mapped to California's official status codes:

• Not found response_status_code: 5. No match after completing the matching process.
• Deleted response_status_code: 3. Exactly one record matches; delete that consumer's non-exempt data on your side.
• Opted out response_status_code: 4. Multiple consumers are linked to the same identifier; opt them all out of sale or sharing.
• Exempted response_status_code: 2. The match is real but the data is retained under an exemption such as Civil Code §1798.99.86(c)(2).

Example response body:

{
  "updates": [
    { "id": "7a3d9c73-39d8-40a5-bfcb-31d123456789", "response_status_code": 3 },
    { "id": "16d9225f-b0c9-4a14-89ce-5b31abcdef12", "response_status_code": 5 },
    { "id": "d3f1f996-cd1e-4e4e-a3c6-82cdabcdef34", "response_status_code": 4 }
  ]
}

California's official result codes are 2, 3, 4, and 5. Full status code reference and file schemas in CalPrivacy's official spec.

Point Superset at your endpoint

On the Matching Endpoint page, drop in the URL Superset should POST to, leave the method as POST, and add any headers you need (auth tokens, signing keys) as a JSON object. Then hit Send test batch to confirm Superset can reach your endpoint and parse a response.

Step 3: Test in the Sandbox

Iterate until your hashing is right.

Open ai.trustsuperset.com/drop/overview.

This is the iteration step, and it's highly recommended before you go anywhere near production: the Sandbox grades your matching against California's spec and tells you what you got wrong. Synthetic dataset on California's side, your own normalized copy on your backend. Run a batch, see what matched and what didn't, fix your normalization, rerun.

Download the synthetic CSV

Click Download CSV to grab the synthetic dataset. Same CSV the Sandbox environment is going to send requests against. Think of it as a fake customer database for testing.

Normalize the synthetic dataset on your backend

Apply California's normalization rules and SHA-256 Base64 hashing to the records in your copy of the synthetic CSV. Stand up your matching endpoint to look up incoming hashes against this normalized set.

This is where you commit, on your side, to the canonicalization rules in CalPrivacy's official spec. The Sandbox is graded against exact-match. No "close enough."

Run a Sandbox batch

In Superset, trigger a test batch. Superset pulls a batch from California's Sandbox API and forwards it to your endpoint exactly as it would in production. Your endpoint responds; Superset records the response.

For each data subject you'll see three things side by side: the hash that was submitted, the response your backend returned, and the response Superset expected. That last column is the one that matters. When they don't match, you've got a normalization bug, and Superset will tell you which records hit it so you can fix them on your side.

A typical first run: a mix of matches, mismatches, and not-founds. Some of the not-founds are real (the synthetic dataset doesn't contain everyone California's Sandbox asks about). Some of the mismatches are normalization bugs. The point of iteration is to drive the mismatches to zero.

Fix, rerun, repeat

Fix your normalization, save your changes, rerun. No cap on Sandbox runs and no consumer data on the line. Burn through as many cycles as it takes.

Step 4: Flip to production

A production key, a production endpoint config, and you're live.

Once your Sandbox runs are clean, switch the module's Sandbox / Production toggle to Production and work through the same setup in the new environment:

• Generate a Production API key Same flow as Step 1, but in the portal's production environment instead of the Sandbox. It's a separate key generated independently; your Sandbox key doesn't carry over.
• Confirm your production endpoint configuration Production keeps its own endpoint configuration. It still points at your own backend, and it uses the same authorization headers you set in Step 2.
• Set your run and upload behavior In DROP Settings, turn on Run Production DROP Daily so Superset polls every day, and decide whether to enable Auto-Upload Completed Production Batches or review and upload each batch yourself (the default).

Once production is on:

• Production sync runs daily
  With Run Production DROP Daily on, Superset polls DROP every day, downloads the latest batch, and forwards it to your endpoint. DROP itself processes new data on a daily cadence, so daily polling means your endpoint sees requests the moment they're available.
• Daily maintenance window
  California's DROP API closes between 1:00 AM and 3:00 AM Pacific Time for daily batch processing. Plan around it for time-sensitive integration testing.
• You control uploads
  By default, a completed batch waits until you click Upload before anything goes back to California. Enable Auto-Upload Completed Production Batches in DROP Settings if you want clean batches sent automatically. Failed batches surface in your DROP dashboard for review either way.
• A record of every batch
  For every batch Superset pulls, you've got a record of how many were deleted, opted out, not found, and exempted, plus the download and upload timestamps. That's your audit trail when CPPA comes asking.

A few things to be clear about

You own normalization

We can't normalize your records for you, because that data lives in your systems, not ours. We hand you correctly-formatted hashes from California, you match against your records, the matching logic is yours. If you change your data formats (a CRM migration, a phone number cleanup, anything that touches identifier shape) you need to confirm your normalization still produces the same hashes California is sending. The Sandbox is the right place to verify after any change.

Treat the Sandbox as long-running, not a one-shot

Most customers spend more than one round in here before going live, and there's no downside to staying longer. The point is to drive your mismatches to zero on synthetic data before a real consumer is anywhere in scope.

DROP is distinct from your DSR Manager queue

Webform and email-submitted DSRs flow into your DSR Manager queue at ai.trustsuperset.com/dsars/manage. DROP requests come from California's centralized platform, arrive pre-hashed, and don't show up in the DSR Manager queue. Two systems running in parallel, not in sequence. If you haven't onboarded DSR Manager yet, the guide is at trustsuperset.com/docs/dsr-manager.

One identifier per request

Each DROP request has exactly one populated identifier field. If California asks about an email hash, every other field (phone, MAID, NVIN, NDZ, CTVID) is null on that request. Don't try to match across fields.

Two 45-day clocks: one to download, one to report

Per CalPrivacy, you must download your lists at least once every 45 days, and report the status of each request within 45 days of downloading it. Day 0 you download, Days 1 through 45 you process and upload, and your next download is due within 45 days of the last. We poll daily, which keeps you comfortably ahead of both clocks.