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:Is there a CLI?
Not today. Everything above is already scriptable through the REST API and the MCP server, so a CLI is not required to build any of these workflows. What a dedicated CLI would add is ergonomics: a single command to store and switch between account profiles, built-in pagination and retries, and human-friendly output — instead of assembling the calls yourself. We think that is worth having, and a lemlist CLI is on our radar for a future addition. In the meantime, wrap these calls in your own script, or point an AI assistant (for example Claude with the lemlist MCP server) at these endpoints and let it drive them for you.give us feedback on this page