Tenancy, roles and scopes
Woltti is multi-tenant: municipalities and energy companies (operators), optionally with partner organisations under them, share one platform. The security model does the isolation for you.
You never filter by tenant
Your API key belongs to one organisation, and every query is scoped to it automatically on the server. There is no tenant parameter to pass, and no way to widen the scope: a sessions list returns your sessions, a stations list your stations. If your organisation has partners, their records nest under yours the same way they do in the operator portal.
Roles
The platform's role vocabulary applies to keys exactly as it applies to people:
| Role | A key with it can |
|---|---|
Accountant | Read-heavy work: sessions, receipts, billing data, audit trail, plus the read side of most areas |
CompanyAdmin | Everything the organisation's admin can do over the API |
The role is the ceiling; scopes narrow within it. A CompanyAdmin-role key with only charging-sessions:read can read sessions and nothing else.
Scopes
Scopes are area grants in the form area:read or area:readwrite, comma-separated:
charging-sessions:read,charging-stations:read,data-hub:read
| Scope | Covers |
|---|---|
charging-stations | Stations, EVSEs, station operations |
charging-sessions | Sessions, session receipts, session interventions |
locations | Sites, opening hours, images |
tariffs | Tariffs, electricity contracts and sellers |
users | User accounts, teams |
assets | Meters, batteries, solar inverters, payment terminals, circuits |
smart-charging | Smart-charging policies and schedules |
billing | Invoices, licenses, subscriptions, documents |
data-hub | Reports, data and export endpoints |
audit | History / audit-trail reads |
Every endpoint's required scope is stated in the API reference. One honest note: scopes bound endpoints, not response fields — a sessions response still embeds, say, station names.
Everything is audited
Actions performed with a key appear in the organisation's audit trail with the key's name as the actor. Name keys after the integration, not after a person — your future auditors will thank you.