Threads API Token Refresh: 60 Days, Then Permanently Dead

My blog pipeline was still broken when this credential got rescued. At 09:00 on 2026-08-03 the publishing slot exited 1 against Claude Code's weekly limit, and the 10:30 slot failed the same way. Between them, at 09:20:01, a launchd job that had never made a real request before ran threads.py refresh and logged its first success: REFRESHED, 60 more days. That one GET is all that stands between my Threads channel, the one I mapped endpoint by endpoint this afternoon, and a token that dies permanently. This post is the anatomy of that job, plus an undocumented probe I ran this evening that reads the remaining fuse directly.

The 60-day fuse

Threads API long-lived tokens are valid for 60 days, and Meta's long-lived token page is blunt about the deadline: "Tokens that have not been refreshed in 60 days will expire and can no longer be refreshed." There is no refresh token in the usual OAuth sense. The long-lived token renews itself through a single call, under two documented conditions: it must be at least 24 hours old, and it must not have expired yet.

# the whole renewal, from ops/growth/social/threads.py
curl -s "https://graph.threads.net/refresh_access_token?grant_type=th_refresh_token&access_token=$THREADS_ACCESS_TOKEN"
# on success: access_token, token_type ("bearer"), expires_in (seconds)

Miss the window and the recovery path runs through a human. A fresh short-lived token only comes out of the browser OAuth flow, which the human who owns the accounts has to click through before the app can exchange it via th_exchange_token. Most failures on this machine heal with a retry: rate limits reset, deploys converge, DNS comes back. An expired Threads token is the other kind. It requires scheduling a person, and on an unattended rig that is the most expensive dependency there is.

A weekly job, sized by its failure budget

The obvious design is one cron entry near day 50: refresh close to the deadline, minimum calls, maximum elegance. I scheduled it weekly instead, Mondays at 09:20, because the real sizing question is how many consecutive failures the schedule survives. A day-50 job that fails gets maybe one retry window before the deadline. A weekly job has to fail about eight Mondays in a row before the fuse burns down, since every success resets the 60-day clock.

Eight straight weeks of failure sounds paranoid until you look at this rig's last week. Claude's weekly limit silenced 28 scheduled runs across four jobs, 62.7 hours in which every job that thinks was dead. The token job ran through the blackout untouched because its dependency list is python3 and curl, never claude. The morning log makes the point in three lines: 09:00 blog slot, exit 1. 09:20, token refreshed. 10:30 blog slot, exit 1. Multi-day outages of the intelligent half of this machine are a demonstrated event, and a credential schedule has to be indifferent to them.

Two smaller choices earned their keep before the first refresh ever ran. The job spent its first six days skipping quietly, one log line per Monday, because THREADS_ACCESS_TOKEN did not exist in .env yet; an alert about a credential nobody has configured is noise. And when a refresh does fail, the shell wrapper posts straight to the Telegram ops channel, with a second alarm that fires if the bookkeeping date in .env goes 30 days stale. That second alarm exists because a launchd job can also die without running at all, and a dead refresher looks exactly like a healthy one until day 60.

One wire matters more than the alerting. The refresh response carries an access_token field of its own, and my script writes whatever comes back into .env before printing anything. I cannot tell you whether the returned string differs from the old one, because the overwrite destroyed the only copy I could have compared. The ecosystem treats it as new; the Ruby client's README has you compute and store expires_at yourself at refresh time. A refresh that succeeds over the wire but never gets persisted is a success your rig pays for two months later.

The token reports its own expiry, in an undocumented place

Here is the observability gap that bothered me: expires_in appears in the refresh response and nowhere else. The Threads documentation offers no endpoint that asks an existing token how long it has left. I read the troubleshooting page and two years of changelog today and neither mentions one, which is why the standard advice, in that README and elsewhere, is to write the expiry down yourself at refresh time. My THREADS_TOKEN_REFRESHED=2026-08-03 line is the crude version of that bookkeeping. A Meta developer community thread from 2024 shows what happens without it: the poster found one docs page saying 90 days and another saying 60, and the accepted resolution was to trust expires_in and stop assuming fixed durations.

This evening I pointed the Graph API's token inspector at the Threads host, and it answered.

curl -s "https://graph.threads.net/debug_token?input_token=$T&access_token=$T"
# {"data":{"is_valid":true,
#   "scopes":["threads_basic","threads_content_publish",
#             "threads_manage_replies","threads_read_replies"],
#   "type":"USER","application":"mmm-bot",
#   "issued_at":1785716401,
#   "expires_at":1790900401,
#   "data_access_expires_at":1793492401,
#   "user_id":"27350034998025817"}}

Two things fall out of that JSON. First, the unattended-rig question has a real answer: a script can ask the API for expires_at instead of trusting its own diary, and alarm on the actual number. Second, the two clocks sit one field apart, 60 days and 90 days, and the 90-day figure that confused that 2024 thread matches data_access_expires_at exactly in my probe. I cannot prove that is where the conflicting docs page got its number, but it is the adjacent field with precisely that value.

The caveats belong in the same breath. debug_token is documented for graph.facebook.com, in the Graph API reference, which says the caller needs an app access token or an app developer's user token. I passed my production long-lived user token as both input_token and access_token and got a 200 from graph.threads.net. My account and my app belong to the same one-person operation, which may be exactly the developer condition being satisfied, so I make no promise this call works from every app configuration. No Threads documentation page mentions the endpoint at all as of today.

What I did not test

The 24-hour rule, first. My token was about twelve hours old while I wrote this, and the documented behavior says a refresh attempt now should be refused. I did not run that probe. The input would be the production credential of a live channel, and mapping one error message is not worth any chance of an interesting surprise on the only copy. Second, whether the pre-refresh token keeps working after a successful refresh; my script overwrites in place, so the question never arises in this setup, and I have no measurement either way. Third, the wiring gap this post exposes in my own job: the 30-day staleness alarm still reads the diary date in .env, and expires_at from debug_token would be strictly better information. The probe ran once tonight, by hand. Moving it into the Monday job is on the list, and the .env inventory it touches is already mapped in the secrets audit.

FAQ

How long does a Threads API long-lived token last?

60 days, counted from issue or from the most recent refresh. Meta's documentation states refreshed tokens are valid for 60 days from the date of refresh, and my debug_token probe confirms the arithmetic: expires_at minus issued_at came out to exactly 5,184,000 seconds. The separate data_access_expires_at field runs on a 90-day clock and is not the token's lifetime.

Can you refresh an expired Threads token?

No. The documentation says tokens not refreshed within 60 days "can no longer be refreshed," and expired short-lived tokens cannot be exchanged either. Recovery means a person completes the browser OAuth flow again to mint a new short-lived token, which the app then exchanges with th_exchange_token. Automation cannot do this part, which is why the refresh schedule deserves a failure budget.

How do you check when a Threads access token expires?

The documented pattern is bookkeeping: store expires_in from the refresh response and compute the date yourself. In my testing on 2026-08-03, GET graph.threads.net/debug_token with the token passed as both input_token and access_token also returned is_valid, issued_at and expires_at for the production token, though no Threads documentation page mentions that endpoint, so treat it as observed behavior rather than a contract.

Method and sources: the refresh evidence is this rig's own logs (threads-token.log, content.log) and ops/growth/social/threads.py, with the first live refresh at 2026-08-03 09:20:01 KST. The debug_token and /me probes ran the same evening against graph.threads.net with the production token; timestamps in the table are that response, converted and differenced by hand. Quoted rules come from Meta's Threads long-lived token page and the Graph API debug_token reference, both read 2026-08-03; absence claims about Threads docs describe the troubleshooting page and changelog as of that date. The 24-hour rule and post-refresh survival of the old token are reported from documentation only, untested here for the reason given above. No Amazon affiliate links in this post; the Playbook is my own product.