Most X API Spaces builds start the same way: a plain App-only Bearer Token, a handful of lookup calls, and everything works on the first try. Then the roadmap adds ticketed-Space reporting or host-facing buyer analytics, and the exact same auth setup starts failing — not with a formatting error, but with an authorization rejection nobody planned for.
The Spaces endpoints are not one uniform API. Five of six work with the simplest possible credential. One does not, and X buries that distinction inside an OpenAPI security block most integrators never open.
Space lookup, batch lookup, creator search, keyword search, and in-Space Posts all accept a plain Bearer Token. The ticket-buyers endpoint does not — it accepts only OAuth 2.0 user context carrying space.read, tweet.read and users.read together, and by X's own account, it only returns data when the authenticated user is the Space's own creator, on a ticketed Space.
An integration built and tested against the first five endpoints will look completely correct right up until the sixth call is made.
Spaces also behave differently from every other resource on the API in one more way: there is no endpoint to create one. A Space can only be started, scheduled or cancelled inside the X app itself — the API's role is strictly read and discovery, never write.
Six Endpoints, Two Very Different Access Rules
Bearer-eligible endpoints
Lookup by ID, batch lookup, lookup by creator, keyword search, and Posts shared inside a Space all accept a simple App-only Bearer Token — no user login flow required.
The OAuth-only exception
Ticket buyers accepts only OAuth 2.0 user context, and only returns results when the requester is the Space's own creator — the one endpoint tied directly to revenue.
No create-Space endpoint
There is no POST for Spaces anywhere in the API. Starting, scheduling and ending a Space happens only inside the X app.
Live-only lifecycle
Spaces can be scheduled up to 14 days ahead and cancelled anytime before they start, then disappear from every lookup endpoint the moment they end.
The Endpoint Set
| Method & endpoint | What it does | Auth needed |
|---|---|---|
| GET /2/spaces/:id | Get one Space's details by ID | Bearer token or OAuth 2.0 user context |
| GET /2/spaces | Look up multiple Spaces by ID at once | Bearer token or OAuth 2.0 user context |
| GET /2/spaces/by/creator_ids | Find live or scheduled Spaces hosted by given user IDs | Bearer token |
| GET /2/spaces/search | Search live or scheduled Spaces by keyword | Bearer token |
| GET /2/spaces/:id/tweets | Get Posts shared inside a Space | Bearer token or OAuth 2.0 user context |
| GET /2/spaces/:id/buyers | Get Users who purchased a ticket to a Space | OAuth 2.0 user context only — no Bearer-token path |
participant_count is the only listener-facing number this API returns. There is no listener list and no listener-level IDs anywhere in the Spaces data dictionary — only an aggregate count. And once a Space's state moves to ended, every lookup endpoint above stops returning it: the lifecycle is real-time only, not an archive.
Where These Builds Stall
- Testing the whole integration on one Bearer token. Five endpoints pass every test. The buyers call fails at launch, because it was never Bearer-eligible in the first place.
- Assuming participant_count can be broken into a listener list. It is an aggregate number only — no listener-level data exists in this API at all.
- Polling for a Space after it ends, expecting archived data. Ended Spaces are not retrievable; the lookup endpoints return an error, not history.
- Assuming an approved developer app can schedule or start a Space. There is no such endpoint — Space creation happens only inside the X app.
- Requesting buyer data without confirming the requester is the Space's creator. X's documented behavior returns nothing for anyone else, ticketed or not.
What a Correctly Scoped Spaces Integration Looks Like
Getting the Access Model Right Before You Build
Spaces integrations almost always start as a Bearer-token-only build, because five of six endpoints work that way from the first request. The gap only shows up once a product roadmap adds ticketed-Space reporting or host-facing buyer analytics — and at that point, the fix is not a code change but a second authorization flow that has to be planned, scoped and reviewed like any other user-facing OAuth surface.
I provide setup, scope-planning and configuration support for X (Twitter) API integrations, including Spaces endpoint selection, OAuth 2.0 user-context flows and buyer-data access design. This sits alongside the platform's OAuth scopes vs. app permissions breakdown, the developer account approval and pricing guide, and the webhook-based Account Activity API covered elsewhere on this site.
Endpoints, scopes and access rules on the X API change frequently and must be confirmed against the official documentation and your developer console at the time you build. This page is technical setup and configuration support — no specific outcome or timeline can be promised.