Identity & accounts
Evidence for that status: Packaged as @flashy/identity, serving production traffic today across the group’s consumer network. See the case study. Read the case study →
What it does
Accounts and sessions
Sign-in across web and embedded surfaces, with one identity per person rather than one per surface.
Trust boundaries
Three separate boundaries — user session, human or cron admin, and service-to-service — because collapsing them is how privilege escalation happens.
Roles and entitlement
What an identity may do, evaluated by a service rather than asserted by a caller.
White-labelled, and not
Yours
- Brand, domain and the sign-in experience
- Role and entitlement configuration
- Session and retention policy
Not white-labelled
- Identity provider contracts where you bring your own
- Any regulatory KYC permission — we integrate a provider, we are not one
- The source code, unless a source licence is agreed separately
Integration surface
REST for identity and entitlement; a separate service-to-service key distinct from admin and user credentials; webhooks on identity lifecycle events.
Who operates what
The licensee owns the user relationship and any regulatory identity obligation. We own the software, its upgrades and its defects.
- Status
- Live in production
- Deployment
- Your cloud · ours · hybrid
- Licensing
- Annual + monthly active identities
- Support
- Tiered; SLA in contract
Publication gate: capability claims on this page are verified against the running software before publication. Lineage: Built in-house.
Reference deployment
One identity, three surfaces, no fork — Building the account system beneath a consumer programme that had to work identically on the web, inside a messenger, and from other services — without three separate account tables drifting apart.
Request a technical evaluation
Engineers on both sides, against your requirements. If the software does not do what you need, this is where you find out.