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

# Approve or decline access requests

> For Platform Super Admins: where access requests wait, what approving one creates, how declining is told, and the settings that change the flow.

A Platform Super Admin approves or declines requests for access in the console's staff portal, under **Access Requests**. Approving creates the company's organisation with the requester as its **Owner** and emails them a welcome; declining records the decision and emails the requester your reason when you write one.

This is platform administration. A customer's Owner or Administrator cannot see the queue or decide a request; the platform refuses them. Your account must be listed in `ARUKZ_PLATFORM_ADMIN_ACCOUNT_IDS`.

## Review the queue

1. Sign in through the staff entrance and open the staff portal.
2. Choose the **Access Requests** tab. It shows requests **Waiting for review**: the company, who asked, their email address, and the note they wrote.
3. Use **Show** to see requests whose email is not confirmed yet, approved and declined requests, or all of them.

A request appears as waiting for review only after the requester confirms their email address from the link they were sent. One that was never confirmed cannot be approved.

## Approve a request

1. Choose **Approve** on the request.
2. Check the **Organisation name**. It is the company as they typed it; tidy it if it needs it.
3. Choose **Approve**.

The organisation is created with the requester as Owner. If the address has no MITHUNAI account yet, one is made with no password, and the welcome email carries a link to choose one that works once for 7 days. If the address already has an account, it is seated as Owner and keeps its password; the welcome says to sign in.

Nothing is created unless the welcome can be sent. If the deployment cannot send email, approving is refused and the request stays in the queue.

## Decline a request

1. Choose **Decline** on the request.
2. Write a **Reason** if you want the requester told. Leave it empty to send nothing.
3. Choose **Decline**.

The screen says whether anyone was emailed. A declined address can request access again.

## Settings

| Setting | Default | What it does |
| - | - | - |
| `MITHUNAI_ACCESS_REQUEST_NOTIFY_EMAIL` | empty | Who is emailed when a request is confirmed. Empty emails nobody; the request still waits here. |
| `MITHUNAI_STARTER_MONTHLY_ANSWER_ALLOWANCE` | empty | Monthly answers an approved organisation starts with. Empty uses the deployment's allowance. Change one organisation's afterwards under **Usage & Allowances**. |
| `MITHUNAI_SELF_SIGNUP` | `false` | When `true`, a confirmed request is approved at once, with nobody deciding. **Requires legal review** before it is turned on; leave it `false`. |

> [!WARNING]
>
> Self sign-up is built but off. Do not set `MITHUNAI_SELF_SIGNUP=true` until your legal review has
> cleared it. With it on, the queue shows each request as already approved, and the tab says so.

## Good to know

* **Every decision is audited**, as `access_request.approve` or `access_request.decline`, with who decided.
* **Each request is decided once.** If two administrators decide the same request at the same moment, the second is told it was already decided.
* Requests are not reminded or expired. Decline one you do not intend to approve.
* The same queue is available over the API, behind platform administration: `GET /platform/access-requests` and `POST /platform/access-requests/{id}/approve` or `/decline`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.