If your product serves marketers, agencies, or e-commerce sellers, they eventually ask for social publishing. Building that yourself means OAuth flows for a dozen platforms, retry logic, and a multi-tenant data model. PostGate is that layer: one API, connected through your product, with each of your customers isolated in their own publishing boundary.
A profile group is the durable publishing boundary for one customer, brand, or workspace — it owns that customer's connected profiles, schedules, posts, and group-bound keys. Create one per tenant with POST /api/profile-groups, and store its id next to your own tenant identifier.
Bind a key to a group_id and it is permanently scoped to that group — it cannot read or mutate another customer's data, even if your application code sends the wrong parameter. Scope each key to read, publish, or full depending on what your product needs it to do.
PostGate's default connection screens carry PostGate's name. On plans with the white-label entitlement, that experience — and the underlying provider apps for Meta, TikTok, and LinkedIn — can run under your brand instead. See white-label & BYOK for what that unlocks and which plan it's on.
Customers already draft content in your product — let them schedule and publish it without leaving, instead of exporting to a separate scheduler.
Turn product drops, listings, or campaign milestones into social posts triggered from events already happening in your system.
The same tenant model that isolates your customers works for isolating clients. See PostGate for agencies if that's the shape of your product.
This page covers why a scheduling API fits into a multi-tenant SaaS product. For the actual wiring — hosted connection URLs, the unified post endpoint, webhooks versus polling — see embedding social posting into your product.
Create a profile group, issue a group-bound key, and connect a test profile — all against a pg_test_ key with no card required.