Case study — ClaimYour.Gold
One identity, three surfaces, no fork
- Scale
- A live consumer engagement programme in continuous production.
- Surfaces sharing one identity
- Web + mini-app + services
- Trust boundaries
- 3, kept separate
- Status
- Live in production
The challenge
A programme that started as a web product added a Telegram mini-app, then needed other internal services to act on a person’s behalf. Each addition is normally where a second account table appears, quietly, and the two records disagree within a quarter.
The approach
One identity, many surfaces
Sign-in state is shared across web and mini-app rather than issued per surface, so a person is one row, not three.
A third trust boundary
Service-to-service calls carry a credential distinct from both user sessions and admin access, so another system acting on an identity’s behalf is a designed capability rather than a shared password.
Entitlement as a query, not a flag
What an identity may do is evaluated by the service at the moment of the request, so a role change takes effect immediately rather than at the next login.
The outcome
The identity layer has run without a second account table appearing since. It is now the foundation the group’s engagement and messaging surfaces build on, which is why it is packaged separately as @flashy/identity rather than left embedded in one application.
The platforms this evidences
Considering something similar?
The capability above is licensable independent of this engagement — see the platform page for what is and is not white-labelled.