The DROP 45-day cycle, start to finish

DROP is the Delete Request and Opt-out Platform the California Privacy Protection Agency runs at databroker.drop.privacy.ca.gov. Consumers file one deletion request there, and every registered California data broker is expected to pick that request up and act on it. The mechanism that turns that into an operational obligation is a repeating 45-day cycle: download the list, work it, report back, and start the clock again.

CalPrivacy's published dates put the start of processing at August 1, 2026. Consumers could begin submitting requests in January 2026, the sandbox opened in March 2026, and from August 1 brokers must begin processing DROP requests, then at least once every 45 days after that. Those dates come from the agency's own broker page at privacy.ca.gov.

The clock is yours, not a shared calendar

The single most common misreading of the 45-day rule is that it is a fixed quarterly calendar every broker shares. It is not. The obligation is stated as an interval: you must access DROP at least once every 45 days. That means the due date is your own last successful download plus 45 days. Two brokers who registered on the same day and downloaded on different days have different due dates, forever, and a broker who pulls early moves their own next due date earlier with it.

Two practical consequences follow. First, there is no external reminder to lean on: nothing in DROP tells you that day 44 has arrived. Second, the date drifts every cycle, which is exactly the kind of moving deadline a spreadsheet gets wrong after the third or fourth iteration. If you want to see the drift written out, the cycle calendar projects the next several cycles from a date you enter.

Interval

At least once every 45 days

Anchor

Your last successful download, not a fixed quarter

Processing begins

August 1, 2026

Portal

databroker.drop.privacy.ca.gov

Registration deadline

January 31, annually

Status codes

2 exempted, 3 deleted, 4 opted out, 5 not found

One cycle, step by step

A cycle is nine steps. The first eight are mechanical and can be run by software. The ninth is the one a person has to do.

1. 01Download. Call GET /data/download with your API key in the X-API-KEY header, or click through in the portal. What comes back is a ZIP: one CSV per deletion list you are subscribed to, plus a separate Removed file listing identifiers withdrawn since your last pull.
2. 02Read the rows. Each row in a list CSV is a work item ID and a hash. The work item ID is a 12-character Base62 string. The hash is what you will compare against, not a name or an email address: DROP never hands you a raw consumer identifier.
3. 03Standardize your own records. Apply the DROP standardization rules to every field in your roster before you hash anything: lowercasing, whitespace removal, date reformatting, and the rest. Standardization is where most silent failures start.
4. 04Hash your records. SHA-256 over the UTF-8 bytes of the standardized value, output Base64. The NDZ and NameVIN lists are composites and are hashed twice, in a fixed field order.
5. 05Match. Compare your hashes against the hashes in the downloaded CSVs. This is a set intersection, and it is the only place a consumer request meets your data.
6. 06Decide, row by row. Every work item ID you were given needs a status: 2 exempted, 3 deleted, 4 opted out, or 5 not found. Rows you never matched are 5. Rows you matched need a real determination, and that determination is yours.
7. 07Build the status file. One CSV per list type, header exactly Id,Status, named <YYYYMMDD>_<DataBrokerId>_<DataType>[_suffix].csv. If a list needs more than one upload, each additional batch carries a suffix. DROP rejects a duplicate filename inside one download.
8. 08Upload. POST /data/upload as multipart form data, CSV rather than ZIP. A clean submission returns 202 Accepted, which means the file is queued for validation.
9. 09Wait for the validation outcome, then close the cycle. A 202 is not the end. Record-level validation happens afterwards, and the result reaches you by email.

Step nine is the one that trips people up, and it is worth its own page: see Submitted vs Filed for what the two words mean and why collapsing them is the expensive mistake.

The states a cycle passes through

When DROP tells you to wait

DROP prepares your download asynchronously, so the first call often does not return data. Four responses are worth knowing by name, because three of them are normal control flow and only one is a real problem.

• 202 Preparing means the export is being built. The response carries a Retry-After header. Wait that long and call again. This is not an error and should never be shown to anyone as one.
• 429 Too Many Requests means you are calling too often. Back off and retry. Aggressive polling is not a workaround, it is the cause.
• 500 and other 5xx responses are transient. Back off and retry on the same schedule.
• 409 Conflict is different. On download it means a previous batch is still open and its responses are outstanding. On upload it means there is no active download waiting for responses. A 409 is a state problem, not a timing problem, and retrying blindly will not clear it.

In practice this means a pull is not one HTTP call, it is a retry schedule spread over a day or two, with a hard stop and an alert if it never succeeds. It also means you should never open a second download while a prior one is unclosed.

The cycle where nothing matches

Plenty of cycles end with zero matches. A small broker with a narrow list may go several cycles without a single hash in common with the DROP file, and a 200 OK with no new records is a perfectly ordinary outcome.

A zero-match cycle is still a cycle. You accessed DROP inside the 45-day window, and that access is the thing you may later be asked about. So the cycle closes with an audit entry that records the pull, the timestamp, the record counts, and the fact that there was nothing to file. Treating a quiet cycle as no cycle at all leaves a gap in the record exactly where the interval obligation lives.

The human confirm gate

Steps one through five and step seven are arithmetic. Step six is a judgment: for every matched row, is this record deleted, exempted, opted out, or not found? That judgment belongs to the data broker of record. It is not a default, it is not a vendor setting, and nothing should be transmitted to the state until a named person has looked at the counted set and confirmed it.

DropDue runs steps one through five and seven, and then stops. A person reviews the worklist and confirms it, the confirmation is written to an audit log with who and when, and only then is the status file built and uploaded. If nobody confirms, the cycle waits and chases rather than filing something nobody looked at.

Exemptions carry a reason. That reason is kept in your own audit record. It is not sent to the CPPA, because the status file carries exactly two columns: Id and Status.

What to keep from every cycle

• The date and HTTP outcome of the download, including the attempts that returned 202 Preparing.
• The list types pulled and the row count of each file.
• The match counts, broken down by the four status codes.
• Who confirmed the determinations, and at what timestamp.
• The status file itself, its filename, and a checksum of its bytes.
• The submission response, and afterwards the validation outcome that closed the cycle.

None of that is exotic, but it has to survive staff turnover and the passage of a year. A cycle you ran perfectly and cannot evidence is, from the outside, indistinguishable from a cycle you skipped.