Skip to content
Latchkey

MongoDB Atlas API "401 Unauthorized" (public/private API key) in CI

The Atlas Admin API (and the Atlas CLI on top of it) uses HTTP digest auth with a public/private API key pair. A 401 means the keys are missing, wrong, or not scoped to the project, so the request is rejected before any resource action.

What this error means

An atlas command or a direct Admin API call returns "401 (request ... ): Unauthorized" or "You are not authorized for this resource", while cluster data connections are unaffected.

bash
POST https://cloud.mongodb.com/api/atlas/v2/groups/.../accessList: 401 (request "...")
Error: You are not authorized for this resource.

Common causes

API key secrets are missing or wrong

The public/private key pair was not injected, has a typo, or was rotated, so digest auth fails with 401.

The key is not assigned to the project or lacks a role

A valid key that is not a member of the target project (or has too low a role) is rejected for that resource.

How to fix it

Provide a valid, scoped API key pair

  1. Create a project-level API key in Atlas with the needed role.
  2. Store the public and private keys as CI secrets.
  3. Export them for the CLI or use digest auth for direct API calls.
.github/workflows/ci.yml
env:
  MONGODB_ATLAS_PUBLIC_API_KEY: ${{ secrets.ATLAS_PUBLIC_KEY }}
  MONGODB_ATLAS_PRIVATE_API_KEY: ${{ secrets.ATLAS_PRIVATE_KEY }}

Use digest auth for raw API calls

The Admin API requires HTTP digest auth with the key pair; --digest is mandatory for curl.

Terminal
curl -s -u "$ATLAS_PUBLIC_KEY:$ATLAS_PRIVATE_KEY" --digest \
  "https://cloud.mongodb.com/api/atlas/v2/groups/$ATLAS_PROJECT_ID/clusters"

How to prevent it

  • Store API keys as secrets and rotate them on a schedule.
  • Assign the key to the target project with least-privilege roles.
  • Always use digest auth for direct Admin API requests.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →