TL;DR: JUST DO IT.
Other answers somewhat touch on it, but they aren't quite clearly identifying what the real deciding factor is.
Where is the risk? What is at risk?
Where is the risk?
Assuming your API doesn't have a vulnerability,
the real risk case is when an admin leaves their PC open while they grab coffee.
Someone could make some changes and no one would know who did it. They will at least know WHAT was done, if it's logged properly.
What is at risk?
If the admin can set the user password, then you are risking that in the above attack, someone could gain access to someone else's account and impersonate them. The above attack leaves users open to identity theft, with whatever powers you grant users, plus whatever information you store for them.
Decision
Prompting for a password is an easy to implement fix to the where.
Given the simplicity, it's hard to think of any scenario where it isn't worth implementing.
But don't stop there.
Evaluate your other risks--in the above attack, is there anything else that an attacker could change in order to gain something? If there is, a password should be required for any of those changes too.
Examples:
- Changes in permissions for users. Can an attacker give them self access to new data?
- Changes in functions. Can an attacker break your site, especially in a way that might not be noticed easily? (Disable a particular web page, turn off a webhook, etc)