Overview
Atlas has three access patterns:
Use the generated reference for endpoint-level auth requirements. Use this page
to choose the right model before you build.
Public read access
Most public directory reads do not require credentials. This includes actor search, place pages, entity sources, issue areas, and domains. Public access is intentionally useful, but it has the lowest rate limit. If a script becomes part of a regular workflow, authenticate it.API keys
Use API keys for server-to-server integrations:- Scheduled exports into a CRM or data warehouse.
- Workspace reports, briefs, lists, watches, or usage proof.
- Discovery run automation.
- Higher-volume directory reads.
X-API-Key header:
OAuth and MCP
Use OAuth when the user is granting access to a compliant client, especially an MCP client such as Claude Desktop, Claude Code, Copilot, Gemini, or Codex. Most users should not configure OAuth endpoints by hand. They give the client the Atlas MCP server URL:MCP for AI assistants
Use Atlas from compliant AI assistants through the hosted MCP endpoint.
Workspace binding
Workspace APIs and assistant access use a workspace context. Single-workspace users are selected automatically. Multi-workspace users pick the workspace during consent. If an integration writes or exports data, store the workspace id alongside the artifact. Do not mix public directory records with private workspace notes unless the API response explicitly says a record is public.When auth fails
Use the error response to choose the next action:
For exact OAuth metadata, scopes, and token behavior, use the generated
reference and the MCP docs.
Next steps
Rate limits
Understand limits by access pattern.
Workspace visibility
Keep private workspace context separate from public records.
Generated reference
Check exact endpoint auth and schemas.
Plans & pricing
See which plans include API keys and MCP access.