Platform overview

Project Trident · Guest Activation Platform

FINNS has millions of guest records but almost no relationship with the people behind them. Trident gives guests a reason to identify themselves: sign in once, and every visit, booking and in-app activity is tied to one member and earns points. The name comes from the shape of the platform: several guest touchpoints, one shared backend.

The platform at a glance

People

GuestMember once signed in

StaffGuest services, admins

Touchpoints

FINNS PassApple/Google Wallet

Guest appFlutter (mobile app + web)

Booking websiteCTG

Gate scannerVendor TBD

Admin consoleSvelteKit

Trident platform

API

LoyaltyPoints ledger and membership

AssetsWallet balance, wristbands

AccessesGym

Relationships

ReservationsEvents

Transactions

Customer PII

Services

Guest identityKeycloak

Staff identityJumpCloud

Transactional emailAmazon SES

Payment gatewayAirwallex

POSShiji

PMSDaylight

Customer engagementSota Platforms

CDPInsider

Who owns what

The clearest way to understand Trident is to know which system has the final say on each piece of data.

flowchart LR
  classDef ours fill:#13686C,stroke:#0B4A4D,color:#ffffff
  classDef ext fill:#F3ECDF,stroke:#B9A88B,color:#12191B

  KC["<b>Keycloak</b><br/>guest accounts<br/>passwords, sign-in sessions"]:::ext
  CORE["<b>Core</b><br/>who is a member<br/>points balances and ledger<br/>one-time codes, check-ins"]:::ours
  SOTA["<b>Sota Platforms</b><br/>rewards, raffles, campaigns<br/>the widgets guests play with"]:::ext
  BOOK["<b>Booking engine</b><br/>availability, bookings<br/>payment for bookings"]:::ext
  GATE["<b>Gate</b><br/>scanning at the entrance"]:::ext

  KC -- "account changes" --> CORE
  SOTA -- "credit / debit points" --> CORE
  BOOK -- "paid booking" --> CORE
  GATE -- "scanned QR" --> CORE

Data	Owner	Everyone else
Guest account, password, sign-in session	Keycloak	Core keeps a read-only copy of name and email
Membership and identifiers	Core	Each partner gets only the id it needs (a external id for engagement), never a password or token
Points balance and every posting	Core	Partners post through the API and mirror the balance
Rewards, raffles, campaigns: the “how” of the program	Sota Platforms	Core only sees the resulting postings
Bookings and their payment	Booking engine	Core only learns “booking X was paid, total Y”

Design principles

One member, one identity

Guests sign in with one FINNS account (Keycloak) everywhere. Partners never run their own sign-up.

Tokens never leave home

The app never hands its access token to a partner. It hands over a one-time code that the partner exchanges server to server, so a code in a URL or log is worthless after a minute.

The ledger is the truth

Points live in a double-entry, append-only ledger. Every posting is idempotent and traceable to who made it: a partner, staff, or core itself.

Partners see as little as possible

Each partner gets only what its job needs. Sota Platforms sees an opaque external id, never a name or email.

Sign out means everywhere

Signing out of the app signs the guest out of the booking site and the widgets too, through revoke callbacks.

When in doubt, say no

If a check can’t be completed (core unreachable, code unknown), the answer is “no”. Nothing is ever let through by default.

Where to go next

• How guests sign in: the identity flow every integration builds on.
• Integration conventions: authentication, errors and idempotency, common to every API.
• Glossary: the words used across this portal.