Postproxy is a social media API for products that need more than publishing. Publish posts, manage comments, DMs and reviews, track post and profile analytics, and receive webhooks across major platforms. Built for SaaS products, automation workflows, and agents that need reliable social media infrastructure without maintaining every platform API themselves.
Postproxy is a social media API for products that need more than publishing. Publish posts, manage comments, DMs and reviews, track post and profile analytics, and receive webhooks across major platforms. Built for SaaS products, automation workflows, and agents that need reliable social media infrastructure without maintaining every platform API themselves.
Ayrshare had better UX and more platform choices, but postproxy was not charging an arm and leg for their service and covered all the major platforms I needed. I am very glad I switched.
Hey Product Hunt 👋
We launched Postproxy here a few months ago. Back then it was mostly about publishing. We solved the basic but painful problem of posting reliably across platforms, and that layer is still the foundation.
However, publishing a post is not the end of a social workflow. People comment, ask questions in DMs, and leave reviews. Someone has to read that, react somehow, or plug it into the product where the rest of the work already happens.
That is what this launch is about: Postproxy has moved beyond the publish button and now has an engagement API.
You can fetch comments, reply to users, read and send direct messages, and work with reviews through the API. So if you are building a social inbox, a support flow, a moderation tool, a customer dashboard, or an agent that needs to touch social platforms, you do not have to wire every platform yourself.
Of course, things like post stats, profile analytics, webhooks, and the rest of the plumbing are there too. And you can use Postproxy from your backend, automation tools like n8n, Make, Zapier, or Needle, or from whatever agentic setup you have through MCP.
If you have built anything around social APIs before, I'd love to hear where it hurt most.
Cheers,
Dmitry
Most "social media API" products mean Twitter/X plus maybe LinkedIn if you're lucky, with read access that breaks every time a platform updates its terms. Curious which platforms Postproxy actually covers right now and whether you're using official APIs throughout or a mix that includes anything scraping-adjacent. The analyze side is also where I'd want more detail: are we talking raw metrics pulled from native analytics endpoints, or is there some aggregation and normalization happening so you can compare performance across platforms without doing that work yourself?
No scraping or scraping-adjacent stuff - we only use official APIs, properly verified and approved flows.
Right now we cover 11 platforms: Instagram, TikTok, LinkedIn, X, YouTube, Facebook, Threads, Pinterest, Bluesky, Telegram, and Google Business. Reddit is coming soon.
Small note on X: because of their pretty aggressive API pricing, we keep X more limited in the base plans and offer pay-as-you-go and bring-your-own-key options for products that need heavier X usage.
As for the analytics, we pull data from the native analytics endpoints and expose it through an API, again, no scraping or guessing ourselve. And we do normalise the structure so the metircs are a bit more consistent across platforms.
Report
The hidden cost of social media integrations isn't building them - it's maintaining them when platforms quietly change OAuth flows, add permission scopes, or drop API endpoints. Is that the maintenance burden Postproxy is taking on? If so, that's actually the valuable part. Curious whether you're absorbing Instagram's graph API versioning cycles and TikTok's business API quirks on behalf of developers, or leaving those edge cases to the caller.
@galdayan Hi Gal, that is exactly the main point - you don't need to worry about Meta's or TikTok's quirks, it is on us.
Report
Congrats on moving beyond just publishing! To answer your question about where it hurts most: for me, it’s always been handling webhooks and unified payloads for DMs. Every platform formats a message or a comment completely differently, so writing the normalization layer is exhausting.
Having a single Engagement API that handles the plumbing for comments and DMs under one roof is a massive time-saver for anyone building SaaS toolboxes. Best of luck with the launch today!
We are big proponents of webhooks and tried to make them as easy to use as possible in Postproxy. They still feel kinda underrated, but once volume grows they are super useful and save a lot of unnecessary polling.
Report
to answer your question: rate limits and silently dropped webhooks are by far the worst part of building custom social integrations. abstracting that away is huge.
how are you handling platform rate limits when fetching comments during a viral spike? awesome update.
@wilder_dev Thanks the comment! Yeah, processing webhooks looks simple until it goes to real production :) To handle spikes and platforms downtime we have a fancy back pressure system in place that takes care of that.
Report
For me the pain was always video. Posting text or an image reliably is one thing, but every platform handles video upload and processing differently, with async transcoding and a status step that fails quietly. Does the publish API roll that into one flow, or do I still poll each platform to know a Reel actually went live?
@yannikga There's no difference what you post via Postproxy – text, image, carousel, video. The API is absolutely the same for every platform and every format and we take care of what you mentioned. Give it a shot! ;)
And answering your question of "do I still poll each platform.." - no, there is no need to poll each one. Calling GET /api/posts/:id will return per-platform status. Alternatively (and ideally) you can subscribe to post-related webhooks, i.e. platform_post.published fires when it actually went live or platform_post.failed in case something goes wrong.
Report
The jump from reliable cross-platform publishing to a reply-and-analyze API is the part that actually closes the loop for community ops, since posting was never the hard half, keeping up with replies across platforms is. For the engagement side, does the API surface inbound comments and DMs with a stable per-item ID, so a team can build a reply-once workflow without two people double-answering the same comment? That dedupe guarantee is the thing that would decide whether I could put this in front of a real community team.
@hazy0 Yes, you can quickly and easily build reply-once logic on top of Postproxy API. If you need any assistance with that we're always happy to help.
Postproxy
Thanks a lot for the feedback! Much appreciated!