X Articles: Who Can Post Them and How the API Handles Drafts.

The short answer

X Articles can be published by accounts on X Premium, Premium+, Premium Business or Premium Organisations. Since 11 June 2026, the X API has two Articles endpoints: one creates a draft and one publishes it. That lets a publisher send long-form to X from its own tools, though the docs list no endpoint for editing.

What X Articles are

X’s Help Centre describes Articles as a way to share long-form written content on X. An Article can carry images, video, GIFs, posts and links, and text can be formatted with headings, subheadings, bold, italics, strikethrough, indentation and numbered or bulleted lists.

X says Articles are available globally. Once published, an Article can be read and shared by anyone on X, within the audience controls you chose for it.

For a publisher, that makes an Article the nearest thing X has to a page of your own site, hosted on someone else’s platform. That is the trade-off this whole decision turns on, and it is the same one behind how publishers think about always-on social.

Who can post them

The Help Centre is explicit: publishing Articles is limited to Premium and Premium+ subscribers, Premium Businesses and Premium Organisations.

So the first question for a publisher is not editorial. It is which account holds which subscription. If the brand account, the section accounts and the journalists’ own accounts sit on different tiers, only some of them will be able to publish an Article at all.

How to publish an Article in the composer

X’s own steps on x.com:

1. Subscribe to X Premium, Premium+, Premium Business or Premium Organisations.
2. Open the Articles tab in the side navigation.
3. Click Write and write the Article.
4. Click Publish. The Article goes live on your profile, in the Articles tab.

To make an Article for paying subscribers only, X says you click Publish, choose Subscribers under Choose your audience, then click Publish again.

Editing an Article unpublishes it

This is the line in the Help Centre that matters most to a newsroom. To edit an Article, you open its three-dot menu, select Edit Article and then Confirm. X says that unpublishes the Article. Once you have made the edit, you can republish it.

A publisher correcting a fact in a live story expects the page to stay up while the fix goes in. On X, the Article comes down while you edit. Plan corrections with that in mind, and decide in advance who is allowed to take a live Article down to fix it.

What the API now does

X’s developer changelog records that on 11 June 2026 it added endpoints for drafting and publishing Articles through the X API. The Articles introduction in the developer docs says the API currently supports two endpoints:

• Create a draft Article. The request carries the title, the body and, optionally, cover media uploaded through X’s media upload endpoints. The response returns the draft’s ID.
• Publish an Article. Using that ID, a second request makes the draft publicly visible. The response returns the ID of the post it creates.

The body has to be sent in a format called DraftJS, which X’s docs describe as a content state made of text blocks and entities. In practice, a publisher’s content system will need to convert each story into that structure before it can be sent.

What the API needs from you

X’s docs say these endpoints require user authentication, through OAuth 1.0a or OAuth 2.0 with PKCE, with the tweet.read, tweet.write and users.read scopes. In plain terms, the request has to act as a specific X account that has given your tool permission to read and post for it, using a user access token.

That has an operational consequence. Because the request acts as one account, the Article goes out from that account. If your scheduling tool is connected to the wrong account, the Article goes out under the wrong name.

What the docs do not say

The Articles introduction in X’s developer docs does not say whether an account needs one of the Premium tiers to publish through the API, and it lists no rate limits or length limits. The Help Centre’s rule is that publishing is limited to those tiers, so the safe plan is to connect the API only to an account that already has one.

The docs also list only two endpoints, draft and publish. There is no endpoint for editing or deleting an Article in that list. Corrections and removals still happen in the composer on x.com.

How to fit it into a publishing workflow

The API changes who does the work, not what the work is. A sensible setup for a publisher looks like this:

1. Decide which stories go to X as Articles, and write that rule down.
2. Connect the API to one named account with the right subscription, and record who owns that connection.
3. Send stories as drafts first, so a person reviews each Article before it goes live.
4. Publish from the draft once it has been checked.
5. Route every correction through the composer, knowing the edit takes the Article down until it is republished.

Step 3 is the one to protect. A draft endpoint and a separate publish endpoint means you can build a review step into the tool rather than relying on someone remembering to check. NBK helps publishers build exactly this kind of review step, and it matters more here because a fix costs you a live page.

What belongs on X and what belongs behind a link

This is the real decision, and it is editorial judgement rather than a setting.

An Article keeps the reader on X. That suits pieces whose value is the reading itself: an explainer, an opinion piece, a long thread that deserves to be one document, a summary of a story you have already covered in full on your site. The reader gets the whole thing without leaving the app.

It suits less well anything that earns its keep on your own site: the story that carries your advertising, the page that leads to a subscription, the live blog that changes by the minute. A live blog is a particularly poor fit, given that every edit unpublishes the Article.

Our view: treat Articles as a format for a defined set of stories, not as a second home for everything. Pick the types that work better read in full on X, and keep the rest on your own pages.

Mistakes to avoid

• Assuming every account in the newsroom can publish. Only the Premium tiers can.
• Connecting the API to a personal account by accident, so the Article publishes under the wrong name.
• Publishing straight from the API with no draft review.
• Treating an Article like a web page that can be edited live. Editing takes it down.
• Sending everything. A format with no rule for what goes in it becomes clutter.

What good looks like

A publisher using Articles well has a short written rule for which stories become Articles, one or two accounts on the right tier, and an API connection with a named owner. Each draft gets a quick human check before it publishes. Corrections have an agreed route and an agreed person.

It also treats X Articles as one channel in a wider publishing system, alongside the site and its other platforms, much as it would treat a Pinterest Save button on its own site: a small piece of plumbing that needs an owner.

Next step

Before anyone connects a tool to the Articles API, list which of your accounts can publish an Article today and who controls each one. If your social process is slowing down good ideas, NBK can help rebuild the workflow behind the content.