Skip to main content
Build 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. 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.

​
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. 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.