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

tweetapi-authentication.yml Raw ↑
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