One key, one account
A lemlist API key (or OAuth token) resolves to exactly one account. There is noaccount parameter and no separate login step — the credential is the
account selector.
To work across several accounts, generate one API key per account (each
account owner creates their own key, see Authentication)
and store them together. Switching account then means switching the key you
send.
Keep each key as securely as a password, and never mix them up between clients.
Switching account over the REST API
Authentication is HTTP Basic with an empty username and the API key as the password. Switching account is just switching the key:curl --user ":$KEY" builds the :APIKey string and Base64-encodes it into the
Authorization: Basic … header for you.
Switching account over the MCP server
The MCP server works the same way, and supports both authentication modes:- API key — send that account’s key in the
X-API-Keyheader. One key, one account. - OAuth — the consent screen asks you to pick a team, so each connection is
bound to a single account. To manage several, add one connector per
account (name them
lemlist-client-x,lemlist-client-y, …).
Looping over all your accounts
Because the account is just the key, iterating over every client is a plain loop:The lemlist CLI
The lemlist CLI packages this whole page into one command, with named profiles per account:lemlist api <METHOD> <path>
(plus named subcommands like lemlist campaigns list — run
lemlist endpoints to discover the surface). Output is JSON on stdout with
stable exit codes, so it pipes into jq, scripts and AI agents, and transient
failures (429, 5xx) are retried with exponential backoff honoring
rate limits.
OAuth tokens refresh automatically; profiles are stored in
~/.lemlist/config.json (file mode 0600).
give us feedback on this page