Multi-tenant and embedded auth

How access is partitioned in Synter today, what you can build on it, and what is not supported yet. Read this before you put Synter behind your own product for your own customers.

The model: users, workspaces, keys

• Every key and every connection belongs to a Synter user. A user can be a member of several workspaces.
• A key can be pinned to one workspace. A pinned key only acts in that workspace, and it stops working if its user is no longer an active member there.
• An unpinned key works only for a user with exactly one workspace. If the user belongs to more than one, tool calls are refused with “This API key is not scoped to a workspace.” Pin keys to a workspace.
• Every key carries scopes. They are enforced on /api/v1/tools/run, the /v1 REST API, and hosted MCP. See Scopes & Permissions.

What you can build today

1. One workspace per client

Teams that run several clients create one workspace per client in the Synter app, and can manage those client workspaces from a parent workspace. Workspace creation needs a signed-in browser session; it is not available with an API key. Each client workspace then gets its own connected accounts, credits, and pinned keys, so a key for client A cannot read or change client B.

2. Mint narrower keys over the API

A key with workspace:write can mint child keys for the applications or agents you build. A child key is bound to the same user and the same workspace, can only carry scopes the parent already holds, and can expire after up to 365 days. The new key is shown once.

curl -X POST https://synterai.com/api/v1/keys \
  -H "Authorization: Bearer $SYNTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "reporting-bot", "scopes": ["reporting:read"], "expires_in_days": 90}'

# List keys in this workspace (workspace:read)
curl https://synterai.com/api/v1/keys -H "Authorization: Bearer $SYNTER_API_KEY"

# Revoke one (workspace:write; same user and workspace; not the calling key)
curl -X DELETE https://synterai.com/api/v1/keys/KEY_ID \
  -H "Authorization: Bearer $SYNTER_API_KEY"

3. Hand a person a connect link

A key with connections:write can create a single-use connect link (it expires in 30 minutes) for an ad platform. The account the person connects lands in the key's workspace. If the person is not in the conversation, POST /api/v1/connections/request emails the link to the workspace owner and returns a request id you can poll with GET /api/v1/connections/requests/{id}.

curl -X POST https://synterai.com/api/v1/connections/start \
  -H "Authorization: Bearer $SYNTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform": "google"}'

4. Hosted MCP

Hosted MCP accepts a workspace-pinned key in a header, or OAuth sign-in. With OAuth, the person signs in as a Synter user. To keep an MCP client on one client workspace, give it a key pinned to that workspace.

Not supported today

• Provisioning a tenant over the API. You cannot create a workspace for your end customer, or get a key scoped to it, with an API key.
• End-user identity inside a workspace. There is no external customer id that separates connections within one workspace, and no way to act “as customer X” with one platform key.
• White-label connect for people without a Synter account. Connect links and MCP OAuth assume the person is a Synter user or the workspace owner.
• A tenant header on hosted MCP. A key selects its workspace by being pinned to it; there is no header to switch workspaces per request.
• Per-customer credit caps inside one workspace. Credits and rate limits apply per workspace and per key.

If your product needs any of these, email hello@synterai.com with your use case.

Related

• Authentication: accepted headers on each surface.
• Approval model: which writes wait for a person, and who approves.