Hi there,

A surprisingly large portion of publishing failures has nothing to do with your code. It’s usually platform rules showing up at the worst possible moment. A post looks perfectly fine when you create it and then fails 30 seconds later when a platform finally decides it doesn’t like something.

We’ve added a bunch of additional validations so more problems are caught when you create the post, not when it’s already being published.

Some examples:

Placement validation

Facebook and Pinterest now require explicit placement identifiers (page_id or board_id). Previously the platforms sometimes defaulted to something implicitly, which could lead to “oops, wrong page” situations. Now we ask for it upfront.

Hi there,

Polling APIs is boring. And also inefficient.

Until now, if you wanted to know what happened to a post — whether it was published, failed, or retried — you had to ask the API again. And again. And again.

Now Postproxy can simply tell you when something happens.

We’ve added webhooks so your system can receive real-time events from your publishing pipeline.

You can subscribe to events like:

• post.processed

• platform_post.published

• platform_post.failed

• platform_post.failed_waiting_for_retry

• platform_post.insights

• profile.connected / profile.disconnected

• media.failed

This makes it much easier to build event-driven workflows around publishing.

For example:

• Trigger analytics pipelines when a post goes live

• Update dashboards when a platform confirms publishing

• Retry logic or alerts when something fails

• Sync publishing events into your internal systems

• Drive automation in tools like n8n or your own backend

Instead of periodically checking /api/posts, you just receive events when something actually happens.

You can configure webhooks directly in the app, or through the API.

Hi there,

Some ideas don’t fit into one post. Product updates, feature breakdowns, launch stories, long explanations. Sometimes you just need a thread.

Postproxy now supports threaded posts for X.
You can send a sequence of posts in one request and we will publish them as a connected thread.

Instead of orchestrating reply chains yourself, you simply describe the sequence and Postproxy handles the rest.

This works especially well for things like:

• product launch threads

• feature breakdowns

• changelog summaries

• educational threads

• longer narratives that don’t belong in one post

And of course you can publish threads through the same unified endpoint you already use for everything else:

POST /api/posts

We’ve opened up the Postproxy Analytics API.

You can now programmatically pull post-level performance data and use it however you want: internal dashboards, reporting tools, automation workflows, or LLM-assisted analysis.

We unify insights where possible, but we don’t assume our UI fits your mental model. Some teams want lightweight visibility. Others want full control.

With the Analytics API (and the SDKs), you can:

• Fetch unified post metrics across platforms

• Combine and transform data in your own system

• Build fully custom Postproxy dashboards

• Feed performance data directly into automation or AI workflows

Start here:

Hey!

We’ve released official Postproxy SDKs for popular languages.

Yes, you can always call the REST API directly. But most teams end up writing the same thin wrapper again and again - request builders, typing, error handling, basic helpers.

So we wrote it once.

The SDKs:

• Cover all available parameters

• Are typed where possible

• Include copy-pasteable examples

• Let you publish in minutes, just paste your API key and run it

This is especially useful if you’re embedding Postproxy into:

• Internal dashboards

• Automation workflows

• AI-driven publishing pipelines

• Backend services publishing on behalf of users

Hi there!

If you’ve worked with social media APIs long enough, you’ve seen this:

1. You send a valid request. Platform responds with “Internal error”.

2. You retry the exact same request a minute later and suddenly everything is fine.

We don’t think you should be building retry logic for every platform yourself.

Postproxy now runs smart automatic retries for transient platform failures. When we detect a failure that looks recoverable, we queue a controlled retry sequence instead of immediately marking the post as permanently failed.

You stay in control:

• The API exposes a clear status like failed_waiting_for_retry

• The UI shows that the post is retrying and when the next attempt is scheduled

• Each platform is handled independently, as always

Publishing is already complex enough. Platform instability shouldn’t become your infrastructure problem.

Hey! We’ve had a few people ask for this one, especially those running content automation or AI-driven creative workflows. It’s nice to finally say: yes, it’s live.

If you’re building tools or automations that need to publish visual content, Pinterest has always been one of those platforms that quietly matters. It’s not just “another feed” - it’s search-driven, evergreen, and heavily visual. Now you can publish Pins through the same unified Postproxy API you already use for other platforms.

What this means in practice:

• Create and publish Pins via API

• Keep your automation flows consistent across platforms

• Let Postproxy handle the platform-specific details at publish time

As always, publishing is processed per platform, with clear outcomes and proper error reporting. Pinterest now fits into that same predictable execution model.

Hey there!

We’ve shipped a new free tool: Social Calendar 2026. It’s a curated social media calendar with holidays, awareness days, cultural moments, commerce dates, plus “Sensitive” and “No Post” days so you don’t accidentally schedule something tone-deaf.

The calendar is completely free to browse and you can use it without an account.

On top of that, the same dataset is available via a public Calendar API with filtering (country, category, type, tags, date range, search) and no authentication required. You can plug it directly into your automations, content pipelines, or agent workflows.