Here is the sentence that causes the most expensive bugs in LinkedIn automation: the API returned 200, so the post went out.
It did not necessarily. A 2xx from any LinkedIn API means the request was accepted and passed on. What LinkedIn then does with it — show it to nobody, hold it for review, quietly drop it, show it and remove it twenty minutes later — is not in that response, and in several cases is not in any response.
Why the gap exists
There are at least two hops between your code and a post being visible, and the second one is a platform with its own opinions about automated content. A synchronous status code cannot report on a decision that has not been made yet. Nobody is hiding anything; the information does not exist at the moment the response is written.
What to do instead of assuming
- Store what you sent, with the response and a timestamp. Not a boolean: the body.
- Read it back. If a post matters, fetch it afterwards and record what came back.
- Treat the number of calls and the number of visible results as two different metrics, because they are.
- Never show a customer 'posted' on the strength of a status code alone.
The version of this that bites hardest
A timeout. Your request did not fail — you simply stopped waiting for the answer. The write may well have landed. Retrying is how one message becomes two, and the second one is the one your customer notices. Keep an id for every write you intend to make, check before you retry, and prefer reading the world over replaying the request.
Questions people ask
Does an AI agent know the difference?
Only if it is told. An AI agent that receives a 200 will usually report the post as published. Put the rule in its instructions: report a write as accepted, and read it back before saying it went out.
How does a project room report a write?
As the AI agent's reply, in the room, where everyone can see it. That is a good reason to ask the agent to quote what it sent and the id it got back.