TweetAPI · Authentication Profile
Tweetapi Authentication
Authentication
TweetAPI secures its APIs with apiKey and oauth2 across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode flow(s).
twitterxsocial-mediasocial-datasearchanalyticsresearchdeveloper-toolsmcpagent-nativellms-txtrest-api
Methods: apiKey, oauth2
Schemes: 2
OAuth flows: authorizationCode
API key in: header
Security Schemes
XApiKey apiKey
· in: header ()
TweetAPIOAuth oauth2
· flows: authorizationCode
Source
Authentication Profile
generated: '2026-08-11'
method: searched
source: https://tweetapi.com/docs/getting-started/overview
corroborating_sources:
- https://tweetapi.com/.well-known/oauth-authorization-server
- https://mcp.tweetapi.com/.well-known/oauth-protected-resource/mcp
- https://tweetapi.com/llms.txt
docs: https://tweetapi.com/docs/getting-started/overview
note: >-
Derived by hand rather than by derive-authentication.py: TweetAPI publishes no OpenAPI, so there
are no securitySchemes to aggregate. Everything below was read from the provider's own docs and
live OAuth discovery documents.
summary:
types: [apiKey, oauth2]
api_key_in: [header]
oauth2_flows: [authorizationCode]
surfaces: 2
schemes:
- name: XApiKey
type: apiKey
in: header
parameter_name: X-API-Key
applies_to: TweetAPI tw-v2 REST API (all 76 documented endpoints)
source: https://tweetapi.com/docs/getting-started/overview
obtained_from: https://tweetapi.com/dashboard (account required, free trial without a card)
note: >-
Single key, no scopes, no key-level permission model. The key identifies the billing account
and its rate ceiling; it does not restrict which endpoint categories may be called.
- name: TweetAPIOAuth
type: oauth2
applies_to: TweetAPI Hosted MCP Server (https://mcp.tweetapi.com/mcp)
source: https://tweetapi.com/.well-known/oauth-authorization-server
issuer: https://tweetapi.com
flows:
- flow: authorizationCode
authorizationUrl: https://tweetapi.com/dashboard/mcp/authorize
tokenUrl: https://tweetapi.com/api/oauth/token
revocationUrl: https://tweetapi.com/api/oauth/revoke
registrationUrl: https://tweetapi.com/api/oauth/register
scopes: [tweetapi:read, offline_access]
pkce: {supported: true, methods: [S256], required_hint: only S256 advertised}
grant_types: [authorization_code, refresh_token]
token_endpoint_auth_methods: [none]
resource_indicators: true
bearer_methods: [header]
note: >-
RFC 8414 authorization-server metadata plus RFC 9728 protected-resource metadata, with dynamic
client registration (RFC 7591) and RFC 8707 resource indicators. This is a materially stronger
auth posture than the REST surface, and it exists so the API key stays behind the OAuth
boundary instead of being pasted into an agent client.
account_credentials:
note: >-
A distinct third credential class, and the one a governance reader should look at hardest. The
account-authorized endpoints (posting, engagement, lists, profile, X Chat, legacy DM — 43 of 76
documented endpoints) require the caller to pass end-user Twitter/X session material as ordinary
request parameters: authToken (the auth_token cookie), ct0 (the CSRF token), an optional
upstream proxy string of the form host:port@user:pass, and for POST /tw-v2/auth/login a username,
password and twoFactorSecret. These are not TweetAPI credentials and there is no delegated
authorization (no OAuth to X, no token exchange) in front of them.
fields: [authToken, ct0, proxy, password, twoFactorSecret]
transport_concern: >-
Several of these appear as query-string parameters in the provider's own published curl examples
(for example GET /tw-v2/interaction/inbox-timeline-trusted?authToken=...), which puts long-lived
session cookies into URLs and therefore into logs and referrers. Moving them to the request body
or a header would be a meaningful hardening step.
provider_guidance: >-
TweetAPI's own agent skill forbids agents from requesting, storing or forwarding any of these
values, and the hosted MCP server deliberately does not expose the endpoints that need them.
gaps:
- No scopes or per-key permissions on the REST surface
- No key rotation or expiry policy published
- No mTLS, no signed requests, no OpenID Connect
- No documented 403 behaviour distinguishing key-level from account-level authorization failure
see_also:
- scopes/tweetapi-scopes.yml
- conventions/tweetapi-conventions.yml
- well-known/tweetapi-well-known.yml