Authentication
TwitterAPIs uses a single bearer token on every request. No OAuth, no scopes, no token refresh.
TwitterAPIs uses one credential: an API key passed as a bearer token. There is no OAuth flow, no refresh token, and no per-endpoint scope to request. If the header is present and the key is valid, the call runs.
The header
Send your key on every request in the Authorization header:
Authorization: Bearer <API_KEY>A complete request looks like this:
curl "https://api.twitterapis.com/user/info?username=naval" \
-H "Authorization: Bearer $TWITTERAPIS_KEY"Where to get your key
- Sign up or log in at twitterapis.com.
- Open the dashboard and go to the API Keys page.
- Copy the key. It is shown once in full, so store it right away.
You can hold more than one key, which is useful for separating staging from production or rotating a key without downtime.
Key safety
Never expose a key in client code
A key sent from a browser, a mobile app bundle, or a public repository is a key anyone can read and spend. Always call TwitterAPIs from a server you control.
A few rules that keep keys out of trouble:
- Use environment variables. Read the key from
process.envoros.environ, never a string literal in committed code. - Proxy through your backend. If a frontend needs Twitter data, have it call your own endpoint, and let your server attach the key.
- Rotate on exposure. If a key leaks, create a new one in the dashboard and delete the old one. Calls on the deleted key stop immediately.
- Scope per environment. Use separate keys for local, staging, and production so you can revoke one without breaking the others.
What a bad key returns
A missing, malformed, or revoked key returns 401 Unauthorized with a JSON body. See Errors for the full shape and the other status codes.
{
"status": "error",
"code": 401,
"message": "Invalid or missing API key."
}