Hello there @apsimos,
You need to check the account’s seats and plan on your end and you don’t need backend for it. You can use the SDK/API for it 😀
Thanks @Matias.Monday,
How can I get the seat number? I have checked the account query but there is no seat number.
{
account {
plan {
max_users
}
}
}
Hi @anon29275264,
This gives the max users in that plan. But I need the max users in the team to force the plan selection.
That is the max users in the monday.com account plan, that the account has purchased, and is the number used when they purchase a seat base plan to your app in the marketplace.
Hi @anon29275264,
I am little bit confused. Let’s say the plan’s max user capacity is 20. And then account’s team size is getting increased, say it is 21. As far as I understand the account needs to be subscribe to the next plan which starts with 21 seat. Am I wrong? So in order to compare I think I need the current team size.
max_users is the number of monday.com licenses that the account has purchased. If they have 20 and increase to 21, they must purchase another monday.com license. They do that, and max_users now increases. But maybe they have purchased 25 users but only have 20 active - they still have a max_users of 25.
When they go to the marketplace to purchase your app, they are presented the plan which encompasses their current max_users.
You then compare their subscription plan against the account.plan.max_users and if the max_users is above the subscription plan you can choose to restrict access (or maybe a grace period for them to upgrade?) or display a prompt to upgrade their plan for your app.
Monday bases the app subscription on the licenses purchased, not the currently in use seats.
Hi @anon29275264,
Thank you for this long explanation. I could not able to find a documentation that stresses these things. This is why I am confused. Is there any documentation that I can dig deeper? cc: @Matias.Monday
@apsimos You’ll need to add the account:read OAuth scope to your app to run that query.
Also, get a bit more information…
{
account {
plan {
version
max_users
}
}
}
Also get the version of the plan, because if you update the plan, currently existing accounts will remain on the old plan.
And consider some weirdness in the max_users when using webhooks.
Hello there @apsimos, you can find more about this here and here 😀
@Matias.Monday With the switch to subscriptions being sold on active users not max users I see the potential for the {account {plan{max_users}}} (which is the account plan not app plan correct?) being higher than the app tiers max user count - how are we to check this now, so that we don’t cut off accounts that monday put on an appropriate plan?
PS. I think switching to active users was the right choice, but it seems like communicating to us any changes needed, as well as ensuring we can retrieve the active user count from the API was missed.
Hello there @anon29275264,
That is a good point and I have taken this with the monetization team.
I will come back here as soon as I have an update!
Cheers,
Matias
Its actually sort of blowing up in some slack threads with something that appears associated with the change in how they are calculated.
Firstly, I’d like to apologize for the miscommunication (or rather lack of communication) here.
Please do not use the max_users field on the account object! It will not give you an accurate count since we don’t consider guests or view-only users in app pricing. The field is also null for trial/free accounts, which makes it limited in its helpfulness…
Instead, you need to query the users object via API and count the number of users that are not guests or view_only.
{
users (non_active:false, limit:100) {
id
name
is_verified
is_guest
is_view_only
is_pending
}
}
I know this is a bit of work and so we’re investigating if we can expose this number via API. Will update here once we firm up our plans for it.
FYI @anon29275264 @dvdsmpsn @apsimos
wouldn’t you also want to filter on is_verified = true or is_pending = false too?
Hi @dipro,
I agree with @anon29275264. is_verified and is_peding should be filterable.
Well I meant we’d need to filter them on our side, arguments for the API don’t exist for this. I was just calling out for everyone we’d probably need to exclude pending accounts that aren’t in use. But I don’t know that for a fact because I don’t know how they filter for the active user count used to determine the plan.
I don’t expect any native API method for this until July at the earliest.
Then we need to retrieve all users from the server which is not good.
That is what it appears to be at this time. The app would also have to have the users:read scope for the token in question too.
I think @anon29275264 is right. It makes sense. This solution is straightforward and seamless. Downloading all users for each load and doing calculation based on users count is anti-pattern and costy I think. Besides, it requires users:read scope which contains PII data.
@dipro and @Matias.Monday I have another question. The app_subscription query is returning an array. How many records it returns and how can I decide which is the current one?
query{
app_subscription{
days_left
is_trial
plan_id
renewal_date
}
}
Hello everyone!
Our team is working on a solution for this as we speak. I will of course keep you posted!
@apsimos app_subscription will return an array with one object only.
Heads up, we will expose the number of active users on an account via the API next week.
So you will not have to query the list of users on the account. Current plan is to expose it as a field on the Account object.
I’ll share an update here when it’s deployed!
Quick note about scopes – before the change in how we count users, apps would use Account > Plan > Max Users to get the number of users. So this API update will not require additional scopes @anon29275264
@apsimos @anon29275264
