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

# Authentication

> Monime uses a Personal Access Token (PAT) authentication model designed for multi-tenant, role-aware, and secure API access.

Monime uses a **Personal Access Token (PAT)** authentication model designed for **multi-tenant, role-aware, and secure API access**. Instead of tying credentials directly to a single organization, Monime separates **user identity (Monimeer)** from **organizational context (Spaces)**, allowing developers to authenticate once and operate securely across multiple Spaces.

## Core Concepts

### Monimeer — Your Personal Identity in Monime

A **Monimeer** is your unique personal account in the Monime ecosystem. It exists independently of any Space and can belong to multiple Spaces at the same time.

This design ensures:

* You have one central identity across all organizations you work with
* No need for multiple logins for different projects or clients
* The same account can hold multiple tokens for different purposes

### Spaces — The Organizational Container

A **Space** is a secure, isolated environment representing a business or organization.\
It contains:

* Payment infrastructure and connected financial accounts
* Identity and access policies
* Resource ownership and operational data

When a Monimeer joins a Space, they are assigned a **role** that grants a specific set of permissions within that Space.

### Personal Access Tokens — Flexible API Credentials

A **Personal Access Token** is created under a Monimeer’s account.\
It is not tied to a single Space but can be used across multiple Spaces, with **effective permissions determined by the intersection** of:

1. Permissions granted to the token itself at creation time
2. Permissions granted to the Monimeer’s role in the specific Space

This model ensures:

* Tokens cannot exceed the Monimeer’s actual authority in a Space
* Tokens remain reusable across Spaces, reducing duplication
* Cross-organization automation is secure and efficient

### Token Types

| Token Type     | Prefix      | Environment      | Use Case                            |
| :------------- | :---------- | :--------------- | :---------------------------------- |
| **Live Token** | `mon_`      | Live environment | Real production API access          |
| **Test Token** | `mon_test_` | Test environment | Simulated API calls in sandbox mode |

**Environment Enforcement**

* A live token will never work in the test environment
* A test token will never work in the live environment

## How Permission Enforcement Works

When a request is made with a token, Monime applies three checks:

1. **Environment Validation**
   * Token type must match API environment (live/test)
2. **Token Permission Check**
   * Token must explicitly have the required permission
3. **Role Permission Check**
   * Monimeer’s role in the target Space must also grant that permission

Only when **all three checks pass** is the request approved.

## Advantages of This Model

### a) **True Multi-Tenancy Support**

Because tokens are tied to a Monimeer, not a Space, a single token can work across all Spaces you belong to, respecting each Space’s specific role restrictions. This simplifies automation for agencies, developers, and service providers who manage multiple clients.

### b) **Role-Aware Security**

Tokens inherit the least privilege possible — they cannot exceed the permissions of either:

* The token’s assigned scopes
* The Monimeer’s Space role

This prevents privilege escalation through token misuse.

### c) **Operational Efficiency**

No need to generate multiple tokens for different Spaces unless you want separate rotation schedules. This reduces management overhead and improves integration speed.

### d) **Better Collaboration Across Organizations**

A single developer or team member can participate in multiple Spaces with one set of credentials, while still having tightly scoped access to each.

### e) **Improved Token Rotation & Incident Response**

If a token is compromised:

* It can be revoked instantly
* Other tokens and Spaces remain unaffected
* No need to reset credentials for unrelated organizations

### f) **Clear Separation of Identity and Context**

By separating Monimeer identity from Space membership, there is no risk of cross-organization data leakage, and access decisions are always evaluated within the scope of the current Space.

## Best Practices

* **Use least privilege** when assigning token permissions
* **Rotate tokens regularly** to minimize exposure risk
* **Separate tokens per integration** for easy revocation
* **Whitelist IPs** for added production security
* **Test first** using `mon_test_` tokens before going live