Review connected apps and access keys

Open Connected apps and see what can reach your data

Open Settings, find the Advanced group in the left menu, and choose Connected apps. The page lists one row per outside application that currently holds a live token for anyone on your team. It is company wide, not personal: an app a colleague approved appears in your list too.

An entry only ever gets here one way. Someone signed in, an outside app asked for permission, and Mailsoftly showed its own approval screen listing exactly what the app wanted. Approving is limited to Admins, so a member of your team cannot quietly attach an outside service to your account. In practice that approval screen is reached either from the integrations catalog or by connecting an AI assistant to Mailsoftly’s hosted server for assistants, which Connect an AI assistant with MCP walks end to end.

If the page reads "No connected apps yet", nothing outside your team holds a token, and there is nothing to review here today.

Open Connected apps in Mailsoftly

Read a connection: who approved it, when, and what it can do

Each row packs four things. Read them in this order and you can decide about an app in about ten seconds.

• The name is the name the application registered with us. It is the app’s own name, not something you typed
• Authorized by is the email address of the person whose approval is behind the newest live token. If that person has since been deleted, it reads "Removed user", which is itself worth noticing
• Last authorized is the date that newest approval happened
• The bullet list underneath is the plain-English list of what the app is allowed to do

Those permissions are the important part, and there are only seven of them in the whole system. An app can be allowed to read your contacts, lists and tags; to create and update them; to read your campaigns and their reports; to create and edit campaign drafts; to send or schedule campaigns to your contacts; to add addresses to your suppression list; and to read your account and company profile. The row shows the union of everything the app’s live tokens carry, so what you see is the full extent of it.

One permission is deliberately harder to give than the others. Sending or scheduling campaigns is never granted just because an app asked for it: the approval screen breaks it out as a separate, unticked box, and it is refused unless someone actively ticks it. So if a row does not list sending, that app cannot put mail in front of your contacts, full stop.

Cut off an app you do not recognise

Revoking is one click. Hover over the row and a revoke icon appears at the right hand end; it is hidden until you hover, so if you are looking for it on an untouched screen, move your pointer across the row first. Choosing it asks you to confirm, then the row disappears and a confirmation appears at the corner of the screen.

What that does, precisely:

• Every access token that app holds is revoked, for every person on your team at once, not just for you
• The stored approvals go with them, so the app cannot quietly renew itself in the background
• It takes effect immediately. There is no waiting period and no grace window
• The only way back is a fresh approval by an Admin, starting again from the app’s own side

The outside app is not notified. Nothing is sent to it, and it has no way of knowing until its next request to Mailsoftly fails. That is worth telling whoever owns the integration before you press the button, so they are not debugging a mystery outage.

Open API keys and see what a key can do

Now the other half. In the same Advanced group, choose API. This is the list of keys your own systems hold. You will hear these called company access keys in some places; it is the same thing under two names, and this screen is where they live.

The difference from a connected app is worth being clear about, because a reviewer will ask:

• A connected app is an outside product that an Admin approved. It gets short-lived tokens that refresh in the background, and its access is tied to the approval
• An API key is a long string your own code holds and sends with every request. Nobody approves it in a browser. It belongs to the company, not to a person, so it keeps working after the teammate who made it leaves

Each row tells you when the key was created, when it expires, when it was last used, and what it is allowed to do. Under the name sits a short code: that is the first few characters of the key, kept so you can tell one row from another. The rest was never stored.

"Last used" answers the question that matters most in a review: is anyone still using this? It updates at most once an hour, so treat it as a staleness signal rather than an audit trail. A key that reads "Never used" months after it was made is a key you can delete today. If you are creating your first key rather than reviewing the ones you have, Use the Mailsoftly API covers the key, the endpoint reference and a first call in one pass.

Open your API keys in Mailsoftly

Create a key, copy it once, store it somewhere safe

Press Create New API Key. The dialog asks for two things.

A name. Name it after the thing that will use it, not after you. "CRM connector" tells the next person what breaks if they delete it; "test" tells them nothing.

What the key can do. The dialog opens on Full access, which lets the key use every part of the API. Choose Limited access instead and the seven permissions appear as checkboxes, the same seven a connected app can hold. Tick only what the integration actually needs.

• Read only reporting? contacts:read and campaigns:read are usually enough
• A signup form pushing people in? contacts:read and contacts:write
• Leave sending off unless the integration genuinely sends campaigns

Two more things about permissions. They are set at creation and cannot be changed afterwards, so narrowing a key means creating a new one and retiring the old. And renaming a key later, which you can do by clicking its name in the list, only changes the name; it never touches what the key is allowed to do.

The key is shown once, and only once

Press Generate API Key and a dialog appears with the key in it. Read the warning in it carefully, because it is literally true: this is the only time the full key will ever be visible.

Copy it with the copy button, then put it straight where it belongs. That means your integration’s configuration, or a password manager, or wherever your organisation keeps credentials. It does not mean an email to yourself or a note in a shared document.

Mailsoftly cannot show it to you again, and that is deliberate rather than awkward. The database keeps a one-way fingerprint of the key plus its first few characters, and nothing else. There is no column holding the key itself, no support person who can look it up, and it is never sent by email. If you lose it, the fix is to delete that key and make a new one.

The dialog also tells you the date the key expires. Write that date down with the key.

Rotate before the warning turns into an outage

A new key stops working one year after it is created. Nothing about that failure is loud from the outside: the integration simply starts being refused, so Mailsoftly warns you twice.

• On the screen. A banner appears above the key list as soon as any key is within 45 days of its deadline, naming each key and its date. Closing it only clears it for that visit; it comes back on the next one until the key is actually rotated
• By email. Thirty days out, the Admins on the account get a message naming the keys, their dates, and the three steps to rotate. Only the first few characters of each key appear in it; the full value is never emailed

The rotation itself is the order given in the banner, and the order matters:

1. Create a new key, with the same permissions as the old one 2. Update the integration so it uses the new key, and confirm it still works 3. Only then, revoke the old key

Doing it in that order means nothing goes down. Revoking first means an outage until step two is finished.

Put the review on a schedule, and answer the questionnaire

Once a quarter, open the two screens in order and ask four questions. It takes about five minutes.

• Connected apps: is every app on this list still something we use, and does anyone still recognise the person under "Authorized by"?
• API keys: does every key still have a job? Anything reading "Never used" or last used months ago goes
• Does any key hold Full access where Limited would do? If so, make a narrower replacement and retire the wide one
• Is the team list still right? A leaver’s login is gone when you deactivate them, but a key they created keeps working until somebody revokes it

When you have to answer someone else’s security review, these are the facts you can state, and every one of them is something you can show on screen:

• Only Admins can approve an outside application, and approval always shows an explicit screen listing what the app is asking for. It is never automatic
• Permission to send campaigns is a separate opt-in that has to be ticked, and is refused otherwise
• Any Admin can cut off any connected application immediately, for the whole company at once, from Connected apps
• API keys are stored as a one-way fingerprint plus the first few characters. The full value exists only in the moment it is created and is never sent by email
• Keys expire after a year, with an on-screen warning at 45 days and an email to Admins at 30 days
• A revoked key stops working on its very next request. There is no grace period and no way to reuse it

That is the whole answer, and none of it requires you to go and ask us. Two screens, four questions, once a quarter.