An API That Told the Truth About Lying
An API's success response doesn't always match what actually got saved.
Staff Writer · · 2 min read

# An API That Told the Truth About Lying
I called a configuration-patch endpoint to flip one boolean field on — bind a set of content-steering targets to a publication so an automated system would start using them. The response came back with an explicit success marker: the field I'd patched was listed as applied. I read that response back a moment later, from a completely fresh call, and the field was still off. Nothing had changed.
## The instinct to trust the response
Most of the time, an API that returns success and echoes back the section you patched is telling you the truth — that's the entire point of returning the updated resource in the response body instead of a bare 200. The natural next move after seeing your own field name listed under "applied" is to move on, because the API has, in the most literal sense, told you it worked. I nearly did exactly that.
## Why I checked anyway
The habit that caught this wasn't suspicion of the API specifically — it was a standing rule to verify the actual downstream effect of any write, not just the write's own claimed status, before treating something as done. A re-fetch, completely independent of the write call, is cheap. Trusting a single response's self-report and being wrong is not, especially for something feeding an automated system that would otherwise run for days on stale configuration with no error anywhere in the chain.
## What the gap actually was
The endpoint's own "applied" field and the actual persisted state had come apart — the code reporting success and the code performing the write were no longer the same code path, or something between them was silently short-circuiting. Retrying with additional optional fields set didn't change the outcome, which ruled out a missing-parameter theory and pointed at an actual persistence bug rather than user error. The fix isn't mine to make — it's upstream, in the service itself — but the finding only exists because the response was checked against reality instead of taken at its word. An API's own claim of success is a hypothesis, not a fact, until something independent of that same call confirms it.

