#End-to-end user flows

Each flow shows the visual path, then the written steps with the system responsible at each step. FE = Central frontend, BE = sa-central-api-2, OSS = the server's panel API.

#New user

1. FE shows the register form (name, email, password, Turnstile, optional codes). BE validates and creates an inactive account. V8 requirement 2.1
2. The user clicks the email link. BE activates the account (24 h validity). V8 requirement 2.2
3. Login. BE returns token, user and an empty organizations list. V8 requirement 2.3
4. FE shows "Create your organization". BE creates it with owner + admin roles and the user as Owner. V7 only
5. Plan step: not decided for V8 Open question. In V7 a Free/trial plan is created without payment.
6. FE loads subscription + usage and lands on the Dashboard empty state.

#Existing user

1. Login (2FA / IP check if enabled). BE returns token, user and organizations. V8 requirement
2. FE restores the last-used organization if the user is still a member, otherwise the main one, otherwise the first.
3. FE loads the organization's subscription, plan limits and usage from BE Missing, then the dashboard.

#Upgrade plan

1. FE shows the current plan + usage (from BE) and the plan catalog (from BE, never hard-coded). Missing plans API
2. The user picks a plan and cycle. BE quotes the amount (proration/credit, tax, promo). In V7 remaining-credit and discount-percentage exist. V7 only
3. Checkout. In V7 the plan is paid from wallet credits. If credits are short, the user tops up through a gateway (Stripe/PayPal/Instamojo) first. V7 only
4. The gateway redirects back. BE verifies the payment with the gateway (payment/{key}/verify in V7) before crediting. FE never treats a redirect as success.
5. BE changes the subscription, writes a charge + audit entry, and returns the new plan.
6. FE refreshes subscription, limits, sidebar badges and the dashboard.

#Add an existing server

1. On the OSS panel, the server admin turns on Central and copies the key sv_central_… (shown once). OSS API POST /central/enable
2. In Central: FE form with server name, panel/API address and Central key.
3. BE checks (all Missing on the Central side):
   • Reachability: GET {api}/api/health → {"health":{"status":"ok","version":"1.0.14"}} OSS API
   • Key: an authenticated call such as GET {api}/api/auth/me with Authorization: Bearer <key> must return the machine admin user. A wrong or revoked key gives 401 OSS API
   • Version: compare health.version with Central's minimum supported OSS version Open question
   • Duplicate: is the same panel already linked to this or another organization? Missing
   • Plan limit: are servers in use below allowed_servers? V7 only
4. BE stores the link record (encrypted key) under the current organization and writes an audit entry.
5. FE opens Server Details. The first data comes live from GET /server/facts and /server/metrics/live. OSS API

#Add a member

1. FE invite form: email, designation, role(s). V7 only
2. BE:
   • If the email belongs to an existing user, they're added at once and emailed ("joined organization"). V7 has no accept step for them.
   • Otherwise a pending invitation with a token is emailed. V7 only
3. The invitee opens the link and registers or sets a password (V8 requirement 2.6 "Invitation password"). The membership becomes active.
4. The member's roles define their permissions. BE enforces them on every request.

#Create a VPS

1. Connect a provider: OAuth (DigitalOcean, Linode) or API token (Vultr, Hetzner, Lightsail) in V7. V7 only
2. BE lists regions and sizes from the provider. V7 only /cloud-server-providers/{id}/regions|sizes
3. BE creates the VPS with a cloud-init/SSH step that runs the OSS installer with CENTRAL_TOKEN=<token Central generated>, so the key is known to Central without copy/paste. OSS API installer supports CENTRAL_TOKEN · the Central side is Missing
4. BE polls the new panel's /api/health until it's up, then links the server. The OSS panel does not call Central back. OSS API
5. FE shows progress (create → boot → install → connect) and the result.

#Deploy a blueprint

1. Blueprints are saved in Central (V7 stores them per user). V7 only
2. The user picks a server and a WordPress site on it (from OSS GET /applications). OSS API
3. BE sends the whole blueprint to OSS POST /central/addons/applications/{id}/wordpress/blueprint → 202 run. OSS API
4. BE/FE poll GET /central/addons/runs/{run} until succeeded/failed. Read result.completed and result.steps[] for per-step results. OSS API
5. Needs the WP Toolkit add-on installed and licensed on that server (403 addon_licence_required / 404 addon_not_installed). OSS API

#Audit

1. Every state-changing Central request writes an audit entry: actor, organization, resource, action, result, IP, time. Missing (V7 has a simpler activities table)
2. Server actions forwarded to OSS are recorded in Central with the real person, because OSS records them as the "central" machine account. OSS API
3. FE Audit Log lists entries with filters (actor, resource, action, date) and links from the dashboard's recent activity.