Submitted is not Filed

There are three states at the end of a DROP cycle, not two. Most tooling, most spreadsheets and most mental models carry two: you uploaded, or you did not. The platform actually gives you Submitted, then either Filed or Needs correction, and the gap between the first and the second is where a broker can sit for days believing a cycle is closed when it is not.

What a 202 Accepted actually says

You finish a cycle by uploading a status file: one CSV per list type, header exactly Id,Status, one row per work item ID you were given. You send it to POST /data/upload as multipart form data with your API key in the X-API-KEY header.

A well-formed submission returns 202 Accepted. The HTTP semantics of a 202 are the whole point: the request has been accepted for processing, and the processing has not been completed. DROP has taken your file. It has not yet told you whether the rows inside it are good.

The response body does carry counts, an accepted count and a rejected count, and those are worth recording. But they describe the intake, not the record-level validation that follows.

The three states, plainly

A cycle can also close as no new records, when the download returned nothing to act on. That is a fourth outcome, but it never passes through Submitted at all, because there is no file to upload. See the 45-day cycle for how the earlier states fit together.

How the outcome reaches you

This is the part that surprises engineers. DROP's documentation describes validation outcomes being delivered by email, to the contact addresses on the data broker account. In the technical material available to us, no polling endpoint was found that answers the question "has my submission passed validation yet?".

DROP does publish a webhook vocabulary, including upload.received and upload.processed events, signed with an HMAC over the timestamp and raw body using a per-broker signing secret shown once in the portal. A broker who configures webhooks in their own portal gets a signed, machine-readable signal. A broker who does not is left with the email.

That is a real structural gap, and it deserves to be stated rather than smoothed over. Any product that claims to detect Filed automatically without a webhook configured is, underneath, parsing a confirmation email. Email parsing is fallible: a message can bounce, be filtered, be sent to a contact who left the company, or have its wording changed by the agency without notice.

DropDue's honest floor: with no webhook and no inbound email route configured, the cycle stays Submitted and the interface says exactly that, with a manual "I received the CPPA confirmation" action that records who marked it and when.

Why two states are not enough

Suppose a dashboard shows a green tick as soon as the upload returns 202. Four things go wrong at once.

• A rejected file looks finished. Record-level errors arrive after the 202. If the interface already declared success, nobody goes back to look, and the rows sit unfixed while the interval clock keeps running.
• The evidence is weaker than it appears. A 202 proves you sent something. It does not prove the state accepted the contents. If you are ever asked to show a closed cycle, the artifact you want is the validation outcome, not the intake acknowledgement.
• The waiting window becomes invisible. Between submission and confirmation there is a period, typically a handful of days, where a cycle is neither open nor closed. That is precisely the window somebody asks about, and a two-state model has no place to show it.
• Retries get made blind. Re-uploading a file that is already queued does not help and can conflict with the open batch. Knowing you are in Submitted rather than Failed is what stops the second upload.

So the three states get three different treatments in the product: different labels, different colours, and never one word standing in for two. A Submitted cycle keeps a visible row of its own with a day counter, so it is not silently invisible while it waits.

What to keep as evidence

The record you want for each cycle is a short chain, and each link answers a different question.

• The status file as generated: its filename, its row count, and a SHA-256 of its bytes. This answers "what exactly did you send?".
• The confirmation of the human determination: who confirmed the worklist, when, and the per-code breakdown they confirmed. This answers "who decided?".
• The submission response, including the HTTP status and the accepted and rejected counts. This answers "did the platform take it?".
• The validation outcome, and how it arrived: a signed webhook, a parsed email, or a manual mark. This answers "did it pass, and how sure are you?".

That last distinction matters more than it looks. A confirmation that arrived as a signed webhook is stronger evidence than one parsed from an email, which is in turn stronger than one a person ticked by hand. Recording which of the three you have is more useful than pretending they are equivalent. A proof pack that shows a manual mark as a manual mark is worth more, under scrutiny, than one that quietly upgrades it.

What to do in each state

• Submitted. Nothing, for a few days. Watch for the confirmation. If it has not arrived after a week, check the contact addresses on the DROP account before assuming a platform problem.
• Filed. Close the cycle, keep the chain, and note the date. Your next due date runs from the download, not from this moment.
• Needs correction. Read the rejection detail, fix the specific rows, and submit an amendment through the documented amendment path rather than re-uploading the original file.

One more habit is worth building: keep the contact addresses on the DROP account current, and make sure at least two people receive the mail. Because the outcome arrives by email, the account contact list is not administrative trivia, it is part of the control.