What happens
Connecting the Twitter/X toolkit via the default quick-connect (account OAuth) produces a connection that looks ACTIVE but fails on every X API v2 call with:
403 Forbidden
{"reason":"client-not-enrolled", "detail":"When authenticating requests to the X API v2 endpoints, you must use keys and tokens from a developer App that is attached to a Project.", "client_id":"30926256"}
The client_id (30926256) is Composio's own shared OAuth app, which is not attached to a project with paid X API access. So the account-OAuth path can never make a working v2 call, no matter what the user does, and the failure is only visible at call time - the connection itself reports healthy.
Why it's confusing
For a user with their own paid X developer app and subscription, the quick-connect never asks for their app credentials, so their paid tier is never used and every call 403s. From the user's side the X connection appears "active but useless."
Expected / suggestion
TikTok already does the right thing here - connecting TikTok prompts for your own app's client credentials (a custom auth config) up front, because TikTok's API requires an app you own. X/Twitter has the same requirement (v2 calls need keys from a project-attached developer app), but its Composio connector defaults to account-OAuth through the shared app instead of prompting for a custom auth config.
Could X/Twitter default to (or clearly steer users toward) the custom developer-app auth config the way TikTok does - i.e. ask for the user's own OAuth client id + secret - and surface a clear message when a connection is on the shared app that cannot make v2 calls? Even a docs note and a connect-time warning would prevent the silent "active but non-functional" state.
Environment
- Toolkit: twitter (X)
- Symptom: 403 client-not-enrolled on
/2/users/me, /2/tweets, /2/usage/tweets via the account-OAuth connection
- Works as expected: reading public posts via a non-API scrape path; the failure is specific to X API v2 calls requiring a project-attached app
Thanks for the great platform - this one just costs users real debugging time before they realize the account-OAuth path can't work for X.
What happens
Connecting the Twitter/X toolkit via the default quick-connect (account OAuth) produces a connection that looks ACTIVE but fails on every X API v2 call with:
The
client_id(30926256) is Composio's own shared OAuth app, which is not attached to a project with paid X API access. So the account-OAuth path can never make a working v2 call, no matter what the user does, and the failure is only visible at call time - the connection itself reports healthy.Why it's confusing
For a user with their own paid X developer app and subscription, the quick-connect never asks for their app credentials, so their paid tier is never used and every call 403s. From the user's side the X connection appears "active but useless."
Expected / suggestion
TikTok already does the right thing here - connecting TikTok prompts for your own app's client credentials (a custom auth config) up front, because TikTok's API requires an app you own. X/Twitter has the same requirement (v2 calls need keys from a project-attached developer app), but its Composio connector defaults to account-OAuth through the shared app instead of prompting for a custom auth config.
Could X/Twitter default to (or clearly steer users toward) the custom developer-app auth config the way TikTok does - i.e. ask for the user's own OAuth client id + secret - and surface a clear message when a connection is on the shared app that cannot make v2 calls? Even a docs note and a connect-time warning would prevent the silent "active but non-functional" state.
Environment
/2/users/me,/2/tweets,/2/usage/tweetsvia the account-OAuth connectionThanks for the great platform - this one just costs users real debugging time before they realize the account-OAuth path can't work for X.