Is enabling the installation for not-logged-in users a requirement to get an unlisted app approved?

Hi !

We’d like to offer a pipedrive integration to our users and need to chose between developping an app or requesting API keys.

Building an app seems more secure as tokens can be revoked and the app can be uninstalled.

However we only plan to propose the app to our paying user. It makes no sense for us to enable the installation of the app for a non logged-in user (and an unneccessary complication)

Is this workflow required to get the app approval or is it “nice-to-have” ?

Thanks
Bruno

Hi @Bruno,

Welcome to the community! :wave:

Depending on your use case for your app, you may want to choose between creating a public app or an unlisted app. You can read more about types of apps here.

For both public and unlisted apps, you will need to use OAuth 2.0 authentication. It is required to get your app approved. You can read more about our app approval process here.

Apps with API keys are only for internal/private use, meaning for users of the same company within Pipedrive.

I hope this helps? Do let us know if you have further questions. :blush:

Hi

Thanks but my question is more about the “app installation flows” : App installation flows

The following flows seems to be required, event for unlisted apps :

  • A new user to your app
  • The user isn’t logged into your app

But we dont need those workflows for our app, as we will only let paid users access the app

So my question is : are those two workflows mandatory to get the app approved or is the workflow “The user is logged into your app” sufficient ?

Thanks

Bruno

Hi @Bruno
The flows depict different scenarios when the user hits the Install button. It is important to handle all of them. Of course, the steps in each flow outline the bare minimum that needs to be taken care of. Depending on the use case things can be added to it.

For instance, we can’t prevent someone from clicking on the Install button, but if they do, we can decide how we would like to handle that.

In that case, payment subscriptions for new users could be handled in step 2 (represented in bold text)

1* Store the authentication code (e.g., within the session)
2* Direct them to create an account and log in to your service (probably selecting a subscription in your product can be part of this?)
3* Depending on Step 2, Exchange the authentication code for the access token and refresh token
4* Redirect them to a page (or your product) where they can resume the installation/setup

If the user happens to be a non-paying customer, the product can prompt them to select a subscription. Upon successful subscription, they proceed to step 3 / 4. If not, the flow stops at 2 and the install doesn’t happen.

In an alternate scenario, the user can be considered a trialist and the installation succeeds. But in order to use the tool, they need to upgrade their subscription later. As I understand, this scenario is what you’d like to avoid?

Hi @Hem

Thanks for the quick & detailed answer ! :ok_hand:

I understand the requirement but the scenario in which an unknown user clicks on “install” and proceed with registration and subscription is really not relevant in our case.

It adds a lot of complexity for a very unlikely user case.

=> We only plan to show the app installation to our logged-in / paying users (hence the choice of an unlisted app)

From your answer I understand our only option is to go with the API key. Its really not our favorite solution because our users wont benefit from the security layer of the oauth.

Did you consider making the installation workflow for new users optional when building an unlisted app ?

Bruno

Thanks for clarifying the scenario. Having an unlisted app helps in narrowing down the audience. Users who only have the URL can install the app & those users are assumed to possess knowledge of its existence (say, they are already your customers).

Kindly note that unlisted apps will not be shown publicly. The URL has to be shared with the users directly

For such users, when they encounter your product/app login, they will already have an account and they can login + successfully authorize the product/app to access data in Pipedrive. Basically, the flow for A new user to your app and The user isn’t logged into your app would almost be the same as it does not involve account creation. (Kinda implicitly handled :wink: )

As said earlier, the flows are more like scenarios that need to be handled. There could be a scenario where the user hasn’t logged in to your product (or say session expired) and attempts to access it. If your app can handle that (redirect to login, reauthorize, good-to-go), it will ensure that they have a seamless experience at any point in time.

I understand that The user is logged into your app would be a common scenario in your case. I would consider it as a happy path but still, handle the flow where the user hasn’t logged in to ensure continuity.

This is a good question. With unlisted apps, the scenarios vary differently. As long as it is handled and results in a smooth experience, it is good-to-go :slight_smile:

It is recommended to stick to OAuth as it lets you define the level of access (through scopes) and as you rightfully mentioned, is very secure compared to API key.