What Decides How Long a Video You Can Post to X Is Not Your API Plan

The upload finished. The progress bar hit 100%, the media id came back, everything looked healthy — and then attaching it to a post returned a 403 with a sentence about how long a video "this user" is allowed to post. You check your developer dashboard. You are on a paid tier. You consider upgrading it.

Do not upgrade it. On 2026-09-01, X published a changelog entry documenting media size and duration limits, and one sentence in it explains the whole failure.

The sentence that saves you a subscription

Verbatim from the X API changelog entry dated September 1, 2026, retrieved 2026-09-21:

"Limits follow the authenticated user's X Premium / verified status and media_category, not your developer API plan."

Read that again with your own setup in mind. The ceiling is a property of the account you are posting on behalf of, not of the credentials you are posting with. A developer on the cheapest tier posting on behalf of a Premium account gets the Premium ceiling. A developer on an expensive tier posting on behalf of a default account gets the default ceiling. The money that moves the limit is the money the account holder spends, not the money the developer spends.

This is not a subtle distinction in a pricing table. It is the difference between fixing the problem for a few dollars on the right account and paying for a developer tier that will not change the outcome at all.

The actual numbers, and which account they attach to

From the same entry, verbatim:

Three things worth pulling out of that table.

The DM row is a different product. A Premium DM video tops out at 10 minutes — well under the 20 minutes a default account gets on a Post. If your integration sends media through DMs, the Post limits tell you nothing about what will work.

media_category is part of the rule. The sentence names it alongside Premium status. The categories are not interchangeable labels; picking the wrong one is its own class of failure, separate from any duration question.

Upload and attach are enforced separately. The entry says so directly: "Upload and POST /2/tweets are separately enforced." That is why the failure feels so wrong. A large file can move through the upload endpoints cleanly and still be rejected the moment you try to attach it, because the duration check that applies to the posting user happens at the attach step. Your upload code is not broken.

The 403, read literally

Also verbatim from the entry:

"Exceeding the posting user's duration cap returns 403 This user is not allowed to post a video longer than N minutes."

The phrase doing the work is "this user." The error is telling you, accurately, that the limit belongs to an account — and if you are running a multi-account setup, it is telling you which side of the transaction to go look at. The same media, the same code, and the same developer credentials will succeed on one connected account and fail on another, purely because one of them has Premium and one does not.

That also means the error is not a bug report. It is the API answering the question correctly. The fix is on the account, not in the request.

Three checks before you queue a long video

1. Check the Premium status of the posting account, not the developer account. This is the entire point of the changelog sentence, and it is the check people skip because the developer dashboard is the screen they happen to be looking at. If you manage several accounts, the ceiling can be different for each one.
2. Check which surface you are targeting. Post video and Direct Message video have separate ceilings, and Premium raises them by different amounts. Going from 140 seconds to 10 minutes in DMs is a large relative jump and still far below the Post limit.
3. Check your upload path. The same entry notes that "the chunked upload quickstart now uses the v2 paths (POST /2/media/upload/initialize, /{id}/append, /{id}/finalize) instead of the previous command-style POST /2/media/upload flow." Long videos are exactly the case that forces chunked upload, so tutorials written against the old command-style flow break precisely when you need them. We covered that migration separately in the X API media upload v2 writeup.

If a long video fails on X, the first thing to check is not your code and not your API tier. It is whether the account you are posting as has Premium.

Where this fits with the numbers you have seen elsewhere

If you have read that X publishes several different video limits and they all appear to be official, that is correct and it is not a contradiction. Different product surfaces — the web composer, the mobile app, the API — have separately documented ceilings, which is the subject of our piece on three official numbers that are all correct. What the September 1 entry adds is the axis: within the API, the variable that moves the ceiling is the authenticated user's Premium status, not your plan.

Two adjacent cost questions that this entry does not answer, and which are worth keeping separate in your head: what a single post actually costs through the API is a different meter entirely (the per-request numbers), and what X's own terms permit an automated poster to do is a policy question rather than a quota one (what X allows). A ceiling, a price and a permission are three different walls, and hitting one of them tells you nothing about the other two.

One practical consequence for anyone posting the same long-form video across a set of accounts: the ceiling is per account, so your pipeline's safe maximum is whatever the weakest account in the set allows — unless you branch. A publishing workflow that signs into each of your own accounts locally, like the one NoobClaw is built around, hits exactly this asymmetry, and the honest answer is that it is a property of X's rules rather than something a tool resolves. Know which accounts have Premium, and cut a shorter version for the ones that do not.

FAQ

Will upgrading my X API plan let me post longer videos?

No. The changelog entry dated 2026-09-01 states it directly: "Limits follow the authenticated user's X Premium / verified status and media_category, not your developer API plan." A higher developer tier buys you request volume and endpoint access. It does not raise the duration or size ceiling on a post, because that ceiling is attached to the account being posted on behalf of.

My upload succeeded but posting returned a 403 — what broke?

Probably nothing in your upload code. X enforces upload and POST /2/tweets separately, so an oversized or overlong file can complete the upload and then fail at attach. If the response body says "This user is not allowed to post a video longer than N minutes," the N in that message is the ceiling for the authenticated account, and the fix is on the account or on the video, not in the request.

Do the same limits apply to video sent in Direct Messages?

No, and the gap is larger than most people expect. The entry records DM video as unchanged at 140 seconds / 512 MB by default, and 10 minutes / 1 GB on Premium. A Premium DM ceiling is still half the default Post ceiling of 20 minutes. If your integration branches between posting and messaging, it needs two sets of validation rules.

The satisfying part of this one is that the thing you were about to buy is not the thing that was blocking you. Go check the Premium status on the account that is actually doing the posting.