sometimes I have added the reason, sometimes not, following what I have seen in other endpoints

Thank you for the changes. The "how we do it in other places" might not be such a good guidance. Here some more thoughts:

• An admin should be able to spot the cause of errors by using the Admin UI and the recorded events
• The information and details we provide to the caller are sometimes redacted for security reasons, as we don't want to provide too much information that can be used as OSINT
• The admin should receive the same information, and ideally enough information to make it actionable to fix the problem.

I've pushed one more change, please let me know your thoughts. I've added the same message returned to the caller in the details, although it might be redundant to the error code. I reduced the content that is already in the event in another place, and added details also to the InstantiationException.

Please let me know your thoughts.

@ahus1 LGTM! Then the idea is always adding the details instead of any logger. I tried to do the same that it was done in other parts. 😝