SECURITY
How TwitterAPIs Keeps Your Keys and Data Secure
Authentication is one Bearer token. All traffic runs over TLS 1.2+. Write credentials are proxied to X and discarded the moment the call finishes, so nothing lands on disk. Payments go through Stripe, so we never see a card number, and the only personal data we store is your email and name. Here is the full picture.
One Bearer Key, Scoped to Your Account
Every request carries a single Authorization: Bearer header, the same shape as the official X API token. There is no OAuth 1.0a secret pair to leak and no long-lived refresh token to manage. Your key bills only your account, and you can set per-endpoint spend caps so a leaked key can never run up an unbounded bill.
Write Credentials Are Proxied, Then Discarded
Write actions use a bring-your-own-credentials model: you pass your X auth_token and ct0 in the request, we proxy the call to X, and we discard both values the moment the request completes. Nothing is written to disk or to a database, and no OAuth token is ever issued or stored, because we do not issue one.
Encrypted in Transit, Encrypted at Rest
All traffic between your app and api.twitterapis.com runs over HTTPS with TLS 1.2 or higher, and connections cannot be downgraded to plain HTTP. Account data sits in a managed Postgres database that encrypts data at rest at the platform layer.
We Store Only Your Email and Name
Signup records your email and name, and the billing and usage data needed to run your account. We do not build profiles, we do not sell or share your data, and we never see your payment-card numbers, because Stripe processes every charge.
Securing Your API Key
Your key is a single Bearer token, so the whole security model comes down to keeping that one string private and giving it a ceiling. Five practices cover almost every real-world leak.
- Keep the key in an environment variable or a secrets manager, never hardcoded in source or committed to git.
- Send it only over HTTPS, in the Authorization header, never in a URL query string where it can land in logs.
- Your full key is shown once, at creation, so copy it into your secrets store then; the dashboard lists keys but does not show the raw value again.
- If a key is exposed, delete it from your dashboard to revoke it instantly, then create a fresh one in its place.
- Set per-endpoint spend caps so a leaked or misused key has a hard ceiling instead of an open-ended bill.
- Run a separate named key per environment (development, staging, production) so you can revoke any one of them without touching the others.
Send the key the same way on every platform: one header, over HTTPS, read from the environment rather than written into the code.
1# Key lives in the environment, never in the source.2curl "https://api.twitterapis.com/twitter/tweet/advanced_search?query=from%3Anaval" \3 -H "Authorization: Bearer $TWITTERAPIS_KEY"See the Twitter API key guide for how the key is issued, and the quickstart for your first call.
Credentials, Encryption, and What Leaves Your Control
Reads need nothing from your X account, just your Bearer key. Write actions use a bring-your-own-credentials model: you pass your X auth_token and ct0 in the request, we proxy the call to X, and we discard both the moment the request completes. They are not written to disk or to a database, and no OAuth token is created or kept, because we never issue one.
Everything moves over HTTPS with TLS 1.2 or higher, with no downgrade to plain HTTP. The account data we do keep, your email, name, and billing and usage records, sits in a managed Postgres database that encrypts data at rest at the platform layer.
Payment details never reach our servers at all. Stripe, a PCI-DSS Level 1 provider, handles every charge, so we hold no card data. For account login you can use Google OAuth instead of a password.
Reporting a Vulnerability
Found a security issue? Email emma@twitterapis.com with the details and the steps to reproduce. We acknowledge reports and work to remediate confirmed issues. Please give us a chance to fix a vulnerability before disclosing it publicly. For how we collect and retain data, see privacy and data handling.
Frequently Asked Questions
Yes. Authentication is a single Bearer token, all traffic is encrypted over TLS 1.2+, write credentials are proxied to X and discarded the moment the call finishes, payments are handled by Stripe so we never see card numbers, and the only personal data we store is your email and name. We also never sell or share your data.
No. We never ask for or store your X password. For write actions you pass your own auth_token and ct0 cookies in the request; we proxy the call to X and discard both values when the request completes. Nothing is written to disk or to a database, and no OAuth token is issued or stored.
Delete the key from your dashboard to revoke it, then create a new one. Deleting is the fastest way to shut off access if you think a key has been exposed. Because you can run several named keys at once, one per environment, you can revoke any single key without affecting the others.
Delete it from the dashboard immediately, which revokes it. Because keys bill only your account and you can set per-endpoint spend caps, the blast radius of a leak is limited to your own usage with a ceiling you control, never an open-ended charge or access to your X account.
You create named keys in your dashboard, scoped to your account, and the full key value is shown once at creation, so copy it into your secrets store then. Treat it like a password: keep it in an environment variable or secrets manager, never commit it to git, and send it only in the Authorization header over HTTPS. If a key leaks, delete it from the dashboard to revoke it and create a new one. Per-endpoint spend caps give a leaked key a hard ceiling.
Yes. Every request runs over HTTPS with TLS 1.2 or higher, and the connection cannot be downgraded to plain HTTP. Account data stored on our side sits in a managed Postgres database that is encrypted at rest at the platform layer.
Payments are processed entirely by Stripe, a PCI-DSS Level 1 provider, so card numbers never touch our servers. For account login you can also sign in with Google for an OAuth-backed flow instead of a password.
Email emma@twitterapis.com with the details and steps to reproduce. We acknowledge reports and work to remediate confirmed issues. Please do not publicly disclose a vulnerability before we have had a chance to fix it.
Next read
Continue exploring related pages: