Most API design advice is about the happy path. Real APIs live and die on the details: what happens when a field is missing, when a rate limit is hit, when a caller passes the wrong type.
Here's the short list of things we insist on.
Version the URL from day one. /v1/ looks like ceremony until you need to change a response shape for fifty clients. Then it's survival.
Make errors structured and boring. A consistent envelope - the same fields, the same shape, whether the error is a 400 or a 500 - means your clients can write one error handler and be done. Creative error formats are a tax on everyone who follows.
Never expose internal IDs. They couple your API to your database, and changing a primary key strategy becomes a breaking change.
Paginate everything, even when you think you're small. The caller who only needs ten rows today will need ten thousand next year, and retrofitting pagination is a breaking change.
Document with examples, not descriptions. A wall of field definitions teaches nothing. Two copy-pasteable examples teach everything.
An API that ages well is boring on purpose. It surprises nobody. That's the compliment.