Hey!

Postproxy now supports Google Business.

You can publish local updates to Business Profile locations through the same API you already use for other platforms. That includes:

• regular updates

• events with start and end dates

• offers with coupon codes, redemption links, and terms

Google Business is a bit different from social feeds. Posts are attached to a specific business location, so every request targets a location_id. If one connected profile manages multiple locations, Postproxy lets you pick exactly where the update should go instead of pretending “the right one” will somehow reveal itself.

A simple update looks like this:

curl -X POST "https://api.postproxy.dev/api/posts" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "post": {
      "body": "We are now open on Sundays from 10am to 4pm."
    },
    "profiles": ["google_business"],
    "platforms": {
      "google_business": {
        "format": "standard",
        "location_id": "accounts/123456789/locations/987654321",
        "cta_action_type": "LEARN_MORE",
        "cta_url": "https://example.com/opening-hours"
      }
    }
  }'

You can also publish events and offers with the same endpoint. The format changes, the general model does not. That is how software should behave, though reality keeps filing objections.

Google Business support also comes with review management. Reviews are available through the Profile Comments API, and you can reply to them programmatically from Postproxy. In other words, for Google Business, “comments” are your customer reviews.

Hey!

We added profile-level stats to Postproxy.

Post analytics tell you how a specific piece of content performed. Profile stats answer a different question: how is the account itself doing over time?

You can now fetch metrics like follower counts, audience size, page views, reach, engagement, and other profile-level numbers exposed by each platform. The exact fields vary by network, because naturally every platform had to invent its own version of reality, but the API shape stays predictable.

Example:

curl -X GET \
  "https://api.postproxy.dev/api/profiles/prof_li_001/stats?placement_id=108520199&from=2026-04-01T00:00:00Z" \
  -H "Authorization: Bearer YOUR_API_KEY"

The response gives you a time series of snapshots:

{
  "data": {
    "profile_id": "prof_li_001",
    "platform": "linkedin",
    "placement_id": "108520199",
    "records": [
      {
        "stats": {
          "followerCount": 4500,
          "shareCount": 8,
          "likeCount": 80,
          "allPageViews": 12000
        },
        "recorded_at": "2026-05-09T08:00:00Z"
      }
    ]
  }
}

Snapshots are collected roughly once a day, which makes this useful for:

• reporting dashboards

• tracking follower or audience growth

• monitoring profile health across clients or brands

• comparing account-level trends with individual post performance

For placement-based networks such as Facebook, LinkedIn, and Telegram, stats are scoped to a specific page, organization, or channel via placement_id. Other networks return profile-level stats directly.

We also added a new profile details page in the app.

Open any connected profile and you’ll now see its current status, total posts, recent publishing health, and the latest available performance snapshot in one place.

Hey!

Postproxy now supports Telegram.

This one works a little differently from most other platforms. Telegram does not offer a normal “connect your account and post” flow for channels, so we went with bring your own bot.

You create a bot in Telegram, connect it to Postproxy once, and publish to any channel where that bot has admin access. Your bot, your channels, your branding. No random third-party bot quietly sitting in the admin list like it pays rent.

Once the bot is connected, Postproxy keeps track of the channels it can publish to. Add the bot as an admin, fetch placements, pick the chat_id, and send the post.

Example:

curl -X POST "https://api.postproxy.dev/api/posts" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "post": {
      "body": "<b>Latest update</b> — check it out"
    },
    "profiles": ["telegram"],
    "platforms": {
      "telegram": {
        "chat_id": "-1001234567890",
        "parse_mode": "HTML",
        "disable_link_preview": true
      }
    }
  }'

A few useful details are already covered:

• publish plain text or use HTML / MarkdownV2 formatting

• send posts silently with disable_notification

• turn link previews off when they get in the way

• attach up to 10 images or videos as a Telegram media group

• publish to different channels from the same bot by changing chat_id per post

Telegram fits nicely into Postproxy’s usual model: one API surface, platform-specific details kept in one place, fewer reasons to maintain a small private museum of edge cases.

Hi there!

Postproxy now supports Bluesky.

You can publish regular posts, attach images or video, and create threads through the same API you already use for other platforms. Bluesky itself is pleasantly straightforward from the product side, so we kept our interface that way too. No pile of platform-specific settings to wrestle with before sending a post.

Under the hood, there is still enough machinery to keep things interesting: Bluesky runs on the AT Protocol, uses app-password authentication for API posting, expects mentions, hashtags, and links to be encoded as facets, and handles link cards and media embeds in its own particular way. Postproxy takes care of that layer so you can keep sending normal post payloads instead of becoming an amateur protocol historian.

A basic Bluesky post looks like this:

curl -X POST "https://api.postproxy.dev/api/posts" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "post": {
      "body": "Hello from Bluesky via Postproxy."
    },
    "profiles": ["bluesky"]
  }'

Hey!

We reworked the post creation page in the app.

The old flow did the job, but once you added media, multiple platforms, platform-specific settings, scheduling, or a thread, the page started to feel more like a configuration form than a place to publish something.

The new version is much easier to follow.

The composer stays focused on the post itself: text, media, and thread structure. Profile group and platform selection sit below it, with platform-specific settings grouped where they belong instead of competing for attention. On the right, a compact summary shows exactly what will be published, where, and when.

A few things are noticeably better now:

• media is easier to add and review

• thread creation is more obvious

• platform-specific options are easier to scan

• publishing mode is clearer: post now, save as draft, schedule, or add to a queue

• the final summary makes it harder to publish to the wrong place by accident, which remains a popular human hobby

Hey!

We’ve reworked the webhook creation flow in the app.

Postproxy has accumulated quite a few webhook events by now: publishing updates, retry states, profile changes, comments, media failures, and more. That is useful, right up until creating a webhook starts to feel like reading a permissions matrix at 11 PM.

The new setup makes this much easier to scan.

Events are now grouped by what they relate to, so you can quickly pick what your app should actually listen for instead of working through one long undifferentiated list. Want publishing events only? Easy. Need profile connection changes? Also easy. Building around comments? Those are in their own place too.

This matters because webhooks are usually the point where Postproxy becomes part of a larger system. They let your app react immediately when something happens, for example:

• a post gets published or fails

• a retry is scheduled

• a profile disconnects

• a new comment comes in

The event model itself has not changed. We just made the configuration less annoying, which is a feature category software tends to underinvest in for mysterious reasons.