Account model
Organizations and projects
Sankofa's multi-tenant hierarchy — one organization owns many projects, and projects are the boundary for events, billing, and RBAC.
Sankofa is multi-tenant by design. Every customer gets an organization, and every organization owns one or more projects. The project is the unit of isolation for almost everything that matters: events, people, cohorts, flags, configs, deploys, replays, billing, audit logs, and the API keys that authenticate your SDKs.
This page explains how the hierarchy is laid out and how to think about modelling your team's setup against it.
The hierarchy at a glance
Organization
The top-level container. Created when you sign up. Owns billing, plan tier, SSO config, audit log, and the list of teams + members. One organization per company is the norm; large enterprises sometimes run multiple organizations for legal / data-residency reasons (see Data residency).
Project
The boundary for everything that gets queried. Each project has its own event stream, people store, cohorts, flags, configs, deploys, surveys, replays, and API keys. Two projects in the same organization share zero data.
Environment
Each project has two environments —
liveandtest— and each environment has its own API key. The engine routes ingestion to the correct environment based on the key on the request. See Environments and API keys.Team
A team is a named subset of organization members with the same project access. Teams are how you implement "the iOS team can only edit the Mobile project." See RBAC and teams.
How to model your setup
A good rule of thumb: one project per shipped product surface.
Pattern
Single product, multiple platforms
One project. Sankofa already labels every event with its source SDK (web, iOS, Android, etc.) so you can split by platform in any chart without splitting projects.
Pattern
Multiple products under one brand
One project per product. A Web app, a mobile companion, and a separate marketing site each get their own project so error volumes, billing, and RBAC are clean.
Pattern
White-label / per-customer instances
One organization, one project per tenant. Or one project plus a tenant_id property on every event, depending on whether your tenants need their own RBAC scope.
Pattern
Internal tools
Often one project — the analytics surface area is small and the same eng team owns everything.
What lives at each level
| Concept | Organization | Project | Environment |
|---|---|---|---|
| Members + teams | ✓ | ||
| Billing + plan | ✓ | ||
| Audit log | ✓ | ||
| SSO + SCIM | ✓ | ||
| Data residency region | ✓ | ||
| Events | ✓ | ✓ (live/test split) | |
| People profiles | ✓ | ✓ | |
| Cohorts | ✓ | ✓ | |
| Flags + configs + surveys | ✓ | ✓ | |
| Deploy releases | ✓ | ✓ | |
| Replays | ✓ | ✓ | |
| API keys | ✓ | ||
| Webhooks + integrations | ✓ |
The pattern: identity + governance is org-level; product data is project-level (with a live/test split per project); credentials are environment-level.
Limits
- Organizations per user: unlimited — you can be a member of any number of organizations across companies.
- Projects per organization: unlimited on every plan; some Hobby-tier limits apply on per-project event volume.
- Members per organization: unlimited on Pro and above; Hobby has a soft cap of 5 (contact us if you need more for a small team).