I’m using Claude’s HubSpot connector (OAuth integration, not a private app token) with Notes and Tasks scopes explicitly granted on the consent screen. The connection shows those scopes as available, but every API write to a Note or Task object fails with a 403/authorization error — while writes to Contacts, Companies, Calls, and Deals on the same connection work fine. My HubSpot user has full manual permission to create Notes and Tasks in the UI. Is there a known restriction on Notes/Tasks API write access at the Free/Starter tier that’s separate from OAuth scope grants or UI permissions? Any guidance on where this gap actually lives would help.
Hi @barbdebb4411, Sounds like the same pattern others have hit, a scope can show as granted on the token, but HubSpot still returns 403 if the portal’s subscription tier doesn’t include that API access, even with the right scope present. Worth checking if Notes/Tasks writes have a similar tier gate, and try reinstalling/re-authorizing the connector in case the account needs to re-consent to the scope.
Is this a subscription-tier restriction, or a restriction on the scope being usable by public/OAuth-connected apps specifically (as opposed to a Private App token generated within my own portal)? I’ve already fully disconnected and re-authorized the connector twice with Notes/Tasks scopes explicitly checked, and got the identical 403 both times — so it doesn’t look like a re-consent issue on my end.
@barbdebb4411, Since you’ve already disconnected and re-authorized the connector twice and the same 403 persists, it doesn’t sound like a stale OAuth token.
I’d recommend checking whether the endpoint you’re calling is available for OAuth apps or restricted to specific HubSpot subscription tiers/private app authentication. If the same scopes are granted but the API still returns 403, it may be an endpoint-level permission or account entitlement issue rather than an authorization issue.
If possible, could you share the exact HubSpot endpoint you’re calling (or the relevant part of the request)? That would make it easier to determine whether this is a scope limitation, a subscription restriction, or a connector-specific issue.
Thanks for digging into this with me. Here’s what I have:
Endpoints (inferred from the connector, not directly observed — I don’t have visibility into the raw HTTP call):
POST https://api.hubapi.com/crm/v3/objects/notes
POST https://api.hubapi.com/crm/v3/objects/tasks
Request body pattern: {"properties": {"hs_note_body": "...", "hs_timestamp": "..."}} for notes, hs_task_subject for tasks — sometimes with an associations array linking to a contact, sometimes without. Both patterns fail identically.
Exact error message, verbatim, every attempt:
“Unauthorized request to downstream service. Please verify the connection’s OAuth scopes include the required permissions.”
Correlation IDs from three separate failed attempts (not sure if these are HubSpot-side or Anthropic-side identifiers, but including in case they trace):
77c6903f-80af-41e7-ba82-f46ebeda56ca5aa3def5-0b6f-4f1e-a9f0-b1964057c2fc126add89-8ced-41e0-9294-de42d0b804a7
One clue that might narrow it down: Contacts, Companies, Calls, and Deals writes on this exact same connection all work fine — it’s only Notes and Tasks that 403. If it were a blanket subscription-tier restriction on the API as a whole, I’d have expected it to hit more than just these two object types, which makes me wonder if it’s scoped specifically to engagement objects (Notes/Tasks) for OAuth/public apps, rather than a tier-wide gate. But that’s my guess, not confirmed.
Appreciate you sticking with this — let me know if there’s anything else that would help narrow it down.
this definitely helps narrow it down. The failures are limited to POST /crm/v3/objects/notes and POST /crm/v3/objects/tasks, while writes to Contacts, Companies, Calls, and Deals succeed using the same connection, it doesn’t seem like a general OAuth scope issue.
A few possibilities come to mind:
- The connector isn’t requesting or passing through the required engagement object scopes (
crm.objects.notes.write/crm.objects.tasks.write), even though the other CRM scopes are present. - HubSpot applies different permission requirements to Notes and Tasks for public OAuth apps versus private apps.
- The downstream service is validating against a cached or incomplete access token rather than the current one.
One question that might help isolate the issue is have you tried calling either endpoint directly with the same OAuth access token (for example, using Postman or curl)? If that also returns a 403, it points to a HubSpot OAuth/permission issue. If it succeeds, the problem is more likely in the connector’s implementation.
I don’t have a way to test the raw token directly — is there another way to narrow this down from your end?
Unfortunately I can’t inspect the connector from my end, but based on what you’ve shared, there are a couple of things the connector team could check:
- Compare the OAuth scopes actually being requested and stored for a working object (e.g. Contacts) versus Notes/Tasks.
- Log the downstream request immediately before it’s sent to HubSpot to confirm the same access token is being used and that no required scopes are being dropped.
- Verify whether the connector is using the CRM Engagements endpoints correctly for public OAuth apps, as Notes and Tasks may have different permission requirements than other CRM objects.
- If possible, check HubSpot’s response headers or error body for any additional details beyond the generic 403, as HubSpot sometimes returns more specific authorization information.
Based on everything you’ve posted so far, I’m leaning toward this being a connector-side scope or token propagation issue rather than a problem with your HubSpot account, but hopefully those checks will help narrow it down.