Is v1.1 still available?

Access to older endpoints depends on your access tier and can change. Build new work against v2, since that is where X documents current behavior.

Which endpoint creates a post in v2?

POST https://api.x.com/2/tweets with a JSON body containing a text field.

Do I have to use OAuth 2.0 now?

No. Manage-posts endpoints accept OAuth 1.0a User Context, and OAuth 2.0 with PKCE is an option you enable if you want scoped tokens and a browser-friendly flow.

Why are fields missing from my response?

v2 omits optional fields unless you request them with tweet.fields or user.fields and pull related objects in with expansions.

Expansions pull related objects into one response, such as the author of a post via expansions=author_id, so you avoid a second request.

What changed moving to X API v2

Short answer

Moving from X API v1.1 to v2 changes three things: endpoints now live under /2/ with noun-based resources like /2/tweets, responses are minimal until you request fields with tweet.fields and expansions, and user actions can use OAuth 2.0 Authorization Code with PKCE instead of only OAuth 1.0a. Posting a tweet is a POST /2/tweets with a JSON body.

Key takeaways

v2 endpoints are versioned under /2/ and named as resources, not actions.
Responses return a minimal object; you opt into extra data with field and expansion parameters.
Creating a post is POST https://api.x.com/2/tweets with a JSON body.
v2 supports OAuth 2.0 with PKCE for user-context calls, alongside OAuth 1.0a User Context.

If your mental model is still API v1.1, three differences will trip you up when you port a client. Here is each one with the current endpoint and parameter names from X’s documentation.

Where did the endpoints go?

Everything moved under /2/, and resources are named as nouns rather than actions. The old statuses/update is now POST /2/tweets, and reads come from paths like /2/users/:id/tweets. See the posting and reading guide for the full set.

Why does the API return so little data?

v2 returns a minimal object by default, and you request anything extra explicitly. Want the created time, metrics, or author? Ask for them with tweet.fields and expansions:

fetch("https://api.x.com/2/tweets/123" +
  "?tweet.fields=created_at,public_metrics" +
  "&expansions=author_id")

This keeps responses small and predictable, but it means a v1.1 client that expected full objects will see fields missing until you ask for them.

What authentication does v2 use?

v2 supports OAuth 2.0 Authorization Code with PKCE for user-context actions, as well as OAuth 1.0a User Context. Per X’s documentation, the manage-posts endpoints require OAuth 1.0a User Context, while OAuth 2.0 with PKCE can be enabled in your App settings for fine-grained scopes like tweet.read and tweet.write. The authentication chapter walks the PKCE flow step by step.

Porting a client? Do auth first. Everything else fails loudly, but a wrong token fails in confusing ways.

Sources

Manage Posts: create a Post, X Developer Platform documentation.
OAuth 2.0 Authorization Code with PKCE, X Developer Platform documentation.

What changed when X moved to API v2