Admin Panel

Apiker ships an optional admin panel. Enable it in apiker.init() and your worker serves it at /admp.

apiker.init({ routes, exports, objects, adminPanel: true });

What it shows

The panel opens on a dashboard that answers what your deployment has been doing and how it is configured:

The latest logged events, newest first, labelled by their log prefix
Entities that are currently banned, and which admin issued each ban
Recent rate-limit activity
The deployment's configuration: Durable Objects, registered routes, firewall limit, auth routes and email
Which optional protections are configured

From there you can add admins, ban and unban entities, search bans and logs, send account emails, and update or delete users. Entries in the dashboard carry their own actions, so an entity you spot in the log can be banned or looked up without retyping its id.

Which data does it act on?

The panel has no storage of its own: it reads and writes the Durable Objects of the worker that serves it. Opening /admp on a deployed worker means you are working with that deployment's live data, and actions such as deleting a user take effect immediately.

Every deployment has its own objects, its own admins and its own setup secret — nothing is shared between them. To click around safely, run your worker locally with disposable data:

wrangler dev --local

Claiming the first admin

ADMP_SETUP_SECRET is generated into your .env at build time and becomes a worker variable. While a deployment has no administrator, signing in at /admp with that secret creates the first admin account.

Once an admin exists, the setup secret stops working. Further admins are granted only by a signed-in admin, through the panel's Add Admin action. An account that already exists is promoted and keeps its current password.

Restricting who can reach it

Every panel route is gated by an admin session and a CSRF token. These optional worker variables add a network gate in front of that, rejecting requests from anywhere else before they reach the login form:

ADMP_IP_WHITELIST   = "..."   # only this IP may reach the panel
ADMP_ISP_WHITELIST  = "..."   # only requests from this ISP may reach the panel
ADMP_CITY_WHITELIST = "..."   # only requests from this city may reach the panel

The dashboard reports which of these are configured, without ever exposing their values.

Identities in the panel

Two identifiers appear in the panel, and they are not interchangeable:

Request identity — a hash of the caller's IP, returned by getSignedIp(). It appears on log entries and is what bans and rate limits apply to.
Account email — how a user record is found when updating or deleting a user.