The API Update That Quietly Made a Paid Product Free

The setup

A content platform I was updating had a familiar-looking editor: write your post, mark a line as "everything above this is free preview," publish. Readers see the free part; paying customers see the rest. Standard paywall pattern, nothing exotic.

I needed to fix a batch of stale price references across several paid posts — pure text edits, nothing structural. Doing it by hand through the rich-text editor for a dozen posts is slow and error-prone, so I pulled each post's content through the platform's API, did the string replacement in code, and pushed the updated body back through the same API.

Fast, clean, verifiable diff before and after. Or so I thought.

What was actually happening

The paywall boundary — "everything above this line is free" — isn't stored as part of the post body text. It's separate state, and the editor UI renders it as a marker positioned within the content. When I pushed a full-body replacement through the API, that marker didn't travel with it. On the next visit to the editor, the paywall boundary had silently reset to right after the first paragraph.

For most of the posts, "right after the first paragraph" happened to be close enough to correct that nothing looked obviously wrong in the editor's own preview — which, critically, is rendered from the account owner's session. Owners can always see the full content, paid or not. The editor's preview will never show you what a non-paying visitor actually sees.

For the posts where the intended free preview was substantial — several paragraphs of sample questions before the paywall — the reset boundary would have made almost the entire paid product readable for free the moment I hit publish.

Why this is the dangerous kind of bug

Nothing about the update looked wrong. The text I changed was correct. The editor's own preview looked correct, because the editor's preview is authenticated as me. The only way to see the actual bug was to load the page with no session at all and see where the content actually cut off for a stranger.

This is the same shape as the bundle-pricing bug I wrote about before: a piece of state that looks like it belongs to the content actually lives in a separate system, edited through a separate path, and nothing forces the two to stay in sync. Except this time the blast radius wasn't "a customer sees an outdated number" — it was "a paid product becomes free and nobody notices until revenue quietly drops."

How I caught it

Same rule as always: don't trust the rendering, check the actual output.

curl -s "<public-post-url>" -H "User-Agent: Mozilla/5.0" | grep -o "Question [0-9]*"

A plain anonymous HTTP fetch, no login, filtered for a marker that only appears past a certain point in each post. Compare that against what should be visible for free. For three posts, content that should have cut off after item 5 was fully readable straight through to item 20.

The account-owner preview inside the editor would never have shown this. It took an explicitly logged-out check to surface it — and that's the part worth internalizing: if a permission boundary exists, the only preview that actually validates it is one taken from outside that boundary.

The fix

Once caught, fixing it was mechanical: reopen each affected post's paywall settings, drag the boundary marker back to its intended position, republish, re-verify with the same anonymous curl check. Nothing clever about the fix. The value was entirely in catching it before a reader did.

Going forward, any workflow that updates paid content through an API now has a mandatory step: after publishing, re-fetch the public URL with no auth and confirm the paid section is actually gated. Not a one-time check — a step baked into the process, every time, because the failure mode is silent and the API makes it trivially repeatable.

The takeaway

APIs are usually the more trustworthy path — no flaky UI, no accidental clicks, a clean diff of what changed. But an API only guarantees the fields it explicitly manages. Anything the UI quietly maintains alongside the content — access boundaries, ordering, visibility flags, anything that isn't literally "the text" — can be invisible to that API and get reset the moment you bypass the UI that was implicitly protecting it.

If you're editing paid or access-controlled content through anything other than the exact UI flow it was designed for, the question isn't "did my edit apply correctly." It's "what else does that UI silently manage that my edit didn't know to preserve" — and the only way to answer that is to check from outside the account that's editing it.