Most API problems do not show up on day one. They creep in gradually as teams grow, requirements shift and new developers try to make sense of endpoints that made perfect sense six months ago but now feel inconsistent or surprising.
Start With the Consumer, Not the Database
The most common mistake is designing APIs that mirror your database schema. Your database is an internal implementation detail. Your API is a contract with other teams or products. Shape your responses around what callers actually need rather than what is easiest to query.
Consistent Naming Saves Hours of Confusion
Pick one convention and stick to it everywhere. If you use camelCase for one field name, use it for all of them. If your date fields end in At, every date field should end in At. Small inconsistencies compound into big frustrations when a codebase has hundreds of endpoints.
Version From the Start
Adding versioning to an unversioned API after the fact is painful. Set up /api/v1/ from your very first endpoint. When you need to introduce breaking changes, you can roll out /api/v2/ alongside the old version and migrate consumers at their own pace instead of coordinating a big-bang cutover.
Return Useful Errors
A 400 response with the body {"error": "Bad Request"} tells the caller nothing. Include the field that failed validation, why it failed and ideally a hint at what a valid value looks like. Your future self and every developer integrating with your API will thank you.
Conclusion
Good API design is mostly about empathy. Think about what it feels like to be on the other side of the endpoint. If you can answer any question a caller might have just by reading the response, you are on the right track.