Two API Fields You Can Write and Never Read Back
We found two fields in a scheduling API that accept a value, return HTTP 200, and never give it back. Not slowly. Not after a delay. Never, through any endpoint the API exposes.
Both looked, from every response we could read, like they had worked.
The first field
A social scheduling tool we use lets a post carry a first comment — a follow-up line attached to the post the moment it goes live, commonly used to carry a link that would otherwise look spammy in the main caption. The API accepts a value for it on creation. The response comes back 200.
We assumed, reasonably, that the value we could set was a value we could later read — through the same endpoint that returns the rest of the post, or through the endpoints for listing comments. We checked all three. None of them return the first comment. Get the post: not there. List the post’s comments: not there. List comments generally: not there.
The write succeeds. The read paths simply do not carry the field.
The second field, same shape
A board assignment — which collection a post belongs to inside the tool — turned out to be the same story. Create a post with a board specified, get a 200, and every subsequent call that should tell you what board a post is on returns nothing that says so.
Two unrelated fields, on two different objects, with the identical defect: accepted on write, absent from every read.
Why this is worse than an error
An API that rejects a bad value is annoying but honest. It fails, you see it fail, you fix it before anything ships.
A field that is accepted, acknowledged with success, and then invisible is a different category of problem, because nothing in the normal operation of your system will ever tell you it happened. Every automated check we could write against the API’s own responses would come back clean, because the API’s own responses do not carry the information needed to know the field is missing. You would need to already suspect the bug to go looking for evidence of it, and the API gives you none.
How we actually found it
Not from the API. We opened a live, published post in the tool’s own consumer-facing view — the same page anyone else would see — and looked at what was actually there. The first comment we had set was not attached to the post. The board assignment had not applied.
That is the only way this was established as true. Every API response we had, across every call available, said the write had succeeded. The only source of truth that disagreed was the live artefact itself, and we only checked it because a first comment we expected to see simply was not visible when we went looking at something else.
We want to be precise about what this means for how much trust an API response deserves. It is not that the tool lied. It is that a 200 status code answers a narrower question than the one we were asking — it says the request was accepted and processed without error, not that every field in the request produced the effect we assumed it would. Those are different claims, and it is easy to read the first as the second because most of the time, for most fields, they happen to agree.
The rule that falls out of it
Never let anything load-bearing live only where you cannot verify it.
If a piece of information matters — a link, an assignment, anything a workflow downstream depends on being true — it needs a path back to something you can actually check. Not a response code from the write. An independent read, ideally from the same surface a human would eventually look at, that confirms the value landed where you think it did.
This generalises past one scheduling tool. Any system your business depends on that accepts configuration through an API — a CRM, a marketing platform, a booking system — can have the same shape of gap, and the API’s own success responses will never tell you it exists. The only way to know is to check the artefact the API is supposedly producing, not the API’s account of producing it.
The practical fix we used
We could not make the API return what it does not carry. So we changed what we depend on it for.
The URL that mattered — the thing the first comment field existed to carry — now goes in the post body itself, where every read path does return it, rather than in the field that only accepts writes. And we worded the call-to-action so it reads correctly whether or not a first comment ever appears: it does not depend on a reader having scrolled to a comment that, from the API’s perspective, may as well not exist.
The board assignment has no equivalent workaround, because boards are purely an organisational feature inside the tool with no reader-facing consequence. We stopped setting it through the API entirely and assign boards by hand where it matters, because an automated write we cannot verify is not an automated write we can rely on — it is a write we hope happened.
What we would tell a business relying on any scheduling or automation tool
Ask, for every field your workflow depends on, one question: if this were silently ignored, would anything in your normal monitoring tell you? For most businesses running marketing automation, the honest answer is no, because nobody checks the live artefact against the request that produced it — they check that the request succeeded, which is a different thing.
The fields worth auditing this way are the ones that matter but are easy to set and forget: anything attached at creation rather than edited later, anything organisational rather than visible in the main content, anything you have never personally gone and looked at on the live page after setting it through an API or an automation.
We manage automated marketing and IT systems for clients as part of Microsoft 365 and platform support, and this is the class of defect we build verification for by default rather than assuming a success response settles the question.
The same discipline shows up in two other incidents we have written up: a publish boundary we built specifically because outward calls are the one place a silent failure is expensive, and a run of six jobs that each reported success while doing nothing at all. We also went back through our own repositories afterward with the same instinct — checking what a system actually holds rather than trusting what it is supposed to hold — and found a settings file in every clone despite its name promising otherwise.
Ash Ganda is the founder of Cloud Geeks, which provides managed IT support and cyber security for Australian small and medium businesses.