Case 001
Open Brewery DB's documentation is accurate. We are publishing that unchanged — including the false positive our own tool produced first, and how it was caught before it would have reached a client.
11 / 11 verified · 0 defects
Every documented call executed against the live API. Every one of the 16 documented response fields checked for presence and for the exact type the docs state.
longitude and latitude are documented as number or null — a field pair where APIs very often return strings instead. Theirs return numbers, exactly as written.
/breweries/meta documents its query parameters but has no response-fields table. The shape it returns — total, by_state, by_country, by_type, page, per_page — is undocumented.
That is not a defect in anything they claim. It is a gap in what they claim. A developer integrating against it is reading the JSON to find out.
Our first run reported three defects: total, page and per_page returning numbers where the docs said string.
That finding was false. Manual verification showed the docs specify no response fields for that endpoint at all. The string types existed only in our own contract. We had invented a claim, then reported the API for failing to meet it.
This is exactly the failure this service exists to prevent, committed by the service itself on its first run. It is also why no finding reaches a client without manual verification against the vendor's own published words. The tool proposes; a person disposes. We caught it in minutes because that rule was already in place — and it is in this case study because a verification company that hides its own errors is selling something it does not practise.