topic Re: Error when adding a contact as a member to a list in APIs & Integrations

Error when adding a contact as a member to a list

CBman — Wed, 19 Mar 2025 17:41:19 GMT

Hi folks, I'm getting a strange error where my application tries to interact with a HubSpot account's list. (the # sign represents an anonymized, GUID = anonymized GUID)
API URI: /crm/v3/lists/#/memberships/add-and-remove
RequestBody: {“recordIdsToAdd”:[“#",“#”,“#",“#”],“recordIdsToRemove”:[]}
API Response: 403 PUT
403 Forbidden: “{”status”:“error”,“message”:“You do not have permissions to edit object type ObjectTypeId{legacyObjectType=CONTACT} in portal # (requires one of [contacts-write])“,”correlationId”:“GUID"}”
This makes no sense given that the scope isn't event available for my oauth app and I'm not trying to do a write to a contact, I'm just adding contacts to a list.

Is there any recommendations to remediate this? It references a deprecated scope in contacts-write from my understanding too. The account is using a Marketing Professional membership.

Re: Error when adding a contact as a member to a list

Jaycee_Lewis — Wed, 19 Mar 2025 21:07:14 GMT

Hey, @CBman 👋 I get the same result. In your tests, did you try the Add endpoint as well as the Add/Remove one? I am going to gather up our proof and share this with my internal resources. Thank you very much for taking the time to flag this. — Jaycee

Re: Error when adding a contact as a member to a list

CBman — Wed, 19 Mar 2025 21:34:00 GMT

So, our HubSpot application leverages the add/remove API on behalf of our clients and I do not have immediate access to leverage the token stored in production to test the add API out. However, for our other clients and testing that we leverage this API with, it has historically worked. Thanks for looking into this! 😄

Re: Error when adding a contact as a member to a list

WPeng3 — Fri, 30 May 2025 20:16:49 GMT

any solution ?

Re: Error when adding a contact as a member to a list

Syncari — Mon, 07 Jul 2025 22:44:41 GMT

We are facing something similar in our test, any updates? We are getting error with error message ""status":"error","message":"You do not have permissions to view object type ObjectTypeId{legacyObjectType=LEAD}"

Re: Error when adding a contact as a member to a list

Victor_Becerra — Tue, 08 Jul 2025 19:08:11 GMT

Hi @Syncari ,
Thank you for reaching out to the Community!
I'd like to invite some community members who are subject matter experts to join this conversation.
@GRajput @GiantFocal @zach_threadint - Would you be able to share any insights on this? Your expertise would be greatly appreciated.
Best regards,

Re: Error when adding a contact as a member to a list

CBman — Tue, 08 Jul 2025 19:35:17 GMT

i had to add crm.objects.contacts.write. i assume that you'd need to add crm.objects.lead.read and crm.objects.lead.write or replace lead with whatever object you're interacting with if it's a similar error. the membership apis require more permissions than documented as under the hood there's a dependency. i spoke with a dev here on the error https://hubspotdev.slack.com/archives/C05T36XTUBF/p1742574273625139

@Syncari

Re: Error when adding a contact as a member to a list

RubenBurdin — Mon, 18 Aug 2025 16:16:28 GMT

Good question @CBman

The 403 is a bit misleading here. Even though you’re “just” adding contacts to a list, HubSpot processes it as a write operation against the contact object. That’s why adding crm.objects.contacts.write to your app’s scopes resolves it.

If you run into similar issues with other objects (like leads, deals, or companies), the same logic applies: include both read and write scopes for those objects.

A couple of best practices I’ve seen work: slightly over-provision scopes for any objects your app touches, and keep an eye on the HubSpot Developer Changelog or Dev Slack since some of these dependencies aren’t fully documented yet. It avoids painful surprises in production. Docs reference:

https://developers.hubspot.com/docs/guides/api/crm/lists/overview

https://developers.hubspot.com/docs/guides/api/crm/objects/contacts

We’ve also seen this kind of hidden dependency trip up teams building integrations at scale. Every edge case burns cycles and adds fragility. That’s actually why we built Stacksync to abstract away those quirks so you don’t need to chase undocumented scopes or manage rate limits yourself.

Instead, you just declare what needs to sync and it runs correctly behind the scenes.

Hope this clears things up. Curious if this explanation matches what you saw on your side?