Adding Social Publishing to Your SaaS

Every platform except a couple of credential-based ones (Bluesky uses an app password, Telegram a bot token, Mastodon an instance URL plus token) authenticates through OAuth, and each provider has its own consent screen, its own scope list, and its own developer-app approval process. Building that yourself means registering a developer app per platform, handling each provider's redirect and token-exchange flow, and — for Meta platforms and TikTok specifically — going through app review before your customers can connect real accounts. The alternative is a hosted connection URL: your backend creates a short-lived link, redirects the customer's browser to it, and gets them back automatically once they've authorized the account, with no provider OAuth code living in your own application at all. PostGate's hosted connection flow works this way, and a third option — bring-your-own provider app — lets you plug in your own registered developer-app credentials per platform if you need the consent screen and provider-side branding to be entirely your own, while still using the hosted flow underneath.

When the customer finishes on the provider's consent screen, PostGate returns their browser to your return_url with query parameters describing what happened: connected (how many accounts got attached) and connection_platform on success, or connection_error and connection_platform if the customer canceled or the provider refused. Your settings page should handle both — a canceled connection is a normal outcome, not an error state worth alarming the customer over. From there, list the customer's profile group to render what's actually connected, including per-platform token health so you can surface a "reconnect Instagram" prompt before a scheduled post silently fails instead of after.

Past the connection screen, the feature reduces to three calls your backend makes on the customer's behalf: list their connected profiles to build a picker, create a post targeting the profile IDs they selected, and — for anything time-sensitive — read the post back (or, better, consume a webhook) to know whether it actually published. The create-post call takes a shared post body, a list of connected profiles, and optional media, and a stable Idempotency-Key so a retried request from your own backend after a timeout never becomes a duplicate post on the customer's real account.

The part that's easy to get wrong isn't the OAuth flow — it's making sure customer A's connected Instagram account can never be published to through a request that's actually acting on behalf of customer B. PostGate models this with profile groups: one group per customer or brand, owning that customer's connected profiles, schedules, and posts as a hard publishing boundary. The strongest version of this isolation is a group-bound API key — a key created with a fixed group_id that cannot read or mutate another customer's data even if your application code has a bug and sends the wrong tenant identifier in a query parameter. If your architecture issues one API key per customer at connection time, tenant isolation stops depending on your own application logic being correct on every request and becomes something the API itself enforces.

Customers expect "connect your Instagram" to feel native to whatever product they're already using, not like it hands them off to a third party mid-flow. PostGate's environments resource covers the branding surface — logo, primary color, and a verified custom domain where your plan enables it — so the hosted connection screen and its redirect chain can carry your product's name instead of PostGate's. This is a plan-gated feature, not a default, so check GET /api/platforms for what's actually enabled in your workspace before building UI around it.