Dashboard & access

The admin panel (apps/admin, port 3001) is where the operations team runs the platform. This page covers the landing dashboard and, more importantly, the access model that decides who can do what.

The dashboard

The home screen is an operational snapshot rather than a marketing page. It leads with the numbers that matter day to day — total players and recent signups, total wagered, house profit and edge, and active players in the last 24 hours — and surfaces a warning banner when withdrawals are waiting to be processed.

Below the stats sit quick links into the busy areas (players, games, withdrawals, bonuses, support, marketing), a live activity feed that polls for fresh signups, deposits, withdrawals, and big wins, and a short list of the top games by volume.

Access model

Access is enforced in layers, and understanding them explains why a page might load for one admin but not another.

1. Middleware gates the whole panel. Every route except login, the unauthorized page, and a couple of public endpoints requires an admin session. No session, no entry.
2. The sidebar hides navigation a person can't use. A nav item only appears if the admin holds at least one of its permissions.
3. A few pages also hard-block at the server and redirect to an unauthorized screen — loyalty, segments, and admins do this.
4. Every admin API call is wrapped so it checks the session, verifies the required permission, runs the handler, and writes an audit entry on a successful change. This is the layer that ultimately protects the data, regardless of what the UI shows.

The practical takeaway: the sidebar and the API are the authoritative gates. Most pages rely on those two rather than blocking the page render itself.

Roles and permissions

Permissions are fine-grained slugs like players.view, players.edit, payments.manage, or bonuses.templates.manage. A role is a named bundle of those slugs, stored in the database.

One role is special: a seeded superadmin that is marked as a system role, carries every permission, and bypasses all checks. Beyond that, operators create custom roles and tick the permissions each one should have, grouped by domain. The superadmin flag can't be granted through the UI — it only exists on the seeded role.

A quick map of which permission opens which area:

Area	Permission to view	Permission to change
Dashboard activity	dashboard.view	—
Players	players.view	players.edit
KYC documents	players.documents.view	players.documents.manage
Balance corrections	—	balance.correction.manage
Segments	players.view	players.edit
Games catalog	games.view	games.manage
Bonus templates	bonuses.templates.view	bonuses.templates.manage
Loyalty program	loyalty.view	loyalty.manage
Withdrawals	players.payments.view	payments.manage
Marketing / UTM	—	cms.manage
Cashback	cashback.view	cashback.manage
Quests	quests.view	quests.manage
Wheels	wheels.view	wheels.manage
Traffic qualifier	cms.manage	cms.manage
Support	support.view	support.manage
Support staff	support.staff.view	support.staff.manage
Admins	admins.view	admins.manage
Roles	—	roles.manage
Audit log	admins.logs.view	—

The permission catalog is broader than the panel currently uses — there are slugs reserved for limits, payment geo rules, and other features that may not have dedicated docs pages yet.

Admin accounts and the audit log

The Admins area manages the back-office accounts themselves. It has three tabs: a searchable list where you create admins and assign roles or reset passwords, a roles editor with the permission matrix described above, and an audit log.

The log is worth calling out. Because every mutating API call writes an entry, the log gives a chronological record of who did what — the actor, the action, the entity touched, and a timestamp — with sensitive fields like passwords redacted. It's the answer to "who changed this?"