intercom "not authorized" error creating conversation via rest api

TL;DR

"Not authorized" on Intercom conversation creation is a permissions problem in almost every case, not a broken request. Check the access token's scopes first, then whether you are authenticating against the right workspace, then whether the contact or user id you are replying to actually exists in that workspace. Tokens that can read conversations often lack the write scope for creating them.

The query

intercom "not authorized" error creating conversation via rest api

Use this when

• POST to create a conversation returns 401 or 403 "not authorized"
• Reads work but writes fail with the same token
• The error appears after switching tokens or workspaces
• You are maintaining an Intercom messaging integration

Not for

• OAuth app registration or redirect flows
• Messages not delivering after a 200 response
• Conversation assignment or routing rules
• Rate limit (429) errors

Steps

1. Confirm which token you are sending and what it can do

Intercom has app-scoped tokens and workspace tokens with different permission models. Verify the token in use, its scopes, and that the scope covering conversation creation is granted. Regenerating a token without re-granting scopes is a classic cause.

Expected output: token type identified, write scope confirmed granted.

2. Verify the workspace

Tokens are workspace-bound. A token minted in the production workspace fails in staging with "not authorized" rather than a clearer error. Confirm the token belongs to the workspace your requests target.

Expected output: token workspace matches the target workspace.

3. Validate the contact or user identity in the request

Creating a conversation requires referencing an existing contact or user by id, or creating with valid contact attributes. A typo'd id or an id from another workspace reads as an auth failure. Look the contact up first with a read call.

Expected output: the referenced contact resolves in the target workspace.

4. Check the reply versus create distinction

Replying to an existing conversation needs the conversation id and a different permission than creating a new one from a contact. Confirm you are calling the right endpoint for what you want: new conversation from contact, or reply to open conversation.

Expected output: endpoint matches the intended operation.

5. Re-issue the token as a last resort and diff the scopes

If everything checks out, regenerate the credential and compare scopes against the old one. Scope drift during token rotation explains otherwise inexplicable denials.

Expected output: a fresh token with confirmed scopes, request succeeds.

Template: the checklist

Intercom "not authorized" on conversation create:
[ ] Token type and scopes confirmed (write scope granted)
[ ] Token belongs to the target workspace
[ ] Contact/user id resolves in that workspace (verified with a read)
[ ] Using the create endpoint, not the reply endpoint (or vice versa)
[ ] Freshly regenerated token tested if all else looks right

Variant phrasings

intercom api 401 creating message

Steps 1 and 2. Token and workspace first.

intercom api 403 forbidden conversation

Steps 3 and 4. Identity and endpoint selection.

intercom token works for get but not post

Step 1. Scope gap between read and write permissions.

Why it happens

Intercom separates token scopes and workspace binding strictly, and its error messages compress several distinct failures into "not authorized." A valid token for the wrong workspace, a scope missing one write permission, or a contact id from another workspace all surface the same way, which is why the checklist order matters.

Edge cases

• Test mode apps: some conversation operations behave differently in test versus live apps. Confirm which mode the token belongs to.
• Deleted contacts: the id once worked, then the contact was merged or deleted. The error looks like an auth failure.
• Server-to-server versus user auth: user impersonation flows carry different permissions than app tokens. Do not mix them.
• Regional endpoints: if your workspace lives in a specific region, requests to the wrong regional host can fail auth.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst20srvFSRM5_YaxnvDMSYg