HTTP APIs: sessions and authorization
Atlas exposes APIs for system metrics, files, backups, calendars, contacts, devices and telephony. Most routes use the console session: the server verifies identity and applies permissions for the role and operation. A valid session does not automatically grant administrative access.
Metrics routes under /api/system/stats/ require administrator access. The /api/files/ and /api/devices/ families apply their own controls to files, inventory and device operations. Before building an integration, verify the method, parameters and permissions of the individual route in the installed version.
Errors and request protection
Protected APIs return 401 when authentication is missing and 403 when an operation is forbidden. For requests that change data, origin checks reject requests from another site. Non-browser clients must still satisfy route authentication and authorization: omitting the Origin header does not grant privileges.
Not every route shares this model. Public identity, health checks, device enrollment, provisioning and guest assistance have their own conditions and controls. Do not expose an entire API prefix on the assumption that every endpoint requires the same session.
MCP: connecting AI assistants to business services
The MCP gateway connects compatible AI assistants to authorized business tools and information. It can help inspect system status, gather diagnostic information and perform permitted operations without manually copying data between tools. Administrators decide which integrations to enable and which activities to permit: reading, authorized writes or excluded operations. Authentication and access logging maintain control over resource use. APIs also allow metrics, files, backups and other services to be integrated into business automation.
One use case is asking an assistant to gather authorized information for a diagnosis or operational summary. The assistant can use only enabled tools and the permissions assigned to its access identity. The gateway authenticates requests through personal tokens or delegated access, filters permitted tools and logs data access. Enabling an integration does not automatically grant every operation.
Identity and networking are separate layers
Atlas supports OIDC console sign-in and SAML application configuration, with explicit enablement and groups. This does not turn every API into an OAuth endpoint or automatically extend the session to the Argos console, which retains local authentication and a second factor according to access rules.
Argos can connect networks to Atlas services through policies and VPN tunnels. For remote partner management, pairing with Citadel requires confirmation and grants administrative access: this is a separate operational decision from a user accessing a service. Define scope, revocation and responsibilities first.
Evaluating an integration
Start with read operations and a least-privilege identity. Also verify expired sessions, insufficient permissions, token revocation and service unavailability. For file or device operations, establish which data may be consulted and which changes are authorized before enabling automation.
This page describes access models documented in the source code on October 3, 2026; it does not replace the individual route contract in the installed version.