Skip to content

Build an Admin Dashboard

The complete admin blueprint — every admin-panel menu mapped to its Admin API. The API mirrors the admin panel menu-for-menu, so any back-office screen can be rebuilt from it. Use this as the map; for the two flows with real sequencing/structure gotchas, see Create-Order and Product Management.

Every request carries the admin Integration token:

Authorization: Bearer <id>|<token>

Agent-ask inputs

  • Integration token — ask the user; generated in the admin panel's Integration menu. No admin login; never mint it.
  • Server URL — ask the user for their Bagisto server's base URL (e.g. https://store.example.com) and prefix every endpoint path with it. Never assume localhost or a demo domain.

The pattern behind every screen

list → detail → action — a { data, meta } listing (?page + ?per_page + filters), a detail GET with relations embedded, then create/update/delete + per-record actions (each permission-gated → 403 if the token's role lacks it). See the Admin Workflows overview for the envelope, pagination headers, and GraphQL rules.

1. Dashboard & Reporting

  • Dashboard — the headline stats behind the admin home (?type= picks a stat group; ?start/?end/?channel bound the window).
  • Reporting — sales / customers / products report groups, a table "view details" mode, and CSV export.

2. Sales

The order lifecycle and its documents:

  • Orders — list + detail (customer, addresses, type-aware items, invoices, shipments, refunds, payment, totals — all embedded), plus per-order actions: cancel, create invoice / shipment / refund, add comment. Eligibility + gotchas: fulfillment actions each have their own guards.
  • Invoices · Shipments · Refunds — the document datagrids (list, detail, export; invoice print PDF + mass-update-status).
  • Transactions — payment records; includes Record-Payment create.
  • Bookings — bookable-product reservations (read-only).
  • Create-Order flow → — place an order for a customer through a draft cart.

3. Catalog

  • Products — the datagrid, CRUD, copy, mass-actions, export, and the image/inventory/price sub-panels. The two-step create + partial-update traps live in Product Management →.
  • Categories — flat datagrid + nested tree; CRUD (move = update with parent_id+position); mass-actions; root-category delete guards.
  • Attributes — the dynamic fields + their options sub-resource; system-attribute + in-use guards.
  • Attribute Families — attribute groupings chosen at product-create; last-family / product-attached delete guards.

4. Customers

  • Customers — list/detail/CRUD, addresses, notes, impersonate ("login as customer" → a short-lived customer token), mass-actions; groups; reviews moderation; GDPR requests. Delete is guarded when the customer has active orders.

5. Marketing

  • Marketing — Cart Rules (+ coupons: single/bulk-generate/mass-delete), Catalog Rules, Email Templates, Events, Campaigns (+ send), Newsletter Subscribers, Search Terms, Search Synonyms, URL Rewrites, Sitemaps (+ generate).

6. CMS

  • CMS Pages — list/detail/CRUD + mass-delete. Create broadcasts to every locale; update is locale-nested.

7. Settings

Reference data and access control — mostly straight CRUD (+ mass-delete where the panel has it), each with its own delete guards (last-of-kind, in-use):

8. Configuration

  • Configuration — the whole core_config key/value store via three generic endpoints (menu schema, read values by slug, update by slug). Writes are scoped to the slug — a key outside it is rejected.

GraphQL variant

Every menu is available at POST /api/admin/graphql (admin token, no storefront key). Remember the result-field / id rule on action + mass-action mutations (select success / message / orderId / … — not a generic id). Details in the Admin Workflows overview.

Status codes to handle

200/201 success · 401 unauthenticated · 403 forbidden (permission) · 400 bad input / guard · 404 not found · 409 wrong step order (Create-Order) · 422 validation / ineligible action.

Released under the MIT License.