> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.
# App users
> Manage the drivers signed up to your branded app, and what they can charge with.
An app user is a driver who has an account in Spirii Go or a branded app, and the record in Connect that holds their details, payment methods, and charging history.
## Overview
An app user is created when a driver signs up in an [app](/capabilities/driver-experience/spirii-go-and-branded-apps), or by an [onboarding flow](/capabilities/automation/onboarding-flows) — the web ordering journey where a driver orders a charger, a subscription, or a token. The record itself is light. A name, contact details, and a creation date are all it holds directly, and its value comes from what attaches to it: the tokens the driver charges with, the cards they pay with, the home charger they control, and their session history.
In Connect, App users is where you find a driver, confirm what they can charge with, and see what they have used.
## Context
An app user belongs to the partner whose app they signed up in. The driver sets that boundary at sign-up when they accept the app owner's terms and conditions, and Connect enforces it: only the partner who owns the app can see the record. Where an onboarding flow has associated the user with a customer, that customer can manage them too.
You can delete an app user from Connect. When a driver deletes their own account in the app, an anonymised identifier is all that remains on their charge detail records (CDRs), so session and billing history stays intact without the person attached to it.
An anonymised identifier is also what appears when a driver from another partner's app charges on your locations. Their account sits behind that partner's boundary, so the session is attributed without the driver being exposed to you.
There is no app user over [roaming](/capabilities/roaming/roaming-connection). A driver reaching another network appears there as a [token](/components/access/tokens), and nothing about the account behind it crosses the boundary.
## Key attributes
| Attribute | Description | Example |
| ------------ | ------------------------------------------------------------------------------- | ------------------------ |
| ID | Unique identifier for the app user | `48213` |
| First name | The driver's given name | `Lena` |
| Last name | The driver's family name | `Weber` |
| Email | The address the account is registered to | `lena.weber@example.com` |
| Phone number | Optional contact number | `+49 151 2345 6789` |
| Newsletter | Whether the driver opted in to marketing email at sign-up | `true` |
| Created | When the account was created | `14 Feb 2026` |
| App | The app the driver signed up in, which controls who can see the record | `Acme Charging` |
| Customer | Optional. The customer that can also manage the user, set by an onboarding flow | `Lindenhof Housing` |
A driver who signs up in the app on their own has no customer set. Spirii support can assign one on request, but in practice the onboarding flow that created the account makes the association.
## Relationships
The first two fields above scope who can see and manage an app user. Everything else about the driver hangs off the record.
```mermaid theme={null}
flowchart TD
A("App\nSpirii Go or a branded app") --> AU("App user")
AU --> T("Tokens")
AU --> CC("Credit cards")
AU --> V("Vouchers")
AU --> RL("Residential location\nhome charger")
AU --> SE("Sessions and CDRs")
```
### Tokens
A driver can hold several [tokens](/components/access/tokens), and each token belongs to at most one app user. To move a token to a different driver, unbind it from the current one first. You can make the link from either side in Connect, from the token or from the app user, and a driver can add a token themselves in the app when it arrives.
Tokens do not need an app user at all. A fleet operator running a pool of RFID tokens shared across vehicles leaves them unassigned.
### Credit cards
A driver's saved cards appear in Connect as the card brand, the last four digits, and the expiry date. The card details themselves stay with the payment provider and are never stored in the Spirii platform, so this is the full extent of what Connect shows.
### Vouchers
A [voucher](/components/access/vouchers) appears on an app user's account once the driver enters its code in the app. The voucher group behind it sets which locations that driver can use, and on what price conditions.
### Residential locations
An app user attached to a residential location — a driver's home, shown in Connect under Locations — can control the charger there: charging schedules, authentication, and the charger's other settings. More than one app user can be attached to the same residential location, which is how a household shares a charger, though most have a single user.
An onboarding flow creates the location, the customer, and the app user together and binds them, so a driver who ordered a home charger arrives with the attachment already in place.
### An app user is not every driver
Plenty of charging happens without one. All of these produce sessions and CDRs on your network:
| Who charged | What you see |
| ------------------------------------------ | ------------------------------------------------ |
| One of your app users | The app user, with their details |
| A driver from another partner's app | An anonymised identifier, and no app user record |
| A driver who has deleted their account | An anonymised identifier |
| A driver charging anonymously in Spirii Go | No user |
| A shared fleet token | The token, with no app user behind it |
On a public network, most sessions will have no app user attached, and the CDR is still complete for billing and reporting.
## Used in
Each app user's charging is recorded as CDRs. See [Sessions and CDRs](/components/charging/sessions-and-cdrs) for how those records are structured and billed.
The charging history attached to each driver.
What a driver authenticates and charges with.
The party that can manage a user alongside the app owner.
Access and pricing granted to a driver's account.