Operator console
run the app without code.

01What the console does

• Settings → Firestore. The console is the source of truth for the app's configuration. On every save, and once at start, it writes config/public (read by the app) and config/private (read only by Cloud Functions: verification and postback secrets, store verification, revenue reporting keys). Both documents are rewritten as a whole, so values added to them by hand do not survive the next save.
• Server-side access only. It uses the Firebase Admin SDK on the server. The browser never talks to Firestore.
• Every write is audited in an append-only audit log: who changed what, and why.
• Roles. Viewers read, managers write, only owners create or rotate offer secrets and change secret settings. For payouts there is an approval step: managers approve, reject, mark manual payouts paid (after approval) and freeze; only the owner sends through the PayPal Payouts API, grants cash and changes the money settings. An optional two-person rule stops the approver from also paying the same request (who can do what).
• The console never moves money. Each payout or wallet action is one walletOps document that the backend applies once (how).
• Real counts, no estimates. The Overview shows users, active today, DAU, ARPDAU from measured revenue, day-1 and day-7 retention, the sign-up funnel, points issued and verified ads, offerwall conversions, open fraud flags and open review items. Revenue is only what was recorded with a reference. Anything not measured says so (Revenue centre).

02Environment variables

Copy admin/.env.example to admin/.env (never commit it) or set these in your host's environment.

03Run it and create the owner

cd admin
npm ci
cp .env.example .env   # fill in ADMIN_SECRET_KEY and GOOGLE_APPLICATION_CREDENTIALS
npm start              # http://localhost:8790/admin

1. Find the setup codeOn first start the log prints a one-time setup code. Each start before an owner exists prints a new one; any printed code works.
2. Create the ownerOpen /admin, choose Create the owner, enter the code, your e-mail and a password of 12 or more characters.
3. Add your teamUnder Team, add managers and viewers.

Compiled build instead of tsx: npm run build && npm run start:dist.

04Deploy options

cd admin
docker build -t watchandearn-admin .
docker run -p 8790:8790 -v wae-admin-data:/app/data --env-file .env watchandearn-admin

Put HTTPS in front of it (a reverse proxy or the platform's TLS), on its own host name. The session cookie is marked Secure over HTTPS and the server honours x-forwarded-proto. Proxy settings and sign-in problems: Sign-in and cookies behind a reverse proxy.

05Encryption keys: backup, loss and rotation

Before the detail: this product uses two separate encryption keys, and they have nothing to do with each other. You never need to understand the cryptography, only which key protects what.

• ADMIN_SECRET_KEY - your key, for the console's secrets. You create it once (openssl rand -hex 32), put it in the console's environment and back it up. It encrypts the secret values you type into the console: the ad networks' callback secrets, the offerwall and survey postback secrets, the reporting API keys, the Apple purchase key, the PayPal secret and your team's two-factor secrets. Lose it and you have to type all of those in again - nothing else breaks.
• The gift-card code key - the backend's key, for gift-card codes. You never see it, create it or enter it: the backend generates it by itself the first time you mark a gift-card payout paid, and stores it in Firestore at config/private.wallet.codeKey. It encrypts only the gift-card codes you paste in, so a code is not readable in the database. Lose it and only older gift-card codes become unreadable.

They are kept apart on purpose: rotating your console key must never destroy gift-card codes already paid out, and a database copy must never be enough to read the codes in it. Changing one key never affects the other, and both are backed up separately - ADMIN_SECRET_KEY by you, the code key with your Firestore backup. The tables below give the exact fields, file paths and what happens in each failure case.

In detail, the two keys described above:

Not encrypted with either key: passwords (scrypt hashes), sessions and two-factor recovery codes (SHA-256 hashes), and ordinary settings. Cloud Functions do not need ADMIN_SECRET_KEY: the console writes the plain secret values to config/private, which only the Functions and the console's service account can read.

If ADMIN_SECRET_KEY is lost or changed

• Every stored secret becomes unreadable. The log says [admin] secret "<name>" cannot be decrypted: was the secretKey changed? for each one, and console → Status warns that the rewarded-ad verification secret is missing.
• At the next start (and every save) the console rewrites config/private with those secrets empty. Ad callbacks and offerwall postbacks then answer 403 not configured, PayPal sends, revenue reporting and Apple purchase verification stop until you enter the secrets again.
• Two-factor codes stop working (log: two-factor secret of … cannot be decrypted). Sign in with a recovery code, then turn two-factor off and on again in Account.
• Passwords, sessions, settings, the audit log and the gift-card codes are not affected.
• Putting the old key back and restarting makes everything readable again, as long as you have not saved new values over the secrets in the meantime.

Rotate ADMIN_SECRET_KEY

The console has no re-encryption command: it reads only one key. To move to a new key, enter every secret again under the new key.

1. Confirm you have every valueTick off the list at the top of this section. Missing the Unity secret? Ask Unity support first and wait for the reply before you continue.
2. Back upCopy admin/data/ (or dump your Postgres) together with the old key, so you can go back.
3. Pick a quiet timeFrom the restart until each secret is entered again, its callbacks or postbacks are refused, and those views or offers are not credited.
4. Switch the keyGenerate a new key (openssl rand -hex 32), set it as ADMIN_SECRET_KEY and restart the console.
5. Enter every secret againAs the owner, in its section. Each save writes it to config/private; Functions use it within about 30 seconds.
6. CheckConsole → Status; the self-tests in Test the callbacks; the Test buttons of the PayPal secret and the reporting keys. Team members with two-factor set it up again.
7. Retire the old keyDelete it, and the backups made with it, once everything works.

Gift-card code key

No rotation is supported: there is one key and no code to re-encrypt stored codes. Never edit or delete config/private.wallet.codeKey. If it is removed, users see "That isn't available right now." when they open a code; the next gift card marked paid creates a new key, and older codes can then only be opened by writing the old key back. A changed key makes the older codes fail to open ("Something went wrong. Please try again.").

Backups

• Keep ADMIN_SECRET_KEY in a password manager or your host's secret store, apart from the data backups. Never commit .env.
• Back up the console database regularly: admin/data/ (with SQLite, copy it while the console is stopped, or use sqlite3 data/admin.sqlite ".backup admin-backup.sqlite") or your Postgres.
• Back up Firestore's config collection for the gift-card key, for example gcloud firestore export gs://YOUR_BUCKET --collection-ids=config. That export holds every secret in plain text: restrict access to the bucket.
• The database backup plus the key reveal every secret. Protect them like the secrets themselves.

06Settings sections

The Get started and Status screens show what is still missing. The cash-wallet sections are marked 4.0.

Kit screens beside these: Overview, Status, Team, Audit log, History and Export.

07Product pages

Users

Search by uid, display name (starts with) or referral code. Open a profile to see the last 50 ledger rows. Adjust points with a mandatory reason: the ledger row has type admin, leaderboards do not change, and a deduction can never take the balance below 0. Ban and unban: a banned user is refused by every function except account deletion.

Ledger

The latest credits across all users: type, amount, balance after, note.

Fraud flags

Open flags from verification mismatches, for example a callback for another user's session or an expired one. Review and clear with a reason; the user's flagged mark is removed when no other open flag remains.

Leaderboard

Today, this week and all time. On the sample demo console it is empty on purpose: the demo ranks no invented players.

Quizzes

Create and edit quizzes with a title, category, order, optional points per correct answer and questions with options. Correct answers are stored separately in quizAnswers, which the app can never read.

Tasks

Daily tasks with a type (ads, spins, scratches, quizzes, offers, streak or points), a target count and points. Progress is computed on the server from today's counters; each task can be claimed once per UTC day.

Offers

Partner offers with title, description, URL, points, partner and optional image. Each offer gets a postback secret, shown once. See Partner offers. Offerwalls and surveys are configured in Settings, not here.

Push campaigns

Compose a notification, pick a segment (for "Users in a team", pick the team) and a time, or send one right away to everyone. Managers and owners only. See Push campaigns.

Payouts, Wallets, Business 4.0

The payout queue with flags and actions, one user's cash balances with grants and freezing, and the measured business figures with an example calculator that is not a forecast. See Payouts, Wallets, Business.

Review queue

Held offerwall conversions (in cash mode with their cash amount) and anti-fraud alerts (device, emulator, root, VPN, velocity). Approve or reject with a note. Rejecting can also ban the user. Approving an offerwall hold makes the backend credit it once. See Review queue workflow.

Redemptions

Operator rewards users bought with points. Fulfil once you delivered it, or Reject: the points are refunded unless you untick "refund on reject". See Rewards store.

Revenue and growth

Measured revenue by source and currency, DAU, ARPDAU, retention and the funnel over 7, 30 or 90 days. See Revenue centre.

Teams

Search teams by tag, see members, disband with a reason.

Sponsors

Sponsored banners, tasks and quizzes, with daily impressions and clicks and the booking amount. See Sponsored campaigns.

Rewards store, Events, Promo codes

Store items (the Id column is the id you use for season, mystery-box and event cosmetic prizes), tournaments with live standings, and promo codes. See Engagement features.

08Public read-only demo console

To show the console to others without Firebase, run a separate instance with ADMIN_DATA=sample and ADMIN_DEMO_PASSWORD=<a password you publish>. Visitors sign in as demo@watchandearn.demo, a viewer. No owner exists, every write answers 403, every row is labelled "Sample" and the Overview tiles are marked "demo". Never set these two variables on your real console.

The sample console tells the same story as the web demo app (admin/src/sample-settings.ts, admin/src/sample.ts, cross-checked by admin/test/sample.test.ts): the same ad placements and caps, the "Sample season" of the current month, the same achievements, mystery box, games, boosters and sample walls, the same quizzes, tasks, partner offer and store items, the event "Sample weekly event", the promo code DEMO25 and the sample sponsors. It shows no revenue and ranks no invented players. The sample settings switch the wallet on, like the demo app; the Payouts page shows four example requests (ids sample-payout-…, labelled "Sample", with example.com and placeholder destinations), Wallets shows their example balances, and the Business page says "not measured" everywhere.