Using/Storage tokens for multi-user app

Hello, I have a question, I’m working on an application for the Pipedrive Marketplace, and this is my first experience in developing such an application, so I wanted to ask you a few questions, ask for help.

My application has an integration with Ukrainian scoring service, and I need it to work in background all the time with webhooks. And I did this task, but only with api key, and for multiuser application I need to use 0auth2 authorization.

I read about it in your documentation and did everything based on your examples, but I have a problem.

  1. When I use access token to create the fields in the organization everything goes smoothly, the fields are created.

But when I try to update these fields with webhook, I get error “Error: OAuth 2 property refreshToken is not set.”, although again no such thing when creating.

  1. Another question, I understand storing access tokens in client cookies is not the best choice for multi-user application, would it be better to store them in the database?

  2. And lastly, what is the best way to update the access token in the background, without going directly to the site itself, so that the application always has the opportunity to give what the user needs

1 Like

Hi @Sergii_Rubicon
Welcome to the community :slight_smile: Some excellent points I see there! Will answer them individually

Could you tell me if you are making the API calls directly or via the Node Client library? It seems like the call was made from the client library, but please confirm. In some instances, the library would try to refresh the token automatically, and that might result in such an error (esp, when refresh token is not passed).

Also, which endpoint are you using to update the fields? I assume that you making the changes based on the webhook events?

The safest approach would be to maintain them in the database. However, the access tokens generated are short-lived (1h). If you use Custom UI extensions and basic scopes and want to have some stateless session, storing access tokens in secure cookies should be fine. But I would only recommend this if the app runs within Pipedrive or in a secure context and does not have access to admin-level scopes.

This is a very good question. The official SDKs have an inbuilt mechanism to refresh the tokens based on the refresh token. If you are not depending on the SDK, you might have to either periodically refresh the tokens or refresh them on an ad-hoc basis based on the last refresh time.

Unfortunately, there isn’t a way right now to create long-lived tokens. I realize that this would be an important use-case for background syncs. Perhaps I can get more visibility into that by making sure the Product and Engineering knows about this

1 Like

Thanks for the reply Hem.

Could you tell me if you are making the API calls directly or via the Node Client library? It seems like the call was made from the client library, but please confirm. In some instances, the library would try to refresh the token automatically, and that might result in such an error (esp, when refresh token is not passed).

Yes, I use the library for Node js, and use the data obtained from the webhook when changing, after processing the data I call 2 methods, this new (new pipedrive.OrganizationFieldsApi, new pipedrive.NotesApi) and from them I get an error

The safest approach would be to maintain them in the database. However, the access tokens generated are short-lived (1h). If you use Custom UI extensions and basic scopes and want to have some stateless session, storing access tokens in secure cookies should be fine. But I would only recommend this if the app runs within Pipedrive or in a secure context and does not have access to admin-level scopes.

I was thinking to apply the following case, save the access token in the browser cookie of the user himself, since my application will not have access as an administrator, but also duplicate it in the database, already together with the refresh token, and update the access at each request from the webhook

This is a very good question. The official SDKs have an inbuilt mechanism to refresh the tokens based on the refresh token. If you are not depending on the SDK, you might have to either periodically refresh the tokens or refresh them on an ad-hoc basis based on the last refresh time.
Unfortunately, there isn’t a way right now to create long-lived tokens. I realize that this would be an important use-case for background syncs. Perhaps I can get more visibility into that by making sure the Product and Engineering knows about this

I wanted to refresh the tokens every time I requested a webhook, but I know this can only be done for 60 days, as long as the refresh token is alive, and then the user has to visit the site to get a new pair of keys, or is there a way that this may not be necessary?

And one more question, probably silly, but still
ClientId, ClientSecret in the settings of my application, will they be static for all clients, or will I need to apply some method to get these parameters after installation?

This topic was automatically closed after 10 days. New replies are no longer allowed.