Data Breach API: Define What Your Exposure Counts Actually Measure

A dashboard showing “exposed users” may actually be counting returned records. Those records can include repeated observations, several services associated with one account name, or entries that contain no usable account identifier. The label needs a definition before the number can support a decision.

HKCERT’s October 28, 2026 FortiBleed 2.0 alert makes this distinction explicit. It says credential and account record totals do not represent unique users, currently valid credentials or newly confirmed affected organizations. The alert concerns newly obtained material from an earlier period, not a newly established attack wave.

Hudson Rock’s October 27 analysis also distinguishes account records, cleartext secrets, hashes and undecrypted values. For developers integrating a data breach API, the practical lesson is to specify the unit being counted before aggregating the data.

The example below is a proposed application design using synthetic records. It does not claim that FortiBleed material is available through Webz.io’s API.

Write a definition for every displayed total

Start with the dashboard question. Do you need the number of observations retrieved, the number of identified service accounts, or the number of records containing a particular kind of secret? Give each measure its own label.

Record the query scope, time filter and calculation rule with the result. Include the application version that produced it. A reader should be able to tell whether a changed total reflects new evidence or a changed grouping rule.

Avoid “affected people” unless you have an independently supported way to map accounts to people. An account can be shared, automated or assigned to someone different from its historical owner. A distinct account identifier is not automatically a distinct human.

Keep unresolved records visible. Excluding them from an account-group total may be necessary, but show how many were excluded and why. Otherwise, a cleaner-looking number can conceal gaps in the underlying evidence.

Test the count with four fictional records

Use a small fixture set before processing live data. The following table deliberately repeats an account across sources and services. “Present” describes the synthetic record, not successful authentication.

This set contains four source observations. Under a rule grouping exact account identifiers within a service, it contains two identified service-account groups. R-4 remains unassigned because its account identifier is missing.

Three observations contain a secret representation, but only two are labelled plaintext. Those are record-level counts. They do not establish three distinct credentials, two working passwords or any particular number of people.

Make these expected outputs part of the test. If the dashboard displays four users, the calculation or label has failed even though four rows were correctly loaded.

Scope account grouping to the service

Keep Service A’s account-7 separate from Service B’s account-7 unless independent evidence supports linking them. The identical account name is insufficient to establish a shared identity across those services.

Write down which identifier combinations your application accepts. If a record lacks the service or account field required by that rule, route it to an unresolved category. Do not fill the missing value from an unrelated neighboring record.

Preserve the original identifier when applying a documented normalization. Record which rule changed it. A later reviewer needs to see whether an apparent match came from the source or from your application’s interpretation.

Retain the observations underneath each group. R-1 and R-2 can support the same account group while remaining separate evidence from different collections. Grouping for a dashboard should not erase that source history.

Treat secret presence and validity as different properties

A nonempty secret field tells you that a value is present in the record. It does not, by itself, tell you whether the value is current, complete or accepted by the associated service.

Keep plaintext, hashed, encrypted and unknown representations distinct where the source supports those distinctions. Do not treat an empty value as proof that the account has no password. It may simply mean the export did not supply one.

If another authorized process supplies a validation result, retain its time and scope separately. Do not turn a historical check into a permanent “active” label or infer successful account access from the presence of plaintext.

Keep the API data and your metrics separate

Webz.io’s Data Breach Detection API brings stealer logs, breach data, combo lists and cookies into a consistent JSON structure. Its product page describes account information, record identifiers, source context and device information where available.

Use the fields your integration actually receives to define the applicable measures. The counting rules in this article are application logic, not a claim that the API returns these exact aggregates or establishes unique people.

Webz.io’s article on ingestion progress and remediation addresses another boundary: saving a record does not resolve its exposure. Keep that operational status outside an observation count so a processing milestone cannot silently change a security metric.

Compare totals only after comparing definitions

Before drawing a trend line, check that both totals use the same filters, grouping rules and time basis. A snapshot of collection activity should not be presented as a timeline of when accounts were compromised.

Test a rule change against the same saved fixture set. Report which groups were merged, split or left unresolved. Keep the earlier calculation available so the reviewer can explain a discontinuity in the chart.

A useful fictional dashboard note is: “Snapshot S-4; four observations; two identified service-account groups; one observation unassigned; credential validity not assessed.” Put those qualifications beside the total.

Correct labels wherever the number travels

Review exports, alert messages and customer reports as well as the dashboard. A precise database field can still become “users breached” when copied into a presentation.

When a definition changes, update the displayed label and calculation version together. Identify earlier reports that used the misleading label and issue a correction with the applicable scope and date.