Getting a Twitter Developer Account: Approval, Keys, and Whether You Need One
Getting a Twitter Developer Account: Approval, Keys, and Whether You Need One
Before you start the application, one question saves a lot of time: do you need a developer account, or do you need X data?
They're not the same thing. A developer account is X's front door — necessary if you're going to post, reply, or act as an authenticated user. If you only need to read public data, it's one route among several, and not always the fastest.
This covers the application, key handling, the webhook question, and where the whole thing is worth skipping.
The application
Where: the X developer portal. You sign in with a normal X account, so you need one first — with a verified phone number, which trips people up.
What you fill in: a description of what you're building and how you'll use the data. Write it plainly. "Building an internal dashboard to monitor mentions of our brand" is a better answer than something vague and impressive-sounding.
How long: varies from immediate to several days. There's no published SLA and no queue position to check. If yours is slow, there's nothing to do but wait.
★The developer account itself is free. What costs money is the API access it grants★ — see what the tiers actually cost, because the pricing is the part that kills most projects, not the approval.
⚠️ The free tier is write-oriented. If you applied expecting to read posts at any volume, check the tier limits before building. This is the single most common surprise.
If waiting on approval is the blocker and you only need to read public data, that's a route that doesn't involve an application — no portal, no use-case review.
What you get: keys and tokens
Approval gives you a project, an app inside it, and a set of credentials. The names are confusing because they come from different eras of the API:
| Credential | What it's for |
|---|---|
| API Key / API Secret | Identifies your app. Sometimes called consumer key/secret. |
| Bearer Token | App-only auth. Fine for reading public data. |
| Access Token / Secret | Acts on behalf of a user. Required to post. |
The practical split: reading public data needs the bearer token. Acting as a user — posting, following, liking — needs the access token pair, obtained through OAuth.
★If your app never needs to act as a person, you never need the user tokens★, and that's a meaningfully smaller security surface.
Handling keys without regretting it
- Never commit them. Use environment variables or a secret manager. A key in a public repo gets found by automated scanners within minutes, not days.
- Rotate after any exposure. Regenerating is instant and free.
- One app per project. Shared credentials make it impossible to tell which project is burning your quota, and impossible to revoke one without breaking the other.
- Understand the blast radius. ⚠️ A leaked user access token means someone can post as you. A leaked read-only key means someone can spend your quota. Those are very different bad days — which is why the read-only/write distinction is worth caring about.
The webhook question
This one surprises people, so it's worth being direct.
There is no general-purpose webhook for "notify me when this account posts". X's webhook-style delivery exists for account-activity use cases — DMs and events on your own authenticated account — and requires a separate approval process. It is not a mechanism for watching other people's public timelines.
So how do you watch for new posts?
- Polling. Ask repeatedly, compare against what you've seen. Simple, universally available, and the cost is entirely determined by your interval — which is the number that drives your bill.
- A streaming connection. One persistent connection that pushes data as it arrives. Lower latency, more moving parts to keep alive.
The trade-off between these is the real architectural decision, and it's independent of whether you have a developer account.
★Why we chose streaming over webhooks★
We publish a WebSocket stream and deliberately don't offer webhooks. The reasoning, since it's a decision that affects how you'd integrate:
A webhook makes the receiver's uptime your problem. If your endpoint is down for ten minutes, someone has to decide what happens to those events — buffer them, drop them, retry them, and for how long. Every webhook provider ends up building a retry queue, a dead-letter policy, and a signature scheme, and ★every one of those is a place where events silently disappear★.
A stream inverts it. You hold the connection. If you drop, you know you dropped — your client saw the disconnect. Reconnect and resume. There's no ambiguity about whether a delivery attempt happened, because there was no delivery attempt; there was a connection you were on or off. (Our stream works this way, for exactly this reason.)
The honest trade: webhooks are easier to start with — no long-lived process, just an HTTP endpoint. Streams need a supervised connection. ⚠️ If you specifically want a webhook, we don't have one, and that's a real reason to look elsewhere. We'd rather say so than describe polling as a webhook.
When you don't need a developer account
You need one if: you're posting, replying, liking, following, or acting on behalf of users. There's no alternative — no third party can do write operations for you, and any that claims to wants your account credentials.
You may not need one if: you're reading public data. Then it's a comparison — official API versus a managed data API versus your own scraper — and the deciding factors are cost, approval time, and who maintains it when X changes something. The full comparison is here.
★The short version: writing requires the official API. Reading is a choice.★
Questions people ask
How do I get a Twitter developer account? Apply through the developer portal with an X account that has a verified phone number, describe your use case, and wait for approval.
Is a Twitter developer account free? The account is. API access above the free tier is metered — see current pricing.
How long does developer approval take? Anywhere from immediate to several days. No published timeline and no way to check position.
Why was my developer application rejected? Usually a vague use-case description, or a request that doesn't match the tier. Reapply with something specific about what you're building.
Where is the Twitter developer portal?
developer.x.com. The older developer.twitter.com addresses generally redirect there.
How do I get an X API key? Create a project and an app in the portal after approval. Keys appear in the app's Keys and Tokens section.
What's the difference between API key and bearer token? The API key identifies your app. The bearer token authenticates app-only requests — it's what you use for reading public data.
What are access tokens for? Acting on behalf of a user. Required for posting; unnecessary for reading public data.
How do I regenerate API keys? In the app's Keys and Tokens section. Regeneration is immediate and invalidates the old ones — expect a brief break while you deploy the new value.
What happens if my API key leaks? Someone can consume your quota. A leaked user access token is worse — that allows posting as you. Rotate immediately either way.
Does Twitter have webhooks? Not as a general "notify me about this account" mechanism. Webhook-style delivery exists for account-activity use cases on your own account, with separate approval.
How do I get notified when someone tweets? Poll on a schedule, or hold a streaming connection. Comparing the two approaches is the useful read.
Can I use the API without a developer account? Not X's own API. Third-party data APIs read public data without one, but they can't write.
Do I need a developer account to read tweets? For X's official API, yes. For public data generally, no — there are other routes.
What is OAuth for on Twitter? Letting users authorise your app to act for them. Only relevant if you're doing write operations.
How many apps can I create? Depends on tier. Free is limited to a small number of projects and apps.
Can I share API keys across projects? Technically yes, practically don't. You lose the ability to attribute usage or revoke one project's access independently.
What is a Twitter developer site or portal used for? Managing projects and apps, viewing usage, and regenerating credentials. It's administration, not development.
Why does my API key not work? Common causes: using the API key where a bearer token is expected, a regenerated key not yet deployed, or an endpoint outside your tier.
Can I test the API before applying? Not X's own. Third-party APIs generally let you make a call immediately, which is often the faster way to find out whether your idea works at all.
What's the difference between a project and an app? A project is the container tied to your access tier; an app inside it holds the credentials. Most people need one of each.
Is there a free Twitter API key? A free tier exists and is write-oriented — ★read access on it is minimal enough that most read use cases do not fit★.
What is a bearer token? A credential you send as a header to authenticate app-level requests. ★Treat it like a password★ — anyone holding it can spend your quota.
Where is the developer dashboard? In the developer portal, where projects, apps, and keys live together.
What are the official developer tools? The portal, the documentation, and the API itself. ★Everything else is third-party★ — how to evaluate those.
Do I need a developer account to read public data? ★Not necessarily.★ A developer account is for using X's own API — reading public data through another provider does not require one.
If you're evaluating routes
Two questions settle it:
Are you writing to X? Then you need a developer account, and the rest is paperwork. Nothing here substitutes.
Are you only reading public data? Then compare on cost, time-to-first-call, and who fixes it when X changes something.
Our API is the read-only route: a key from the dashboard, no application or use-case review, flat price per call, and no rate limit of your own to manage. It's read-only by design — ★which also means a leaked key costs you quota, never your account★.
Requests we reject before dispatch, and errors on our side, aren't billed.
Related reading: what the official API costs · polling versus streaming · handling rate limits correctly · every way to get X data compared.