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

# Authentication

> Human sessions, scoped Mach-1 keys and native workforce integrations.

[Build](https://build.aioncx.com) uses a verified email/password session. Confirm your email before Build creates a workspace. Existing invited people retain their existing workspace selection. The browser session is used for key management, source setup, Requests and billing.

Create a **personal ingest key** in Build → Developers. The secret appears once. A key can submit and read or be read-only, has a workspace grant and an expiry (90 days by default, or explicitly until revoked). Current person membership and capabilities are checked at each call; a token does not restore access that its owner has lost. Revoke or replace the key in Build. Do not put keys in source control, URLs, logs or an agent prompt.

For the Mach-1 REST and MCP endpoints, send `Authorization: Bearer <scoped-ingest-key>`. Personal keys use their granted workspace; send `X-Workspace-Id` for receiver submissions and scoped reads when needed. Organization keys with multiple workspace grants must select an allowed workspace using the route's workspace selector. API, Deepgram and native Zoom reads also enforce their own subject visibility; an organization ingest key cannot read native Zoom interactions.

The common `/api/mcp` URL supports distinct credentials. **Mach-1 MCP** uses `atlas_ingest_` scoped keys. Visible tools follow the conversation and forecasting permissions granted to that key. The existing workforce/scheduling branch uses `atlas_mcp_` connections with separate grants. See [MCP](https://docs.aioncx.com/integrations/mcp.md).

Original audio uploads and direct transcripts go to the receiver URL discovered in Build, not through the Atlas status API. Build uses its authenticated cookie for its human routes under `/api/atlas/ingest`; external clients use bearer-key routes under `/api/ingest`. A browser cookie is not a scoped API key.

## Forecasting permissions

In Build → Developers, enable **Submit forecasts** and **Read forecasts** for the intended key. These grant `forecast:submit` and `forecast:read`; conversation permissions alone do not grant them.

Forecasting REST uses `workspace_id` in the query string. MCP uses the connection workspace selector and the tool's declared workspace input where required. Current workspace and source authority are rechecked. See [forecasting](https://docs.aioncx.com/mach1/forecasting.md).

## Workforce integrations

Workforce REST under `/api/v1/workforce` requires `atlas_mcp_` with explicit `api:connect` and the existing workspace/domain grants. `mcp:connect` alone never permits REST. Explicit integrations default to 90 days; narrowly scoped single-workspace planning connections can explicitly be until revoked. Ordinary MCP defaults remain unchanged. Both transports recheck current owner authority and use a token Actor for effects. See the [workforce contract](https://docs.aioncx.com/api-reference/workforce/overview.md).

Complete or reconcile issued workforce drafts before rotating the connection: rotation revokes the old key and gives the successor a distinct token Actor, so it cannot recover the predecessor's pending requests. Authorized native users retain access to the existing receipts.


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