Publishing to social networks is not an API problem

We thought publishing would be the easy part

When we started building 64ads, we genuinely thought publishing would be the easy part. 64ads is an AI-driven system that generates marketing assets at scale — banners, social posts, product visuals. Not one or two creatives, but entire batches. The hard problems were obvious: models, prompts, layouts, brand consistency, orchestration. We spent months solving those, and eventually, that part worked. Publishing, by comparison, felt like a footnote. Once the content is ready, you just send it to the platforms.

Where things quietly started to break

The first cracks didn’t look dramatic. A post would fail on one platform but succeed on others. Sometimes everything looked successful, yet nothing showed up. Sometimes retries worked. Sometimes they duplicated posts. Sometimes the API said “ok” while the UI said nothing. Sometimes the error arrived minutes later, long after the workflow had already moved on. Nothing failed consistently. Nothing failed loudly. That made it worse.

Treating it as an integration problem

Our first instinct was predictable: integrate better. We tightened validation. Added platform-specific conditionals. Built branching logic. Added retries. Then retries for retries. Then special cases for the special cases. What looked like “just publish this post” slowly turned into a maze of defensive logic. At the time, this felt responsible. In hindsight, it was a warning sign.

The uncomfortable realization

Eventually, it became clear that nothing here was actually broken. The platforms behaved exactly as they were designed to behave. Each one had its own rules, limits, quirks, timing, and failure modes. Some failures were synchronous. Some were delayed. Some were permanent. Some were ambiguous. Partial success was not an edge case. It was the default. Publishing wasn’t a request–response interaction. It was an operational process.

Our workflows assumed determinism. They assumed that a successful step meant progress, that an API response represented reality, and that failure was exceptional. But publishing sits at the boundary between your system and a set of external systems you don’t control. At that boundary, guarantees disappear. You don’t call an API and get a result. You submit an intent and later observe outcomes. The more automation we added upstream, the more fragile everything became downstream. Ironically, the most advanced part of the system — AI-driven content generation — was the most stable. The simplest part — “publish this” — was where everything kept failing.

Extracting the problem instead of fighting it

At some point, it became obvious that this couldn’t be fixed by adding more logic inside workflows. Workflows were the wrong place to carry platform complexity. They needed a stable boundary — a layer whose only responsibility was to deal with the messy reality of publishing.

So we stopped trying to integrate better and started extracting the problem. We built an internal abstraction that took a generic publishing intent, handled platform-specific behavior, retries, and partial failures, and reported back what actually happened. Not “success”, but outcomes. Per platform. Explicitly.

Why Postproxy exists

That internal tool eventually became Postproxy. Not because we wanted another product, but because the system demanded it.

Postproxy exists because publishing to social networks is not an API problem. It’s an operational problem that deserves its own boundary, semantics, and failure model. Once we accepted that, everything upstream became simpler. Workflows became shorter. Automation became predictable. Failures became observable instead of mysterious.

This isn’t a launch announcement. It’s an explanation of why a thing like Postproxy needs to exist at all.

If you’ve ever built automation that works perfectly right up until the moment content hits a social network, you’ve already met this problem. You just might not have named it yet.