This comment is very relevant.
It is only an internal API. The argument of the consumers is that they will ask me to support the age field ans want to start changing their app and send that field before the API was updated. Although I understand the urgency I don't like that approach.
There is nothing wrong with having a planned API change and your endpoint being forwards compatible.
It is especially useful when you already know the change is coming and the client is hard to change (e.g. a mobile app typically has a longer release cycle than web service).
Make sure that the semantics of the API are loosely defined and client doesn't make any assumptions.
E.g. the semantics could "I want to register someone to an event, here is everything I know about them, do what you want with that data." and the service defines the details (whether to only the name or both the name and the age).
Imagine you already know the age in the client and are planning to use ages in the future on your service and make it mandatory, but don't have time to implement the backend feature right now.
You would have to do multiple steps:
- Deploy the backend service with v2.0 (without age) of the API.
- Deploy the client with v2.0 of the API
- Deploy the backend service with v2.1 (with age), have a feature that allows you to make the presence of the age field mandatory
- Deploy all the clients using v2.1 of the API (many users don't update apps immediately or even within years).
- Turn on the feature to make age field mandatory.
Now look at the scenario where you do send ages from the beginning:
- Deploy the service with a forward compatible API v2.0 or use v2.1 already but ignore the "name" field.
- Deploy the app the users, using v2.1 of the API
- Deploy a new version of the service using the age field.
Software is there to be useful for the users. Software principles should serve your users and not serve themselves. Don't make then stand in the way of having a good user experience, without a strong reason.