Admin screen index

Ninety page files make up the core admin: 81 under the dashboard shell and 9 under the blog shell. The extensions add another 208 on top, each with its own sub-navigation, which is why this index stops at core.

This is a lookup table. If you know what you want to do, find it here and go. If you want the guided tour — what each area is for and the daily routine that keeps it clear — read The admin panel instead.

How to read the permission column

The permission named is the one that opens the URL, taken from frontend/middlewares/permissions.json. That manifest fails closed: an admin path with no entry requires the base access.admin key, and those rows are marked fallback.

Opening a URL is not the same as seeing data on it. Almost every screen is a data table that also asks for a view.* key before it fetches a row, and each button asks for its own create., edit. or delete. key. Granting access.X without view.X produces a page with a permanently empty table and no error. The whole model is in Roles and permissions.

Dashboard and area landings

The five area URLs are not dead ends: each renders that area's own submenu, so landing on one is a menu rather than a blank page.

Users

Finance

Content and appearance

Everything in this group is covered in Design, menus, footer and branding and Blog, media, announcements and market news.

System

Blog

The blog admin is its own route group. It renders inside the public site's header and footer with a four-item bar of its own — Dashboard, Content, Community, Settings — and the dashboard nav links only to /admin/blog.

Screens with no menu entry

Eleven core screens are reachable only by typing the URL or by following a link from inside another page. Losing track of one of these is how a feature gets reported as missing.

The blog's own screens are not in the dashboard nav either. They are in the blog admin's bar, which only appears once you are inside /admin/blog.

Screens that appear conditionally

They are mutually exclusive by design, and when the setting has never been saved the menu treats it as DEFAULT. Both URLs resolve regardless of the setting — it decides only which one is listed.

Every extension screen is conditional in a different way: the admin menu shows extensions you have not enabled, marked as disabled, so you can see what is available. The public user menu hides them.

The seventeen screens on the access.admin fallback

These core pages have no entry in the URL permission map, so the base access.admin key alone opens them:

/admin/builder                        /admin/finance/binary/market/create
/admin/builder/{id}                   /admin/finance/deposit/method/{id}
/admin/crm/kyc/application/{id}       /admin/finance/exchange/balance
/admin/crm/kyc/level/{id}             /admin/finance/exchange/fee
/admin/crm/user/{id}                  /admin/finance/exchange/market
/admin/default-editor                 /admin/system/license
/admin/default-editor/{pageId}/edit   /admin/system/notification
/admin/extensions                     /admin/trading/settings
/admin/finance/binary/market/{id}/edit

The data on them is still fetched through the API and still refused without the right view.* key, so an under-privileged operator sees an empty shell rather than records. But the URL opens, and for /admin/trading/settings and /admin/system/notification that is a real screen with real controls on it.

One more fragility worth knowing: /admin/system/logo currently gates on access.system in the manifest, but its source file declares the permission using the plural array form (export const permissions = [...]), which the manifest generator cannot parse. If anyone regenerates permissions.json, that entry disappears and the page drops onto the access.admin fallback.

Endpoints with no screen

Some admin capability exists only as an API. These are the ones worth knowing, because looking for a screen wastes the afternoon:

There is no standalone screen for this. It is rendered as the ledger panel on the Audit Trail tab of a customer's page, a deposit, a withdrawal or a transfer, scoped to that record. Filter it directly with ?filter={"walletId":"…"} or ?filter={"userId":"…"} to get a whole trail. See The wallet audit log.

Nothing in the shipped frontend calls it. It is the only way to tell a reserved slug apart from one held by a soft-deleted page.

Also unused. /admin/trading/settings writes through /api/admin/system/settings instead, which is why the access.trading.settings key can be granted and appear to do nothing.

Two maintenance endpoints with no UI. The second is the one to reach for when uploads or logos are landing in the wrong directory on a production box.

The Hummingbot extension adds a whole key-management API at /api/admin/hb/keys/* — list, stats, per-key audit, disable, enable, rate-limit override — with no admin screen anywhere under /admin/hb that opens it. The permission keys (view.hb.key and friends) are seeded and grantable regardless.

Where the extensions live

The 208 extension admin pages are not listed here. Each extension owns a sub-navigation that appears once you enter it from Extensions, and its screens are gated by the URL map and by the API routes behind them. Extension admin sub-menus declare no permissions of their own, so an extension page nobody mapped is reachable by anyone holding access.admin — the same fallback as the block above, at ten times the scale.

For which extensions are installed, enabled and licensed, see Extensions and versions.