Checking user's subscription before any action?

monday Apps & Developers
,
1

Hi,

I am building a client side application for an app idea. It is not a server backed application. It leverages the monday’s Graphql api and does something nice things. I want to monetize it as seat based subscription model not feature based.

The question is, if the monetization type is seat based subscription do I need to check user plan upon team size before using the app? Or does monday do on behalf of me? If monday does not maintain subscription enforcement then I need a server to to store plan selections, right?

What is the best practice here? cc: @Matias.Monday

Thanks in advance.

1 Like
2

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 :smile:

3

Thanks @Matias.Monday,

How can I get the seat number? I have checked the account query but there is no seat number.

4 
{
  account {
    plan {
      max_users
    }
  }
}
5

Hi @codyfrisch,

This gives the max users in that plan. But I need the max users in the team to force the plan selection.

6

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.

7

Hi @codyfrisch,

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.

8

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.

1 Like
9

Hi @codyfrisch,

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

10

@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.

1 Like
11

Hello there @apsimos, you can find more about this here and here :smile:

12

Thanks @dvdsmpsn and @Matias.Monday

13

Happy to help @apsimos !

14

@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.

4 Likes
16

Hello there @codyfrisch,

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

18

Its actually sort of blowing up in some slack threads with something that appears associated with the change in how they are calculated.

19

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 @codyfrisch @dvdsmpsn @apsimos

20

wouldn’t you also want to filter on is_verified = true or is_pending = false too?

1 Like
21

Hi @dipro,

I agree with @codyfrisch. is_verified and is_peding should be filterable.

22

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.