Developer
API keys
Keys your own systems use to talk to Mailyte, and how to keep them safe.
What this is
An API key lets your own software ask Mailyte to do things — send a message, look up a domain, list mailboxes, read delivery events — without a person signing in.
It is not the same as an SMTP credential. SMTP credentials hand mail to us over SMTP; API keys drive the API. If you are wiring up an existing application that already speaks SMTP, you want Senders and SMTP credentials. If you are writing the integration yourself, you want a key, and the full reference is at mailyte.com/developer.
How it works
Keys live on the Developer page, alongside webhooks and third-party integrations.
A key starts with mk_live_. The first sixteen characters are a public prefix — safe to log, and what identifies the key in this list. The rest is the secret.
Each key carries scopes, so a key used by a reporting script can be allowed to read without being allowed to delete. Give every key the narrowest set that lets it work. A request missing a scope is refused and told which scope it needed, so a wrong guess is quick to correct.
Scopes cannot be changed after creation. To widen or narrow a key, create a replacement and delete the old one — which is deliberate, because silently gaining permissions is not something a credential should be able to do.
A key can also have an expiry, or none. An expiry is a good habit: it turns "we should rotate that one day" into something that happens whether or not anyone remembers. A key can additionally be restricted to particular IP addresses or ranges.
The key itself is shown once, when you create it. It is stored as a hash, so nobody — including Mailyte — can read it back to you later. If it is lost, create a new one and delete the old.
The Last Used column shows when the key last authenticated a request, and the address it came from. An empty value means genuinely unused.
A key belongs to the person who created it and is bounded by their access: if they leave the organization, their keys stop working. Check who owns a key before removing a member, or an integration will stop without an obvious cause.
The same page has a Third Party tab for connecting services like chat tools, where you connect and disconnect rather than manage keys yourself.
Set it up
- Go to Developer and open the API Keys tab.
- Create a key and name it for the system that will use it —
billing-sync, notkey2. - Choose the narrowest permissions that let that system do its job.
- Set an expiry unless you have a reason not to. Rotating on a known date beats discovering a five-year-old key in a repository.
- Copy the key now. It is not shown again.
- Store it wherever that system keeps its secrets — an environment variable or a secret manager, never in code you commit and never in a chat message.
- Use one key per system, so revoking one never takes down three things you had forgotten shared it.
When something is wrong
Your integration is refused with a message about a scope. The key does not carry it. The refusal names the scope it wanted; create a replacement key with that scope added and delete the old one.
Your integration is refused with "Invalid API key". The key is missing, wrong, expired, revoked, or its creator has left the organization. Those all answer the same way on purpose — telling a caller which one would confirm to a stranger that a key exists.
You lost the key. It cannot be recovered. Create a replacement, update the system, delete the old one.
A key may have leaked. Delete it immediately — that stops it working — then create a replacement. Deleting first and apologising second is the right order.
You do not know what a key is for. Check the Last Used column for when and from where it was last used. Search your own systems for the key name, and if you still cannot place it, rotate rather than delete: create a replacement, watch for something to break, then remove the old one.
An integration stopped when somebody left. That is working as intended — a key is bounded by its creator's access. Re-issue it under someone who is staying.
A key created before 17 September 2026 does not work. Those keys never authenticated anything, and have been revoked and marked as such. Create a replacement; nothing that was working has stopped.