USER_DOES_NOT_HAVE_PERMISSION API error

[SteveHTM]

I'm getting an error that I having trouble understqnding from the v4 associations API. 

{
"status": "error",
"message": "One or more associations are invalid",
"correlationId": "8113ff26-aa33-4f6f-9937-368d85e9c842",
"context": {
"USER_DOES_NOT_HAVE_PERMISSION": [
"User does not have permissions to associate DEAL 13309937218 with CONTACT 126450882"
]
},
"category": "VALIDATION_ERROR"
}

I have validated the Deal/Contact association type (in both directions) and made sure that the objects do exist. I also have checked private app scopes for both objects are set to write.

Any suggestions from the group?

[mediagarcia]

I ran in to this issue and I though it was because of this issue and that I needed to create a new private key, however this approach did not solve it for me. 

What did solve it was increasing the scope of the API to include the schema read/write. 

So since I was making an association between a contact and a custom object I needed to add 

crm.schemas.contacts 

and 

crm.schemas.custom

[SteveHTM · Accepted solution]

Wow - just goes to show that some out-of-the-box thinking helps here!

The app token I had been using was created by me - but under an email address since disabled as a user.

I just created a new private app using my new account with identical scopes and used the new token with exactly the same code - voila, everything worked as expected!

So beware folks - you may think that a private app is account related and not tied to a user ID, but it seems to be that there are undocumented limits to that assumption. In my case, reading data worked using the older app token - but writing data failed as per the reported error. I cannot tell if this is by design or not - can anyone from the product team comment on this?

[Jaycee_Lewis]

Hey, @SteveHTM 👋 That's great to know you got it resolved. And I'm sorry we had to take the long way around the street to get there.

I'll package this up and pass along your feedback + attach the support ticket that inspired me to even ask that question in the first place. 

I appreciate your collaboration 🙌 — Jaycee

[SteveHTM]

@Jaycee_Lewis -thank you for the helpful questions. I'll try and address these and zero in on the potential underlying issue.

- Its a production portal, in use for a number of years and with enterrpise level subscriptions.

- My tests are on newly created deals, but the creation logic (workflow step) hasn't changed for 6 months or more.

- I've done tests using the custom code workflow steps, then experimented using the surgical call mechanics on the API pages. I have very similar code running in other portals that works consistently.

- I created the private app key some while back. I guess I was using a different account address at the time. That is a good thought of something to check perhaps. But other search API calls, association label listing API calls (all data reading not writing of course) are working in the code fragment without issue.

I have done a few searches of the community posts and Google in general and not found any good clues. I kind of expect this to be a scope issue that is not properly reported as such, but I can't figure out what I'm missing there. 

Thanks again!

[Jaycee_Lewis]

Hey, @SteveHTM 👋 Thanks for posting this. It's very intriguing, and frustrating, behaviour for sure. I don't have the answer. But I want to help. I did a bit of searching of old support tickets for similar issues, on my end, and found some leads but nothing definitive…yet. 

I have a few questions:

• Is this happening in a production portal? Or in an app test account? 
• Is this occurring with newly created deals only? Or “older” deals too? 
• Can you reproduce this issue with some consistency?
• If yes, do you have an “old” deal that you can use to reproduce the issue? 
• Also, if yes, can you record a Loom at the same time (if you can, you can DM this to me later)
• Lastly 🙃, is this a Private App key that you yourself created? Or was it created by another User? 

“Just a few questions” = famous last words 🤣

These questions are a collection of things I noticed were requested in related support tickets. I don't know everything, but I know enough to show up well armed to a support case  💪

Talk soon! — Jaycee

[JoshAtPaperCut]

We ran into this today also, we quickly found this community post and we were cleansing our data so it was pretty evident to the issue. Our symptoms were that all API calls were working to create Companies, Deals, Contacts, etc, however as soon as we tried to associate those objects via the API it would fail with USER_DOES_NOT_HAVE_PERMISSION.

What's interesting is that we've had the email address that created this API key deactivated for some time in the system, it was only after deleting the email when this started.

- Is this happening in a production portal? Or in an app test account? 

This was happening in production for us.

- Is this occurring with newly created deals only? Or “older” deals too? 

All deal associations seemed to fail, no matter the age of the deal.

- Can you reproduce this issue with some consistency?

100%, as long as you create a Private App then delete the email that created the app.

- Is this a Private App key that you yourself created? Or was it created by another User? 

As the other posts in here mention, it wasn't - it was a user that was purged from our system.

Hope this helps others!

[MatthieuLibeer]

@Jaycee_Lewis This issue just happened to us. It was a pain to pinpoint. At this point, it's unclear why only calls to create associations fail but all others succeed, but it definitely seems like this behaviour is not by design.

> Is this happening in a production portal? Or in an app test account? 
Production. The app is a private app but a connected app, and it's not listed on the marketplace.

> Is this occurring with newly created deals only? Or “older” deals too? 
For us it's these associations, i.e. all the associations we try to create:  meeting > contact, meeting > company, call > contact, call > company. We get the "validation error" for both newly created objects and old ones.

> Can you reproduce this issue with some consistency?

For logistical reasons I don't want to make the integration fail on purpose. But I'm 90% sure that this issue follows the removal of the user that installed the app from the HubSpot account.

This is quite critical, at this point we're just hoping that whoever installed our application on the client's side is not removed from the client's HubSpot account, otherwise our integration will fail and we have no way to know apart from error logs on our side.

For what it's worth, for the integration in question, I asked the client to remove the app and install it again, which fixed the issue. Until the latest installer of the app is removed from the HubSpot account I guess 🤣