Data Breach API: Separate Ingestion Progress from Remediation

An exposure feed can be fully processed while a credential remains at risk. When integrating a data breach API, teams must separate answers to two distinct questions: have we saved this record, and has the responsible team addressed the exposure?

LiteLLM’s October 23, 2026 attack-chain report provides context for why distinguishing the two questions is important. In the report, LiteLLM disclosed that an exposed master key was determined to require revocation, but revocation did not occur. The report goes on to discuss how that key granted access to a different exposure. This should not be read to mean that the key was in the data breach API.

Integration teams should separate ingestion and remediation state. A potential application design is provided below.

Keep Two Types of State

The ingestion state should be saved to a checkpoint. The remediation state should be saved to a log. The remediation log should identify the owner, indicate if the owner has reviewed the entry, and include evidence supporting closure.

There should be no impact to a case when a checkpoint is advanced. Likewise, there should be no impact to a case when a feed is reprocessed.

Webz.io’s Data Breach Detection API should be integrated in a way that defines its own case closure.

Save the Page before Advancing

Relative next-page URLs are provided in Webz.io’s API responses. It is suggested that when paging through results, the sorting parameters of a request be maintained.

When saving a page and a checkpoint, do both in the same database transaction. If that transaction fails, use the previously saved checkpoint to repeat the process. Doing this ensures the checkpoint is not moved to a position beyond where data has been saved.

Treat a completed page as an ingestion event. This means it does not guarantee a session has been revoked or that a key has been rotated. It also does not confirm a password has been reset.

Ensure replay safety for downstream actions

Use record identifiers and scope them with your tenant and feed to recognize a record your application has previously saved. Keep the source record. Keep case grouping as a separate decision; different records may be relevant to the same case.

For actions sent to another system, keep the case record update and the action request synchronously. A worker can be told to deliver the request using the other system’s retries. Record the delivery status of an action separately from case evidence that verifies remediation.

A timeout should prompt a status check before repeat action. For instance, a successful request submission is different from a confirmed security change.

Test failure paths before production

Replay a saved page twice. Make sure the second pass updates the existing ingestion record, and does not create a new case or action just because the page was repeated.

Interrupt processing before the database commit. Make sure the next run resumes from the previous checkpoint.

Finally, simulate an action timeout. Make sure your worker can reconcile the state of the destination and retain case history.

These are tests of your integration, not guarantees supplied by an exposure feed. Keep them focused on your database, queue and response system.

A good dashboard shows both ingestion status and remediation status. An empty feed or an exhausted page cursor can’t tell you if a previously exposed credential has been remediated.