[CAL-1794] Allow admin API Key CRUD operation on all resources

[PhilippFr]

I've found several API routes that will only allow operations on resources of the creator of the used API key, despite him having the ADMIN role. We expect an admins API key to do all CRUD operation on all API endpoints without restriction.

This is quite a problem for our current project and it seems to affect multiples routes and methods. Here are some routes I've found that are affected by this issue:

• PATCH /v1/users/:id
• GET /v1/memberships
• GET /v1/schedules
• GET /v1/availabilities

This list is by no means comprehensive, I've only tried some APIs and this issue seems to be spread across them.

_CAL-1794

[PeerRich]

thank you! @agustif will investigate

[agustif]

Yes @PhilippFr, thank you for opening the issue, will be working on shipping all the admin endpoints this week

[PhilippFr]

@agustif Has this not been fixed in release v1.8.0? I'm still experiencing this same behavior.

[ayushman-kc]

@agustif any ETA on when we can expect this to be shipped?

[nckhell]

Hi @PeerRich @hariombalhara ,

Do you happen to have an idea when admin or team-level API keys would make it to cal.com? We have a use case where the team admin should be able to retrieve the booking details of all the team members - not necessarily in the GUI, but via the API. Because API keys are scoped to the user, it currently returns an Unauthorized error. Any help would be welcome!

FYI: we have built a Cal.com extension within our platform and our customers are loving it (we always refer our customers to you if they need patient scheduling). However, the current limitation severely limits the # of use cases they can currently tackle with the extension.

cc @rahulkeerthi

[mreilly-lula]

Adding here, this feature would be very helpful. thank you!

[supalarry]

After going through the API endpoints we can say that:

1. Ever since this issue was created there have been refactors to enable admins to perform CRUD operations on behalf of other users. For example, in this commit “/memberships” endpoint was updated and similarly other endpoints.

2. The only endpoints without admin CRUD logic are:

• POST “/teams”
• “/payments”

3. PR #12794 will enable admins to make POST requests to the “/teams” endpoint to create teams on behalf of other users. Admins always have to provide “ownerId” in the request body to do that. “/payments” requires larger discussion about maybe including payment information in bookings themselves returned by the “/bookings” endpoint.

If you discover an endpoint where an admin can’t perform something on behalf of another user, please let us know, and I will fix it ASAP.

Cheers!