California DROP with Transcend

California's Delete Act requires registered data brokers to process consumer deletion requests through DROP (Delete Request and Opt-out Platform), run by CalPrivacy. This overview explains how Transcend fits into that workflow: what we cover, what stays on your side, and how to plan volume.

This is not legal advice. For the rules, see CalPrivacy's DROP materials and Transcend's DROP compliance guide. For configuration and a full cycle, see Set up and run California DROP.

Consumers register once with the state. DROP sends brokers hashed identifier lists (not plaintext emails or phones). You match those hashes to people in your systems, delete them (or opt out where required), and report a status back for every record.

Division of labor

• You match hashes against your identity graph and produce a matched-records CSV.
• Transcend pulls the hashed CPPA download from CalPrivacy (when configured), turns your matched records into erasure data subject requests (DSRs), runs them through your selected erasure workflow, and builds the CalPrivacy report-back file (Id,Status).
• In the current operator-led flow, you still upload the report-back file to CalPrivacy.

Transcend does not reverse hashes or invent matches.

Brokers must begin processing by August 1, 2026, on a 45-day cycle. The 45-day clock starts when the list is downloaded. See CalPrivacy's Processing DROP requests guidance.

Avoid older shorthand like “File 1 / File 2” in customer-facing docs and integrations.

Upload camelCase headers. Exact names matter — snake_case columns like drop_record_id / person_key / status_override are not accepted by the current intake path.

dropRecordId,dropListType,coreIdentifier,email,phone,maid,cppaStatusCode

Row model: CalPrivacy issues one work-item id per hashed identifier per list. The same person on email + phone + MAID is three rows, three dropRecordIds, one shared coreIdentifier → one DSR.

Records left out of the matched-records upload report as status `5` (not found) on report-back.

On matched-records uploads, put the person’s email in coreIdentifier. Opaque keys like person-0003 do not work.

• Use the same email in coreIdentifier on every row for that person.
• Still put plaintext in the email and phone columns when those list types matched.
• In the upload wizard, map email → email and phone → phone.
• After upload, open one DSR and confirm Identifiers shows email and/or phone.

Details are in Set up and run California DROP.

Operator-led Admin Dashboard loop with a six-step run wizard:

• Enable Data Broker DROP under Administration → Early Access.
• Configure broker credentials and an Internal erasure workflow (with a data subject).
• Pull CPPA requests now (or upload a CPPA download manually if your account team supports that path).
• Wait for record indexing to complete.
• Download a matched-records starter template from the run wizard (optional but recommended).
• Upload matched records in the run wizard; Transcend creates DSRs.
• Generate report-back; download; submit to CalPrivacy; mark submitted in Transcend.

Your account team can help you complete a sandbox cycle before production. Organization admins can also flip Early Access themselves.

• Automated matched-records upload via API for high-volume pipelines
• Scheduled, hands-off polling
• Transcend submitting report-back to DROP for you
• CLI / pipeline-first flows
• Multi-million-row single-shot uploads

If the current operator-led volume fits for August, you do not need later phases on day one.

DROP volume depends on how many Californians use DROP and which list types you subscribe to. Plan for growth each cycle.

Current browser upload is comfortable under roughly 100k rows per upload (and typical file-size limits). Prefer one open run at a time per broker organization. Prefer report, then pull sequencing: finish and submit the prior report-back before pulling the next list.

CPPA download rows are hashed identifiers, not people. Use the same email as coreIdentifier across a person’s email / phone / MAID matches so Transcend opens one DSR.

The CPPA download only has Id and Hash. You standardize identifiers the way CalPrivacy specifies, SHA-256 hash them, Base64-encode the digest, and compare. For every hit, matched records carry the DROP id, list type, and plaintext identifiers Transcend needs to erase (or a declared cppaStatusCode of 2 / 4).

Treat each Id as opaque: sandbox downloads have used numeric ids; production uses CalPrivacy's 12-character Base62 format. Echo the exact value you received.

Report-back is an Id,Status CSV. Every CPPA download id gets one status: exempt (2), deleted (3), opted out (4), or not found (5). Details are in Set up and run California DROP.

Do we still need the CalPrivacy portal? Yes in the current phase. You need CalPrivacy for registration, keys, and uploading the report-back.

Do we publish a DROP workflow to the Privacy Center? No. Use an Internal erasure workflow selected in DROP Configuration. Keep “Show in Privacy Center” off unless you want that erasure action on your Privacy Center for other reasons. The workflow must have a data subject configured, or DSR creation fails.

Can we use our internal person key as coreIdentifier? No — use the person’s email.

Do sandbox and production CPPA downloads look identical? Same Id,Hash columns and status codes; different environment and API key. Work item id shape may differ (numeric sandbox vs Base62 production). Validate hashing and a full cycle in sandbox, then confirm id format against a production download before go-live.

Do we report before pulling the next list? Yes: finish and submit the prior report-back before you pull the next list. Cadence is “report, then pull.”

1. Confirm you are (or will be) a registered California data broker.
2. Share list types and rough volume per 45-day cycle with your Transcend contact.
3. Follow Set up and run California DROP for configuration and a sandbox end-to-end run — especially the coreIdentifier checklist before your first production upload.