Developers struggle to parse inconsistent API error responses
Developers consuming APIs encounter error responses whose status signals, body formats, or schemas differ from successful responses and from one operation to another. In Angular, some requests can also produce error bodies as blobs even when developers need to read JSON or text. People work around this with per-operation lookup tables, extra parsing, or blob-to-string conversions.
For frontend and API-client developers. Mentioned from Sep 2017 to Jul 2025 on GitHub and Hacker News.
4 different people described this problem in 3 separate discussions.
- Indie fit
- 3.0/10
- Pain
- 4.8/10
- Frequency
- 5.8/10
- Willingness to pay
- 0.0/10
- Momentum
- 5.0/10
- Who pays
- Professionals
- Competition
- Medium
- Build difficulty
- Medium
What people said
Quoted word for word. Follow a link to read the whole discussion.
Building usable error handling with that kind of response is a real pain: there's no single identifier that indicates success/failure status, so we had to build our own lookup table of granular responses specific to each operation
Currently, HttpClient expects the same responseType for both, success responses as well as error responses. This brings up issues when a WEB API returns e. g. JSON but just an (non JSON based) error string in the case of an error
Build brief
See what to build and who will buy it
- 2 product ideas with the smallest useful version and pricing
- 4 places to find your first customers
- 3 more quotes from people who have this problem
- Current workarounds, existing solutions and risks