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 TypePrefixEnvironmentUse Case
Live Tokenmon_Live environmentReal production API access
Test Tokenmon_test_Test environmentSimulated 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