Hello Team On the docs of

/booking

request, there is a query params called

attendeeEmails

, however when i used it in the booking, it dosen't seem to work

It should be attendeeEmail and not attendeeEmails.

Okay great, it works now

@Ali possible to create a bug ticket to fix the docs to reflect this?

@John K it's already fixed and merged to main, the next release should see it reflect in the docs 🙏

@Ali, How can we filter by userId? The userId parameter is not working

the userId parameter is a Admin-only filtering method. This doesn't work for non-admin calls, because you will not get access to bookings of multiple hosts unless you're an admin.

@Ali I am using the Admin-only account to filter

That's weird. Let me test this on my end 🙏

Hello @Ali, I made get request to see all users in my company. There is only one user with role of

USER

, is there a way I can make the user and

ADMIN

, shouldn't it be admin by default?

If you are self-hosting, you can make any user an Admin by modifying it in the DB directly using prisma studio (

yarn prisma db-studio

) and then they can make these requests. However, if you're on Cal.com cloud, you can't become an Admin as it becomes a privacy concern. If you're a team on Cal.com cloud, we are working on a team level Admin AFAIK, but it'll be some time before it becomes available via API

Okay, understood

@Ali?? so let me get this straight • we cannot query by id through the BE without being an “admin” even though this is our account with our api key • this is because of “privacy” concerns, even though we can query ALL bookings which includes userId in the response please explain how this makes sense, and how this is not expected to be a core part of Cal’s product and a common usecase for sure?

Hey @John K Here's what I mean: 1. If you're an Admin on Cal.com cloud, you can retrieve information of any user on our Cloud by using their id. If we wish to restrict it to your "team" on Cal.com cloud (I'm assuming you have a team account with us), we'd need to allow admin calls via Team API keys, which as I mentioned is something we're working on. 2. You can't get bookings of all users without an Admin API key. The bookings you get are through your userId alone, unless it is an API key.

we cannot query by id through the BE without being an “admin” even though this is our account with our api key

You can't query by "userId" not "id". id here means booking id, which you can obviously query using your non-admin API key.

this is because of “privacy” concerns, even though we can query ALL bookings which includes userId in the response

The userId included in the bookings list is yours. Yes, this is a privacy thing along with authorization. And we can't give away Admin API keys on Cal.com cloud as the potential to harm is immense, while there is no way for us to regulate it yet. I hope this clarifies it for you! If there's anything more I can help you with, please feel free to let me know 🙏

is data not partitioned or restricted for each account by default? if not, then that is the source of the security concern. our usecase is to query a user’s bookings. a user created by us, who’s id we store in our own db. we may have many users. is there no way to do this without the team’s feature presently or in the future? this forces us to filter on the client which is not an option. this has to be a pretty common utilization of your product right? that is, your clients don’t want to fork or write scheduling logic themselves, nor want to store this data in its entirety themselves, but want to be able to access the data they create. obviously not every feature is going to be there, but this seems like the a use case among the first to be developed

is data not partitioned or restricted for each account by default?

if not, then that is the source of the security concern.

Data is restricted for each account hence you can't access it unless you have an Admin API key, or you're querying your own account. I fail to see how that's a source of security concern when you can't access an account you're not authorized to. If you have created a user, you can create an API key for that user and use that to fetch details for the same. You can pretty much do all of that.

this forces us to filter on the client which is not an option.

You are not going to get any bookings of users other than yourself, what are you trying to filter when the bookings list will not contain any other user? 🤔 You would need to fetch bookings of each user individually.

this has to be a pretty common utilization of your product right?

that is, your clients don’t want to fork or write scheduling logic themselves, nor want to store this data in its entirety themselves, but want to be able to access the data they create. obviously not every feature is going to be there, but this seems like the a use case among the first to be developed

This hasn't been requested yet, believe it or not, or it would have been prioritized over tons of features we've shipped which were requested. 🙂 But, as I said, we are working on it and would prioritize it if we get enough requests for the same. There are easy workarounds for pretty much all use-cases you mentioned. You can potentially store API Key for each user against their Ids that you store in your DB, and use the API keys instead of the Ids when querying. That should be fairly straightforward and doesn't authorize you to use an account you shouldn't have access to.