Admin panel

The operator surface on :5174, page by page, with the platform admin bit each one needs.

The admin panel is the operator's view of an instance: every worker, user, organization, mailbox and background loop, across every workspace. It is a separate app from the customer dashboard, it holds nothing a customer needs, and every page in it is gated on a platform admin bit rather than a workspace role.

Reaching it

The panel runs on :5174 in the default stack (http://localhost:5174 on a stock install, or the host you proxied to it). Sign in with the same account as the dashboard. The first owner holds every admin bit from the moment they claim the instance, and sendsetsctl user create --admin creates a further account that already holds them. A page the account has no bit for says which bit it needs instead of rendering.

The old paths still redirect, so a bookmark or a link in an older version of these docs lands on the right tab.

Command palette

Cmd K (Ctrl K on Linux and Windows) opens the command palette from any page. It jumps to any page by name and searches users, organizations, mailboxes and workers, so a support request that names an email address is one keystroke from the record.

Overview

The landing page. Instance-wide counters and their trends, acquisition by channel, and a strip of open instance problems at the top, which is the same list as the Findings tab of Setup and health.

Operations

Page	What it answers
Workers	Every worker, its heartbeat, region and the mailboxes placed on it. Detail pages carry stats, the assigned mailbox list, and reassignment
Fleet	Capacity per worker with utilization, the control loops' decision log (what the placement and rotation loops did and why), and isolated-egress reservations, with reserve and release
Mailboxes	Every connected mailbox across every workspace, with its state and the worker it sits on
Sync	The platform copy of each mailbox's backfill progress and fair-use throttle, with clear-throttle and restart-backfill. The budgets it enforces are the four `sync.*` values under Configuration > Settings; the worker-side engine is the sync governor described under anti-abuse layers
Warmup	The pools, the blocked list, and the block and unblock history
Warmup Appeals	Appeals from blocked mailboxes, to approve or reject
Warmup Content	The generated and reviewed warmup conversation bank, its library and generation jobs
Campaigns	Every campaign on the instance with its state and owner
Sends	In-flight reservations no worker has answered, and the reclaimer that resolves them after 30 minutes; dead letters with replay; task failures; customer webhook delivery health, with reclaim

Accounts

Page	What it answers
Users	Every account, with ban and unban, ban history and rate-limit overrides
Organizations	Every workspace, with its members, plan, abuse posture, API keys, webhooks and transfer tabs
Limit requests	Customer requests for a higher allowance, to approve or decline
Promo codes	Every discount code on the instance, who has redeemed each one, and the builder that creates them
Outreach	Mail an operator sends from the instance to a user, a workspace or an address, and the delivery state of each message sent so far
Admins	Who holds platform admin bits, and grant and revoke by preset or per bit. This replaces the CLI-only path; `sendsetsctl user grant-admin` still works

A promo code is created here, never in the Stripe dashboard. SendSets stores the code itself, validates it when a customer types it on the billing page or at checkout, and mints a matching single-use Stripe coupon for that one redemption. A coupon or promotion code created in Stripe directly is not reachable: the checkout session carries the discount SendSets resolved, so Stripe never shows its own promo field.

The builder asks six things:

Code, the literal string a customer types. It is uppercased on save and cannot be changed afterwards, because redemptions point at it.
Discount, one of a percentage off, a fixed amount in one currency, or extra free trial days. The kind is fixed once the code exists; its value can still change.
How long it lasts, for the two money kinds: the first invoice only, a number of months, or forever. A months-long discount runs on a clock, not a count of invoices, so a monthly plan gets that many discounted invoices while an annual plan bills once inside the window and has its whole first year discounted. The builder says this back to you as you set it.
Eligible plans, all of them or a chosen set.
Redemption limits, which are two separate numbers. The total cap counts across every workspace on the instance and is off by default; the per-workspace limit is how many times one customer may use it and is 1 by default. Setting the total cap to 1 means one customer in total, which is almost never what a launch offer wants.
Schedule, an optional start and expiry. A start in the future leaves the code scheduled, an expiry is the end of that day in your own timezone, and the Active switch refuses a code at checkout without deleting it.

Deleting a code stops new redemptions and removes it from the list. Workspaces that already redeemed it keep their discount, because the Stripe coupon behind each redemption was minted separately. Disable the code instead when you want the history to stay readable under its name.

Reading the list needs view_organizations; creating, editing and deleting need manage_organizations.

Insight

Page	What it answers
Live Events	The event bus as it happens
Audit Log	Who did what, from where, across the instance
Jobs	Every background loop on the instance with its last run, next run and last error, and a Run now that the owning process picks up within about 15 seconds. The backend's and the consumer's loops are in the same list

Instance

Page	What it answers
Setup and health	Two tabs. Findings is the instance health check list, and the sidebar badge counts its open findings. Services is the old System Status page: the per-service probes and the platform mail card with its connection check and send test
Configuration	Four tabs. Settings is the database-backed settings document; Notifications is the operator notification channels; Environment is the read-only configuration reference view of what the backend resolved; Effective limits lists the compiled pacing constants
Transfers	Workspace export and import for any organization, from the operator side, with the same archives as `sendsetsctl org export` and `org import`. A whole-instance backup stays `sendsetsctl backup` and `restore`

Permission per page

Page	Bit
Overview, Live Events	none beyond signing in as an admin
Workers, Fleet	`view_workers`
Mailboxes, Sync, Users	`view_users`
Warmup, Warmup Content	`view_warmup_pool`
Warmup Appeals	`review_appeals`
Campaigns, Sends	`view_campaigns`
Organizations, Limit requests, Promo codes, Outreach, Transfers	`view_organizations`
Admins	`grant_admin_access`
Audit Log	`view_audit_logs`
Jobs, Setup and health	`view_analytics`
Configuration	`manage_settings`

Detail pages need the same bit as the list they open from. Actions inside a page can need more than the page itself: reading an organization's abuse posture or the Outreach list needs view_organizations, while changing a posture or sending outreach needs manage_organizations, as accounts and access lists.