Administration Overview

Note

The features described on this page apply to MemoryLayer Enterprise. The OSS edition ships with open authentication and authorization by default (any caller is treated as a privileged local user). This is intentional for local development and self-hosted single-tenant deployments.

To plug an external identity provider into the OSS server, swap the auth implementation via MEMORYLAYER_AUTHENTICATION_SERVICE and MEMORYLAYER_AUTHORIZATION_SERVICE — the default value default resolves to the open allow-all implementation. The /v1/users, /v1/applications, and /v1/admin/* endpoints described below are only available in the Enterprise edition.

MemoryLayer Enterprise provides a comprehensive administration API for managing platform users, applications, API keys, and cross-workspace resources. All admin operations are available through the REST API at /v1/.

Authentication

All administration endpoints require a valid API key passed via the Authorization header:

Authorization: Bearer ml-your-api-key

API keys are created through the token management endpoints. Each token carries workspace patterns and scopes that determine what the holder can access.

Tenant and Workspace Isolation

MemoryLayer Enterprise uses a two-level isolation model:

• Tenant — The top-level organizational boundary. Users, applications, and tokens belong to a tenant. All API requests are scoped to the authenticated tenant.
• Workspace — A logical grouping within a tenant for organizing memories, sessions, documents, and datasets. Workspaces provide data isolation so that different projects or teams do not interfere with each other.

API keys can be scoped to specific workspaces using wildcard patterns (e.g., project-* matches project-alpha and project-beta).

Authorization

The platform enforces role-based access control on every request. The authorization system checks three dimensions:

Dimension	Description
Resource	What is being accessed (users, applications, admin, memories, etc.)
Action	The operation (read, write, delete)
Workspace	Which workspace the operation targets (when applicable)

Admin-level endpoints under /v1/admin/ require the admin:read authorization scope.

Administration Areas

Area	Endpoint Prefix	Description
User Management	/v1/users	Create, list, update, and delete platform users
Application Management	/v1/applications	Register applications and manage workspace associations
API Keys	/v1/tokens	Create and manage API tokens with workspace scoping
Dashboard	/v1/admin	Cross-workspace statistics and resource listings

Common Response Patterns

All list endpoints return paginated results with limit and offset parameters. Error responses use a standard format:

{
  "detail": "Description of the error"
}

Standard HTTP status codes are used throughout:

Code	Meaning
200	Success
201	Resource created
204	Success, no content (delete operations)
400	Invalid request
401	Authentication failed
403	Authorization denied
404	Resource not found
500	Internal server error

Audit Trail

All write operations (create, update, delete) across users, applications, and tokens are recorded in the platform audit log. Audit events capture the tenant, acting user, resource type, resource ID, and action performed. This provides a complete history of administrative changes for compliance and troubleshooting.

Quick Start

1. Obtain an API key from your account or from an existing administrator.
2. Set the key in your environment: export ML_API_KEY="ml-your-key".
3. Verify access by calling the admin stats endpoint.
4. Create users and applications as needed.
5. Issue scoped API keys for your applications and CI pipelines.