I've broken a lot of APIs. I've also built a few that I later had to apologize for at standup. After years of doing both, I have opinions — strong ones — about what separates an API people want to use from one that becomes the subject of a passive-aggressive Slack message at 11 PM. This isn't a textbook. It's the stuff I wish someone had handed me before I spent three days debugging a system that returned 200 OK for every error. Let's get into it. The One Thing Nobody Talks About: Design for the Consumer, Not the Database Here's the mistake most backend developers make — and I made it too. You look at your database schema, and you basically mirror it into your API. One table, one endpoint. Feels clean. Feels logical. It's wrong. Your API is not a database interface. It's a product. The person calling it doesn't care that you store users and profiles in separate tables.…