Waymaker
WaymakerDocs
Developer Documentation
Documentation

Managing API Keys

API keys (wm_sk_…) are the credentials that authenticate the CLI and MCP against your organization. They're managed in one place, used by both front-ends.

Creating a key

  1. Sign in at admin.waymakerone.com — any member can mint their own key
  2. Go to /api/keys (admins also have it in the sidebar)
  3. Click Create API Key
  4. Name it something that says what it's for — "CI deploy", "My laptop", "Claude Desktop" — not "Key 1"
  5. Tick permissions (see Authentication for what each one grants). host:admin can only be put on a key by an organization owner/admin
  6. Copy the key immediately. It's shown once. If you lose it, revoke it and create a new one — there's no way to view it again.

Or from the CLI, with an existing key: waymaker auth create-key --name "CI deploy". Without --permissions the server default for your role applies.

Key format

wm_sk_<random>

The wm_sk_ prefix identifies it as a Waymaker API key, distinct from any other token type the platform issues.

Rotating a key

There's no in-place rotation — create a new key, update whatever reads the old one (WAYMAKER_API_KEY in your shell/CI, the MCP client config), confirm it works, then revoke the old key from admin.waymakerone.com/api/keys.

Who sees and revokes which keys

  • Members see and revoke their own keys.
  • Organization owners/admins see and revoke every key in the organization — the list includes each key's user_id.
  • Revoking a key that doesn't exist, belongs to another organization, or (for a member) belongs to someone else returns the same 404.

Revoking a key

From admin.waymakerone.com/api/keys, revoke the key. It stops authenticating immediately — both the CLI and any MCP session using it lose access on their next request.

When someone leaves

A key stops working as soon as its creator is no longer an active member of the key's organization — validation checks membership on every use. You don't need to hunt down a leaver's keys, though an admin can still revoke them explicitly.

Best practices

  • One key per purpose (a laptop, a CI job, an MCP client) so revoking one doesn't break the others.
  • Never commit a key to a repository. Use a .env file (gitignored) or your CI's secret store.
  • Scope keys narrowly — a CI job that only reads data doesn't need any :write, :deploy, or :admin permission ticked.
  • Revoke keys for machines that are decommissioned. (A leaver's keys stop working on their own.)

Next steps