A key is an identity, not a password
Every keyed operation resolves the caller into an environment and a project. That is whose contacts, whose consent records, whose suppression list and whose bill are involved.
So a key is not a gate placed in front of the features — it is the thing that makes a request belong to somebody. A send with no key would be a send with no sender, and there would be nothing to attribute a STOP to.
Live and test are different environments
Every project has both from the moment it exists, each with its own secret and publishable key. Which environment you are acting in is decided by the key you call with — not by a flag that can be forgotten.
They hold separate data: the same person in live and test is two records.
Secret and publishable
A secret key is for your server. A publishable key is for a browser or an app, and can only reach the operations meant to be called from one — the hosted sign-in pages use it.
developers.key.create issues more, with scoped permissions. Each operation’s page names the permission it needs.
The operations without a key
account.signup takes no key, because it is how the first one is obtained. It is limited to 30 an hour per IP address.
Six more are called by a person following a link rather than by your code, and each is authenticated by the token or code that person holds instead of a key: account.member.accept (a dashboard invitation), audience.preferences.get and audience.preferences.set (the preferences page a recipient opens from an email), auth.link.complete (a magic link), auth.oauth.complete (the return from Google, Microsoft or GitHub) and auth.device.describe (the approval page of a device sign-in).
Everything else answers 401 unauthenticated without a valid key, rather than pretending the route does not exist.Last modified on September 23, 2026
