An Empty Array Is Not Proof That a Vehicle Has No Fines

Imagine checking a used car before buying it. The page returns zero traffic fines. Three sources answered successfully; a fourth timed out. If the interface presents one reassuring green total, it has quietly converted a technical failure into a claim about the car. The database may be available, the API may return HTTP 200, and the JSON may be valid. The answer can still be misleading. This is a design problem for any product that aggregates records from independent sources: the response must describe what was observed and what remains unknown. Disclosure: I am Enrique Orione, founder of multas.ar, an Argentine platform for traffic-fine lookup and notifications for individuals, with an API and fleet-management tools for businesses. The following is a proposed design pattern, not a report of a particular production incident or a claim about nationwide coverage. All examples are hypothetical. Separate the source outcome from the records An array answers one question: which records did this response contain? It cannot, by itself, explain whether the query completed, whether the source was covered, or how old the information is. A response contract should carry those facts separately. For each source, consider four explicit outcomes: completed with records, completed without records, unavailable, and not queried. Give unavailable results a reason such as timeout, temporary outage, access challenge, or an unrecognized response format. A successful empty result should be possible only after the integration recognizes and validates the source's response. Keep the requested identifier, source identifier, observation time, and outcome together. If a cached result is shown, retain the original observation time and identify it as cached. A new HTTP response does not make an older observation fresh. Make completeness a separate decision Suppose a query is configured to check four sources. Source A returns two records. Sources B and C complete without records. Source D times out. The aggregate contains two observed records and one unresolved source. It should remain partial even if every returned record is valid. Calculate completeness against an explicit set of intended sources for that query. Otherwise, silently removing a failing source from the denominator can make a result appear complete. Coverage is another dimension: completing every configured query does not prove that every possible jurisdiction was checked. A useful consumer message could say: Two records found in the sources checked; one source could not be checked. A fleet dashboard can expose the same information as completed-source counts, unresolved sources, and timestamps. Both presentations should come from the same result contract. Retry the missing work without changing the meaning A retry should resolve an unknown result rather than erase the original observation. Record which source and query the retry belongs to, then replace that source's outcome only when a newer attempt produces a valid result. A second timeout is still unknown. Limit retries and make retryability explicit. A temporary network failure and an access challenge need different handling. An access challenge may require an approved interaction or manual review; it is not evidence that the vehicle has no records. Repeated automatic attempts should not become a way to evade a source's access controls. Notifications need the same discipline. When a record is absent from an incomplete refresh, that absence alone should not trigger a message saying it has been paid or removed. Retain the last confirmed observation and communicate an unresolved refresh separately. Preserve provenance while normalizing Aggregators often need to normalize dates, currencies, and status labels. Keep the source's original status alongside the normalized value. A mapping should have a documented meaning; an unfamiliar status belongs in an explicit unknown state until the integration understands it. Deduplication deserves equal care. Two records with the same amount and date are not necessarily the same fine. Prefer stable source identifiers when available, retain where each observation came from, and avoid merging records merely because they look similar. Financial totals should state which records and statuses they include. Test the reassurance, not just the response The important tests cover combinations: all sources complete with no records; one source fails while the others are empty; one source fails while another returns records; a cached observation is displayed; and a previously recognized format changes. The partial-empty case is especially useful because it catches the tempting shortcut of turning every empty array into a green success. Monitor source completion and response-format failures separately from application uptime. A system can serve requests reliably while one integration stops producing trustworthy observations. Logs and metrics can track source outcomes without exposing full license plates, personal identifiers, or response documents. The product promise should match the evidence available to the user. A driver deciding whether to investigate a used car and an operator monitoring a fleet both need a clear boundary between checked, found, and unknown. That boundary belongs in the API contract before it becomes a color in the interface. This article was drafted with AI assistance. It contains no claimed customer outcomes, legal guarantees, or invented founder anecdotes.