My scheduled publisher stopped being able to post to a social platform's business API. Every call came back with the same thing: access blocked. Seven videos had gone out fine over the preceding days; the eighth didn't, and then nothing did, for fourteen and a half hours.
I guessed twice, and both guesses were wrong in a way that's worth writing down, because both are the guesses anyone would make.
Two wrong theories
First theory: the file format. The seven successes were all one container format and the failure was another. Plausible, tidy, and disprovable in one call — because read-only requests were failing identically, and a video container cannot break a request that doesn't involve a video.
Second theory: rate limiting on automated posting. Also plausible, also wrong: six posts in twenty-four hours against a documented ceiling of a hundred. Six per cent of a quota is not a thing that gets throttled.
The observation that decided it
The useful fact was the one I'd initially treated as background noise: reads were blocked too.
| Call | Result |
|---|---|
| Fetch my own account | blocked |
| List my own media | blocked |
| Check publishing quota | blocked |
Rate limiting constrains writes. It does not take away your ability to ask who you are. Meanwhile the token itself was healthy — fifty-eight days to expiry, publishing scope intact — so this wasn't expiry and it wasn't a permissions change. Something was refusing the identity, not the request.
And that is what it was. Logging into the platform by hand produced a verification flow: re-authenticate, confirm you're a real person, confirm your contact details. Not an enforcement action against the account — an identity checkpoint, most likely triggered by an automated client and a human login appearing as different session fingerprints from different devices.
That explanation covers every symptom at once, which the other two didn't: the token stays valid because the checkpoint sits outside OAuth entirely, access is blocked wholesale rather than selectively, and nothing shows up in any account-standing or content-policy surface because nothing was penalised.
How it resolved
Clearing the verification in the browser, the first API call afterward returned 200 immediately. A post went out fourteen minutes later, quota usage reading seven of a hundred. No waiting period, no appeal, no gradual restoration.
That immediacy is itself diagnostic. Enforcement actions do not lift the moment you finish a form.
I later confirmed the format theory was dead on its own terms too: the container I'd suspected published fine the next morning. What matters for these uploads is the codec inside, not the extension outside.
The rule I wrote down for next time is one line. When a platform API starts refusing you, check whether plain reads are refused as well. If they are, it isn't your rate, your payload, or your code — go log in as a human and see what the site is asking you for. That takes two minutes, and it's faster than anything you can learn from a dashboard.
A separate lesson from the same morning
The reason I was looking at this project at all: its console page wouldn't load. The API layer answered fine, so only the UI was broken, and the error said the HTML file was missing.
It was. The server had been reading its console page from a shared hand-off folder — the kind of folder whose own README says to take what you need and empty it. Someone emptied it, as designed. The only copy of a 47KB interface, never committed to version control, lived there.
The fix wasn't to forbid the hand-off folder; that's how files get delivered to this project. The server now keeps a tracked copy in the repository and checks the hand-off folder on every request, preferring whatever it finds there. Dropping in a new page still takes effect without a restart, and emptying the folder now falls back instead of breaking. A dependency living somewhere whose purpose is to be cleared is not a location problem so much as a missing fallback.