Multi-org social media management without client account leaks

Start with the access model, not the scheduler

The safe pattern is boring, which is usually a good sign: give each client access only to its own organization or account scope, not a shared login. That way, one client cannot wander into another client’s connected accounts, posts, or delivery history like it owns the place.

TimeToPost’s docs say the REST API is “scoped to your active organization,” and the MCP server works under your account permissions, with org scoping and validation enforced by the backend. The MCP page also says a tool call “carries your authorized access” and that an agent “can never do more than your own account can.” In other words, the guardrails are already there, if you keep the org boundaries intact. API reference MCP server

Use separate organizations or clearly separated account groups

The operational rule is simple, even if the setup UI tries to make it feel like a group project: each client should live in its own active organization or equivalent isolated workspace. TimeToPost scopes API requests to the active organization, so if you keep Client One and Client Two in separate orgs, their data stays separated at the source.

The same idea applies to MCP connections. The hosted MCP server works under the authenticated user’s permissions, so the user you connect matters. If the connected user only belongs to one client org, the agent only gets that scope. Clean separation beats heroic tab management. API reference MCP server

What to expose in the dashboard, and what to keep private

For agency clients, the minimum safe visibility is the stuff they actually need to review: posting status, schedules, draft approval flow, and their own connected accounts.

Keep other clients’ integrations and delivery history out of reach unless they belong to the same org. TimeToPost’s API lists posts for the active organization, and the webhook docs say every member can read delivery history for that org. So the key is not to expose “everything,” just the slice that matches the client’s own org. If the client should not see another brand’s integrations, do not put both brands in the same org and call it collaboration. That is how gremlins get a seat at the table.

Permission setup for owners, admins, and members

The documented permission boundaries are useful here. According to the webhook docs, org owners and admins manage webhook endpoints, while every member can read the delivery history. The API docs also say API tokens cannot create or revoke other tokens, which cuts down on accidental permission sprawl and the usual “who made this key and why does it still exist” chaos.

For agencies, that means you can keep admin-level control with the team that actually maintains the setup, while giving clients a narrower role that supports review without exposing unrelated work. Webhooks API reference

Worked example: one agency, two clients, no cross-account visibility

Hypothetical setup:

• Agency A creates one active organization for Client One and a separate active organization for Client Two.
• Each client gets a dashboard session tied only to its own org.
• Agency A uses an org-scoped API token for each org, or connects an MCP client under the right authenticated account.
• Client One can see Client One’s drafts, schedules, connected accounts, and webhook deliveries.
• Client Two can see Client Two’s version of the same.
• Neither client can see the other client’s posts or integrations, because those live in a different org.

If Agency A uses the REST API, GET /api/posts returns posts in the active organization, and POST /api/posts creates posts in that same scope. If it uses MCP, tools like list_posts, list_integrations, schedule_post, and approve_draft also run under the active org and the authenticated user’s permissions. Same moat, different front door.

Safer handoff options when clients need to review work

When a client needs to review content, do not hand over a broad shared admin login and hope nobody clicks the wrong thing. Hope is not a permission model.

Use drafts, approvals, and scheduled posts instead. TimeToPost supports drafts by omitting scheduledAt in the API, and the MCP server includes create_drafts for drafts that wait for human approval and approve_draft for the review step. The webhook docs also include draft.approved and draft.rejected events, which makes the review flow easier to track without opening up unrelated accounts.

That gives clients the part they need, approval, without the “also here are all your other agency accounts” surprise.

If you are automating access, route it through the official API or MCP

TimeToPost’s REST API and MCP server are the supported ways to script or agent-enable these workflows. The API is the same one the dashboard uses, and the MCP server is a thin adapter over that same backend. So if your workflow needs automation, use those paths and let the org scoping do its job.

For deeper setup details, the MCP page is the place for agent-based access, and the API reference is the place for org-scoped scripting. MCP server API reference

Quick implementation checklist

• Create separate orgs, or equivalent isolated workspaces, for each client.
• Invite the right role for the right person, and keep client access narrow.
• Connect only the accounts that belong to that client’s org.
• Test what a client can see before you go live, especially posts, integrations, and delivery history.
• Verify webhook visibility and delivery history behavior in the right org before handoff.
• If you automate anything, use the official API or MCP connection tied to the correct org.

Related setup guides

If you are wiring this up with an agent, the TimeToPost MCP page shows how to connect a client under the right permissions. If you are scripting the dashboard behavior, the API reference documents the org-scoped request model that keeps client accounts separated.