The simple rule for API evolution is, that the externally observable behavior of an API (from the perspective of the clients) cannot be changed, once the API has been published. Already a small change of the API might break some of the clients consuming the API. It is impossible to update all the consumers or at least unrealistic, since they are under control of different owners. Thus, longevity and stability are important aspects of published APIs.
The restriction imposed by this rule might sound severe and even counter-intuitive, since APIs are often developed using an agile development approach. Agile approaches are based on feedback loops and the idea of many incremental changes of the software. The agile development approach still applies to new or unpublished APIs.
Before the publication of the API, any change can be implemented in an agile manner. As soon as the API is published, however, the game changes. When APIs are published, they become available for consumers and it has to be assumed that the consumers build apps relying on the APIs. Published APIs cannot be changed in an agile manner. At least, APIs need to stay backward- (and forward-) compatible, so that old clients do not break and new clients can use the new and improved features.