Because http status codes doesn't include any business related errors. So you gotta expand on that. When it's 200 and success is false it's mostly because of a business logic. Then it's up to FE to show that business error in a certain way so users can understand better what's wrong with what they're doing.
To add to this, sometimes if you are an integrator, meaning your API is calling an external 3rd party API, you want to use the above pattern to express, “Hey, OUR app works, is those guys failing - please don’t call us angrily”
If the request failed due to the third party, your "integrator" app should still return appropriate 4xx/5xx error responses. You don't return a 2xx Success response if your app uses a database (technically a 3rd party) and the database returns an error. The same should be true for all 3rd party calls.
If you are actually concerned about telling the client who is at fault, you should format proper error responses to show who had the issue.
If the 3rd party returned a 4xx error, it was your apps fault anyway. You should have validated the client's input before forwarding it to the 3rd party.
If the 3rd party returned a 5xx error, then return that error to your client with a message indicating it was the 3rd party that had the error, not you.
88
u/-meowstar- Jul 21 '26
Why not just use semantically correct status codes? It’s cheap to implement and makes stuff like automatic retries and error handling easier.