An API is a promise about how another person will work with your system. The syntax matters, but the deeper product is predictability.
Make the common path obvious
Good defaults let a new user get a useful result with minimal configuration. Advanced options should exist, but they should not crowd the first successful request.
Errors are part of the interface
A status code tells you that something went wrong. A useful error tells you what happened, whether a retry is safe, and what to change. Treat errors as documentation generated at the moment of need.
Design for change
Versioning is important, but compatibility is better. Add fields without breaking old clients, make operations idempotent where possible, and publish examples that reflect real production use.
When an API feels calm, it is usually because someone did a great deal of thinking before the user arrived.