How can I make app_subscription calls 'within the context of an application'

Newbie question here: I am using Postman to query the app_subscription API for subscriptions to our DocuGen app:

The documentation mentions that “you can only make this call within the context of an application, not from our API Playground”. How can I do this in Postman? Where can I get the API token for this?

Thank you all in advance!

You’d need to do the oauth process through postman to get an oauth token, postman supports oauth as an authentication type for a collection. You’d also need to add the callback url postman creates to your app as a valid callback URL.

I’ve done this before, but to be honest, its been over a year so I don’t remember all of the specifics.

The other thing, is the app subscription returned is JUST for the account that you used creating the token. There is not currently a way to return the subscription with the app installs or for other accounts (I’ve asked for this because its just dumb that we have zero method to look up all subscriptions going on 2 years after monetization became a thing.)

2 Likes

Thank you very much @codyfrisch !

Say we have 500 customers, some of which are active (paying) and some are churned. If I understand you correctly, we have to get 500 different tokens and run 500 separate queries to get the full list of subscriptions? This doesn’t sound right…

Yet it is right.

The only way to query an accunts subscription is with a token for the that app and account, or in the context of your UI.

So you could embed code in your UI that checks it, and sends it back to your backend.

If you got an OAuth token when a view was created on a board, or integration recipe was added, you can use that stored token.

If you have integrations, they send a short lived token you can use to look it up and store it when the integration runs.

There is currently, at least thats gotten published, no way to query all app installs for their subscription information. When they announced the app_installs API query, I asked them about the subscription and they said they’d add it to the feature requests.

Yes I am as baffled as you that we as developers have zero solid method to query subscription data for accounts - except if we’ve stored an OAuth token in our backend, query for app_installs, then iterate those to find tokens for each account and make a query on an per account basis.

And if the account uninstalled the app, then your tokens are void, so it will fail - and you have to assume uninstalled that missed getting recorded from the webhook.

I presume you’re receiving lifecycle webhooks which should send you all account changes, subscription renewals, etc. that you can then store the last known state into your database?

Spot on – you feel my pain! The bottom line is that there is no way to get a definitive list of our customers at any point in time. We need to piece together a puzzle of tokens, last known states, and a good bit of good luck :slight_smile:

I’ve had pretty good luck with the lifecycle webhooks, though not perfect, they at least do send events for all the subscriptions and churn now days. Assuming there isn’t an error.

Since the app I work on is strictly an integration app, I get the subscription data for the account ID with every event. Since I have to get the record thats stored in anyway, I make a comparison at runtime and if there is a discrepancy I update the record.

(Thats a simplification, I’m doing a whole lot more but its not relevant to the general discussion)

+1 on this.
I’ve already submitted this request to monday devs several months ago.
Currently there’s no way to check what’s the subscription situation for an account outside of our apps.

1 Like

I’m baffled why it seemed a good idea to release app_installs in 2024-01 without including subscriptions. Seems like dev teams with tunnel vision to me.