The lifetime of an API depends less on the code of the first version than on how long older clients keep working. Mobile users may stay on an old app version for months. That makes removing a field, or changing what it means, risky. Adding fields, accepting optional parameters and making breaking changes under a new version path is the safer approach.
Use one consistent error format, for example RFC 9457 (problem details). Apply rate limiting at the entry point, before the application logic runs. Attach a request identifier to every response and log it, so a server log entry can be matched to the error a client reported. These three decisions significantly reduce the cost of fixing a published API later.
Planning a similar project?
We can talk through how the topic in this article applies to your product.
