Uh oh! - You do not have the correct role to grant these permissions. Please contact your administrator



I am developing a web app in Node JS and I am getting an odd error with one of my test accounts. What I am expecting is the user will hit the token router and be redirect to HubSpot where they will be prompted to grant access:

router.get('/token', (req, res, next) => {
        client_id: process.env.HUBSPOT_CLIENT_ID,
        scopes: 'oauth contacts',
        redirect_uri: process.env.HUBSPOT_CALLBACK_URL

FYI: I am also using a Javascript / node.js wrapper for the HubSpot API which can be found here.

However I am seeing the following error instead of grant access:

My account worked fine ... I have the same role as this user. The only difference that I can see is under their Contacts tab ... the View / Edit has "Unassigned" unchecked.


I need the app to work with the "Unassigned" unchecked. When I looked at the console the only error I see is:

Failed to load resource: the server responded with a status of 403 ()


Hi @Dev-Sell-On,

In order to install an app, the user must be an admin and have access to the tools that the app requires. A user without edit permissions won't be able to install the app in a portal; they would need an admin to authorize the app. After the app is installed, it's still possible for the first user (without admin privileges) to take advantage of the app's functionality.


Hi Derek,

Would there be any way we could talk over the phone? You stated:

A user without edit permissions won't be able to install the app in a portal; they would need an admin to authorize the app.

When I log-in to the portal with an Admin account I can see the integration is installed ... or am I not looking in the correct spot?


Hi @Dev-Sell-On,

I'm not really able to arrange calls; if we can't find a resolution here we can move the conversation to direct messaging and work something out.

You're correct that if the installation is appearing in the portal's integrations page, then the OAuth flow was completed successfully. The specifics here are really important; whether or not a particular user can install a particular integration depends both on the scopes being required and by the user's permissions. If you can give me your full authorization URL and a specific Hub ID and user email, I can check whether or not that user would be able to authorize an integration.

As a separate note, the permissions required to authorize an integration do not reflect the permissions required to use the integration. For example; if an integration requires the HubDB scope to function, the user authorizing the integration must be a HubDB admin. Once the integration is installed, however, users who are not HubDB admins could still take advantage of the integration's functionality.


Hi Derek,

Sorry for the big delay in my response.

Authorization URL:

Hub ID:

User Email:


Hi @Dev-Sell-On,

No worries at all. I checked out that particular user's permissions, and it looks like they can only edit contacts that they own. In order to authorize an integration that requires the contacts scope, a user has to have full view/edit permissions (i.e. all contacts, not just owned contacts). This is because an integration that has access to the contacts scope can read/write to contacts regardless of owner; therefore, the contact authorizing the app must also have that ability.


I came across this same issue. If a user only has access to owned contacts, rather than shutting down their ability to integrate with the Contacts API, it seems like it would make sense that they still be able to integrate with the API, but that requests from their access token would be restricted to viewing and editing the contacts owned by that user.

I get that the API is currently set up such that any integrations with the contacts scope are able to read/write to all contacts, and that while that's the case you can't let a user's integration have more privileges than the user has themselves. However, is it possible to tweak the contacts api such that calls to it are subject to the same restrictions as the user that owns the access token?