My X account was migrated to the new Pay to Use tier and given the $10 credit, once that’s run out though it stopped posting. I added some more credit and that didn’t fix it either.
I’ve a new app in X Dev as suggested, made sure it has write access and given the new credentials to the X credentials in N8N.
I can auth the app, but whenever I try and send the tweet I get 403 forbidden errors.
@Stuart_Grimshaw Can you share the full 403 error or a screenshot of the 403 error, to see if it has any additional details we can use to help diagnose your case?
`
{ “detail”: “You are not permitted to perform this action.”, “type”: “about:blank”, “title”: “Forbidden”, “status”: 403 }`
and the full stack trace from the same error:
NodeApiError: Forbidden - perhaps check your credentials?
at ExecuteContext.twitterApiRequest (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-nodes-base@file+packages+nodes-base_@aws-sdk+credential-providers@3.808.0_asn1.js@5_8da18263ca0574b0db58d4fefd8173ce/node_modules/n8n-nodes-base/nodes/Twitter/V2/GenericFunctions.ts:56:9) at processTicksAndRejections (node:internal/process/task_queues:104:5)
at ExecuteContext.execute (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-nodes-base@file+packages+nodes-base_@aws-sdk+credential-providers@3.808.0_asn1.js@5_8da18263ca0574b0db58d4fefd8173ce/node_modules/n8n-nodes-base/nodes/Twitter/V2/TwitterV2.node.ts:237:22) at WorkflowExecute.executeNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_d301200d8c5446bebb311523c3c1b485/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1048:9) at WorkflowExecute.runNode (/usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_d301200d8c5446bebb311523c3c1b485/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1239:11)
at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_d301200d8c5446bebb311523c3c1b485/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:1687:27
at /usr/local/lib/node_modules/n8n/node_modules/.pnpm/n8n-core@file+packages+core_@opentelemetry+api@1.9.0_@opentelemetry+exporter-trace-otlp_d301200d8c5446bebb311523c3c1b485/node_modules/n8n-core/src/execution-engine/workflow-execute.ts:2339:11
welcome to the n8n community @Stuart_Grimshaw
I would recreate the n8n X OAuth2 credential after confirming the X app is set to Read and write and that the current X developer tier allows posting through the API, since n8n’s X node V2 uses OAuth2 and X enforces plan and endpoint limits outside n8n.
The specific 403 you are seeing (“You are not permitted to perform this action”) right after a tier migration is almost always a scope problem rather than a billing one, and it has a sneaky cause: changing the app’s permissions in the developer portal does not update tokens that were already issued. If the OAuth connection was made before the app was switched to Read and write, the access token n8n holds still carries read-only scopes, and X returns exactly this 403 on POST /2/tweets. Adding credit does not touch it, which matches what you saw.
The sequence that fixes it:
In the X developer portal, confirm the app sits inside a Project (standalone apps get 403s on v2 endpoints regardless of permissions), and that User authentication settings show Read and write with app type Web App.
After any permission change, hit Regenerate on the keys and tokens. This is the step that actually invalidates the stale scopes.
In n8n, do not edit the old credential. Delete it, create a fresh X OAuth2 credential with the regenerated client ID and secret, and run the OAuth flow again.
On the consent screen, read the listed permissions. If “Post and delete posts for you” is not in the list, the write scope is still not being requested and the setting in step 1 did not save.
One more pay-per-use quirk worth knowing: reads and writes are billed separately per request, so a working read node proves billing is fine but says nothing about write authorization. The consent screen check in step 4 is the reliable tell.