PLEASE don’t do this especially when your API is supposed to be RESTful. In REST, the HTTP status is what determines if there’s an error. 2xx - Good 4xx - User fault 5xx - Our fault. I’ve seen you’ve mentioned @supabase does this. Last I checked Supabase is a BaaS not a standards committee. If your API uses REST and you want a structured response that can transfer across teams, use JSON:API jsonapi.org/
Kartik
 @kartik_builds
Nov 6
Update your API response format now 🙏🙏

Nov 6, 2025 · 8:40 PM UTC

101
48
29
1,445
Replying to @StanleyMasinde_ @supabase
You are wrong. This is absolutely acceptable. What if you requested 3 items and one is not found? What do you return? What if you processed a csv and a single row had an error?
12
1
62
“You are wrong” Did you read my tweet? Where did I say it’s unacceptable? You missed a whole line where I specified RESTful. If there’s an error that’s 500 If something is not found that’s 404. Stop creating imaginary problems in your head and focus!!!!
9
179
more replies
Replying to @StanleyMasinde_ @supabase
I did this as a young fledgling engineer. regretted it deeply
3
2
Replying to @StanleyMasinde_ @supabase
The right way is do both. You shouldnt return two different schemas. 400 response with the error field populated. 200 response with the data field populated. It makes the response schema generic regardless of case. Statically typed clients and downstream systems will thank you
2
1
48
Replying to @StanleyMasinde_ @supabase
You can still use proper status codes for auth failures and malformed requests. Business logic failures can be 200 + success: false with enriched errors for the client. The goal is that no one is guessing on the receiving side of the request if there's a failure.
13
Replying to @StanleyMasinde_ @supabase
This does not replaces the status codes sir, why isn’t that obvious to you
2
Replying to @StanleyMasinde_ @supabase
Pragmatic > Dogmatic. It’s fine. HTTP status code is not descriptive enough to provide specific error details. It’s cleaner to have a single API response spec than one that is dependent on status code. The objections to this are just REST dogma.
1
1
Replying to @StanleyMasinde_ @supabase
What I tend to see 200 : Nothing unexpected happened, but check details inside for details 500 : Dunno..., let me check a sec... 🤣🤣🤦
3
Replying to @StanleyMasinde_ @supabase
All apps are RESTish, no one I saw really follows the standard. At the end of the day, build the api the way its easiest and most maintainable.
1
Replying to @StanleyMasinde_ @supabase
Different use cases for both. If a payload succeeds transport, but certain data fails a validation rule or business logic, then embedded errors make sense. Returning 4xx/5xx errors should be consistent with standards, e.g. unauthorized, server issues, network, etc. only.
3
Replying to @StanleyMasinde_ @supabase
Yo, totally feel the pain of bad dev practices. If you're too busy for the social media grind because of stuff like this, endlessposts.com learns your voice and posts for you daily.

EndlessPosts - 10x Your Social Media Output

Post 10x more without burning out. AI learns your voice, curates from your sources, and helps you stay consistent on Twitter/X and LinkedIn. Grow your audience, not your workload.

endlessposts.com
2
Replying to @StanleyMasinde_ @supabase
I've seen like 2 REST APIs in my life, the rest just claim to be
Replying to @StanleyMasinde_ @supabase
What if it's good and there is an error?
Replying to @StanleyMasinde_ @supabase
You can use Problem Details, which is more or less what it's trying to solve.
Replying to @StanleyMasinde_ @supabase
Could fight myself to not go into that discussion yesterday. Thanks for your tweet, I totally agree and appreciate it
1
Replying to @StanleyMasinde_ @supabase
Not that big of an issue. You can do both
4
Replying to @StanleyMasinde_ @supabase
I get a lot of 418s this early in the morning and I don't know why.
Replying to @StanleyMasinde_ @supabase
I use error and http status codes so I can easily debug
Replying to @StanleyMasinde_ @supabase
JSON:API is my default now when building APIs. Good stuff!
Replying to @StanleyMasinde_ @supabase
That 401 was my fault however.
Replying to @StanleyMasinde_ @supabase
Last few weeks I'm migrating a project from using the `data.attributes.whatsoever` to the `data.whatsoeverbutnicer`. Much better. Flat style. I like
Replying to @StanleyMasinde_ @supabase
What about third party fault? That's why you need the success flag sometimes
2
Replying to @StanleyMasinde_ @supabase
Nothing in the OP’s tweet precludes also using the HTTP status codes. IDK why this is so triggering!
3
Replying to @StanleyMasinde_ @supabase
Facts 3xx - it’s in another castle 🏰
1
Replying to @StanleyMasinde_ @supabase
somewhere a junior just learned what 418 means and is abusing it
Replying to @StanleyMasinde_ @supabase
in axios react with the guy you will have to use response.data.data no try catch
3
6
Replying to @StanleyMasinde_ @supabase
Which http code should I use for a validation error on one of my grid lines while saving?
2
1
Replying to @StanleyMasinde_ @supabase
I'm not sure what to do with 404 on this case: There is an endpoint for retrieving books. The "user" (the UI) asks for /books/458 and that book became recently unavailable. Would you response 404 the same as if the "user" asks for a WRONG url like /booooks/458? thnks in adv!
1
Replying to @StanleyMasinde_ @supabase
who gives a fuck about the transport layer. what if u want to make your rest api available over something not http? do you design a completely new thing?
6
1
20
Replying to @StanleyMasinde_ @supabase
I've seen teams asked backend teams to do this because they don't understand Sum type, or the HTTP client library/framework they're using doesn't support Sum type to unmarshall the response. not a problem if you use a proper RFC framework, or follow standards like RFC9457.
Replying to @StanleyMasinde_ @supabase
REST isn’t “status codes = truth.” That’s just HTTP semantics. Real-world APIs use consistent JSON envelopes because proxies, gateways, and edge cases make status codes alone unreliable.
20
Replying to @StanleyMasinde_ @supabase
If it is consistent across all endpoints and your client then everything else is secondary. But ideally don’t have success as a binary (it has at least 4 states and cannot be reduced to t/f)
Replying to @StanleyMasinde_ @supabase
How do you handle and distinguish between an actual communication issue by the http protocol, and the business operation results? You are extrapolating two completely different things on one.
1
Load more