Managing five clients' social accounts from one login usually means fragile naming conventions and the constant risk of posting to the wrong brand. PostGate models each client as its own profile group — a real boundary around that client's connected profiles, schedules, and posts, not just a folder.
Create a group with POST /api/profile-groups for each client, give it their name and timezone, and connect their accounts into it. Keys can be bound to a single group so a team member or integration working on one client's content literally cannot see or touch another client's data. Offboarding a client deletes its group and dependent data in one call.
Every post carries a targets array with per-platform status, attempt count, error detail, and permalink once published — not just an aggregate "sent". Pull GET /api/posts/{id}/logs for a sanitized delivery timeline you can hand to a client as proof of work, or query GET /api/posts/stats for analytics snapshots per profile group.
PostGate's own connection screens carry PostGate's name by default. If your clients ever connect accounts themselves rather than handing you credentials, plans with the white-label entitlement let that screen — and even the underlying provider apps — carry your agency's brand instead. See white-label & BYOK.
Create their profile group, then connect their accounts — either through a hosted connection URL you send them, or by connecting on their behalf if they've shared access.
Post to every connected platform for that client through one call to POST /api/posts, or set up recurring cron and slot schedules for their regular content cadence.
Pull per-target status and delivery logs scoped to that client's profile group — the same data PostGate uses internally, not a summary you have to reconstruct by hand.
Some agencies go further and give clients their own login to a tool built on top of PostGate. That's the same tenant model — one profile group per client — wired into your own UI instead of used internally. See the social media API for SaaS page for the business case and embedding social posting for the implementation mechanics.
Create a profile group, connect a test profile, and publish a scheduled post — the full workflow runs against a pg_test_ key with no card required.