> ## Documentation Index
> Fetch the complete documentation index at: https://belajarkoding.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Admin dashboard

> Comprehensive documentation for the KilatKoding admin dashboard, including role management, operational visibility, and admin access dependencies.

<Info>
  The admin dashboard is the internal operations surface. It is used to see revenue, webhook events, audit trails, and some administrative actions such as role updates.
</Info>

## What this feature includes

* `/admin`
* `POST /api/admin/users/role`
* visibility into payments, webhook events, and audit trail

## Related routes and endpoints

| Route or endpoint            | Type           | Purpose                                 |
| ---------------------------- | -------------- | --------------------------------------- |
| `/admin`                     | Dashboard page | Internal operations panel for admins    |
| `POST /api/admin/users/role` | API mutation   | Changes a user role from the admin area |

<Note>
  The data shown in the admin area usually also depends on payment, webhook, audit trail, and subscription flows. In practice, this page is often used together with [Billing and payments](/en/kilatkoding/features/billing-and-payments) and [Testing and readiness](/en/kilatkoding/features/testing-and-readiness).
</Note>

## Who uses it

* founders who also operate the product,
* internal operators,
* support or finance teams,
* developers verifying admin access.

## Main dependencies

| Item                            | Required?            | Notes                           |
| ------------------------------- | -------------------- | ------------------------------- |
| `NEXT_PUBLIC_ENABLE_ADMIN=true` | Yes                  | Enables the admin area          |
| Auth enabled                    | Yes                  | Admin still requires login      |
| `admin` role in `user_roles`    | Yes                  | Final access control            |
| `ADMIN_EMAILS`                  | Optional             | Helps with initial bootstrap    |
| `SUPABASE_SERVICE_ROLE_KEY`     | Strongly recommended | Used by many operational writes |

## What teams usually customize

* the metrics operators care about,
* who can become an admin,
* which actions need to stay available,
* operational language and labels,
* event and audit visibility.

## When this feature is disabled

Admin is usually disabled when:

* the team is still very small and does not need an internal panel,
* the product does not need formal internal operations yet,
* a client project did not purchase the admin area.

If disabled, make sure there is still an alternative process for:

* checking payments,
* checking webhooks,
* checking audit data,
* reviewing user roles when needed.

## Verification checklist

1. Admin users can open `/admin`.
2. Non-admin users cannot access the admin area.
3. Role updates work if that flow is used.
4. Revenue, payments, webhooks, and audit visibility match expectations.
5. No misleading placeholder data remains in the admin surface.

<Tip>
  If the product actively uses payments or AI, the admin dashboard usually becomes more important. Continue to [Operational runbook](/en/kilatkoding/operational-runbook) for the operational side of it.
</Tip>