Customers never need to know PostGate exists. They connect accounts and schedule posts inside your UI; your backend talks to one API underneath. This page is the wiring diagram — for the business case behind embedding a publishing feature at all, see the social media API for SaaS page.
Register your product's origin once with POST /api/connect-origins, then create a short-lived connection URL with POST /api/profiles/connect and send the customer to it. They authorize the platform and land back on your return_url — to them it never left your product.
Your composer collects body text, media, and target profiles, then calls POST /api/posts once. Provider-specific fields — a Pinterest board, LinkedIn visibility — go under post.options.<platform>, and body_overrides lets one target carry different copy without a second request.
Subscribe to webhooks for terminal delivery events instead of building your own polling infrastructure. If you do poll, read targets on GET /api/posts/{id} — each one carries its own status, attempt count, error, and permalink — and stop once every target is terminal.
Call the connect endpoint from your backend, get back a URL, and redirect. No OAuth app of your own required to start — PostGate's shared provider apps cover every plan.
GET /api/profiles gives you what to show as connected accounts. Check GET /api/profiles/{id}/health before letting a customer publish, and prompt a reconnect in your own UI if a token needs refreshing.
The same POST /api/posts call publishes immediately, saves a draft, fires at a fixed scheduled_at, or joins a recurring queue — your UI just changes which fields it sends.
Register a test origin, create a hosted connection URL, and publish a test post — the full loop runs against a pg_test_ key with no card required.