Workspaces and Tenants
Workspaces, also called tenants, isolate sending configuration and operational data.
Use one workspace for one operating boundary: a company, product, brand, customer, or agency client.
What belongs to a workspace
| Item | Why it is scoped |
|---|---|
| Domains | Each brand needs its own DNS identity and reputation. |
| Senders | From addresses should belong to verified workspace domains. |
| API keys | Keys should only send for the workspace that owns them. |
| Contacts | Audiences should not leak between brands or clients. |
| Templates | Templates often include brand tone, sender information, and unsubscribe language. |
| Campaigns | Analytics and lifecycle events should stay tied to the sending brand. |
| Settings | Quotas, delivery profiles, and safety controls should be configured per workspace. |
When to create separate workspaces
Create separate workspaces when:
- You manage multiple client brands.
- A team needs isolated API keys and logs.
- A product line uses a different sending domain and reputation strategy.
- Compliance requires operational separation.
Use one workspace when:
- The same team sends from one brand.
- You only need multiple contact groups under one domain.
- You are still testing PING8 with owned recipients.
Safe operating pattern
- Create or switch to the correct workspace.
- Add only that workspace's domains.
- Create API keys for the application or team that needs them.
- Import contacts only after the domain and unsubscribe path are ready.
- Review operation logs after admin changes.
Common mistakes
- Sending a client campaign from the wrong workspace.
- Reusing one API key across unrelated brands.
- Importing contacts before suppression and unsubscribe behavior are confirmed.
- Treating a sender address as verified before the domain DNS checks pass.