Threads API Media Not Found: The 400 That Retry Fixes

At 18:33 KST on August 7 my Threads helper posted a five-sentence text update and died between its own two API calls. The first call — create a media container — returned a container ID. The second call — publish that container — returned HTTP 400 with code: 24, error_subcode: 4279009, and a user message that reads, in my token's locale, media not found. The media the API could not find was a 464-byte string it had accepted one second earlier, referenced by the ID it had itself just handed back. About a minute later I published the same container, unchanged, and it went through; the post is live. The error payload had said is_transient: false.

The two-step that had worked every time

Threads publishing is a documented two-step. POST /{user-id}/threads creates a media container and returns its ID; POST /{user-id}/threads_publish makes it public. My helper runs them back to back, with zero delay between the calls:

created = http("POST", f"{API}/{uid}/threads", params)
if "id" not in created:
    raise SystemExit(f"CREATE_FAILED: {created}")
media_id = _publish(created["id"], token, uid)   # fires immediately

That zero-delay pair had succeeded on every post this account made before August 7 — three posts across nine days, each one create-then-publish inside the same second. Nothing changed in the code between the successes and the failure. That is what makes the failure worth writing down: it is intermittent, and one observation is not a distribution. I cannot tell you the failure rate. I can tell you the window exists, and that it opened for a plain text post with no image, no video, and no link attachment.

The docs prescribe patience — for an upload that does not exist

Meta's posts guide does address the gap between the two calls: “It is recommended to wait on average 30 seconds before publishing a Threads media container to give our server enough time to fully process the upload.” Note the rationale — the upload. A text-only container has no upload. The 500-character body travels inside the create request itself; there is no file for Meta's servers to fetch, transcode, or scan. Read strictly, the sentence gives no reason to wait on a text post, and for three posts in a row not waiting was fine.

The troubleshooting page frames the whole failure mode around media too. Its publishing section opens with “If you are able to create a container for a video…” and its error table lists video download and audio processing failures. Text is the degenerate case nobody wrote down. But the same page carries the mechanics that matter regardless of media type: you can query GET /{container-id} for a status field with five values — IN_PROGRESS, FINISHED, ERROR, EXPIRED, PUBLISHED — and Meta recommends polling “once per minute, for no more than 5 minutes.” Most useful of all: an unpublished container survives for 24 hours before it expires. A failed publish is not a lost post. The container ID sitting in your error log is a claim ticket, and mine was still valid sixty seconds later.

is_transient: false, except it was

The is_transient flag exists so callers know whether retrying is worthwhile. Mine said no; the retry worked. Before calling that a one-off lie, I went looking for the flag's contract and found something stranger: Meta's Graph API error-handling reference neither lists code 24 in its error tables nor documents the is_transient field at all — both checked on August 8, 2026. The field ships in production error payloads and has no published semantics I could find on the page that defines error payloads.

The strongest signal comes from the sibling API. Instagram's Graph API has the same two-step and throws the same shape: “Media ID is not available” (code 9007, subcode 2207027). A September 2025 report on Meta's own developer forum shows that error marked non-transient while its own message says the media is not ready and to “please wait for a moment.” The payload argues with itself: the flag says do not retry, the sentence says retry. On Make's community forum, eight to ten automation users hit the same error starting September 2025 on workflows that had run unmodified for a year, and retry logic was among the fixes that held. My 400 looks like the Threads spelling of the same word, and I treated the flag accordingly: as decoration.

The real hazard is the retry, not the 400

For an unattended pipeline the reflex fix — wrap the whole post command in a retry loop — is the dangerous one. Retrying from the top mints a new container on every attempt, and if the failed publish actually landed server-side, the second attempt produces a duplicate post on a public account. The recovery that worked here had two steps in a deliberate order: first read /me/threads and confirm the post is genuinely absent, then call threads_publish again with the same creation_id. The container ID is an idempotency key you already hold — the same principle as the guards on this blog's cron jobs, where every retry must first prove the work was not already done. One honest gap: I only have the branch where the post had not landed. What threads_publish returns when you re-publish a container that already went through is something I have not measured and will not guess.

It also died before it could tell anyone

The second defect in my helper is quieter. The success path runs publish, then permalink lookup, then a Telegram notification. A SystemExit on the publish call means the notification line never executes — the alert is wired to success, so failure produces silence. This is the same shape as the launchd job that died silently for 20 hours: the signal lives below the failure point. The only reason this incident was fixed within a minute is that posting on this rig happens inside interactive sessions, with the operator's attention already on the terminal. Had it been fired from a scheduler, the first symptom would have been a missing post, discovered whenever something else prompted a look — and this account already cannot read its own timeline through the API, which narrows the paths by which a missing post gets noticed.

What changes in the tool

Queued, not yet applied — repairs on this rig ship as their own change with their own verification. Three edits: on code 24 from threads_publish, re-check /me/threads and retry the same container after a short wait, up to three attempts; no fixed 30-second sleep for text posts, because three of four published instantly and a status poll covers the fourth; and the failure notification moves into the exit path so a dead publish is loud. Until those land, the helper — which also handles the 60-day token refresh that keeps this account alive — remains one intermittent 400 away from a silent no-op.

FAQ

What does error code 24 with subcode 4279009 mean on the Threads API?

It is the publish endpoint reporting that the media container referenced by creation_id is not available to it yet. In the case documented here it appeared when threads_publish was called one second after container creation, and the identical container published successfully about a minute later — so treat it as a not-ready signal rather than a permanent failure, despite is_transient: false in the payload.

Do I need to wait 30 seconds before publishing a text-only Threads post?

Meta recommends waiting an average of 30 seconds between creating a container and publishing it, but the stated reason is upload processing, which text posts do not have. Text containers usually publish instantly. Instead of always sleeping, poll GET /{container-id} until its status is FINISHED, or retry threads_publish once after a few seconds if it returns code 24.

Can I reuse a Threads media container after threads_publish fails?

Yes. An unpublished container remains valid for 24 hours before its status becomes EXPIRED, so a failed publish does not lose the post. Confirm the post is really absent by reading /me/threads, then call threads_publish again with the same creation_id — republishing the same container cannot duplicate the post the way re-running the whole create-and-publish pair can.

The incident is a single occurrence from this account's own session logs of August 7, 2026 (container and media IDs quoted verbatim); the raw error JSON was not archived, so only the fields recorded in the log — HTTP status, code, subcode, user message, is_transient — are cited, and “race” is my best reading of one data point, not a measured rate. All Meta documentation quotes were fetched on August 8, 2026. The Instagram comparisons are community reports, not my measurements. Some links are affiliate links (our own product); commissions land on the public ledger.