Version 5.42 adds a new Token Management page to ISPadmin (Settings / System settings) and, more importantly, user permissions for it. Generating API keys — through which data can be both read from and written into the system — is now controlled: the administrator decides, not just anyone who logs in. For an ISP this means lower security risk, control over access to your data, and another step toward NIS2 compliance.
Do you know who can create an API key in your ISPadmin today? How many keys are currently active in the system, and which integration each of them actually belongs to? And is there a token still “living” somewhere after an expired trial license or a disconnected tool that no one remembers? If the answer is “no idea,” version 5.42 has good news for you: access to generating API keys is now fully in your hands.
Why it matters
The REST API is now a common gateway into ISPadmin. API keys are used to connect integrations for maps, SMS gateways, banking interfaces, invoicing links, as well as custom scripts and third-party tools — and increasingly also projects such as voice self-service or AI assistants that pull client and service data from ISPadmin. Every such connection needs its own token, and that token is essentially a key to the system.
The problem was that the API key generation page was not included in the navigation and had no permissions of its own. In practice this meant that any logged-in user could generate their own API key and use it to pull information out of ISPadmin, or to write data into it. For a system that manages sensitive data about clients, services, and the network, this is a real security risk — and this is exactly what one of the providers pointed out.
What Token Management brings
The Token Management page is now included in the menu under Settings / System settings, so generating and managing API keys is in one clearly defined place. The key change, however, is in the permissions: four separate permissions have been added for this page in the user settings — read, add, edit, and delete.
The permissions are enforced strictly. Without the read permission, the page will not be shown to the user at all and cannot even be found in the menu. Without the add, edit, or delete permissions, the relevant buttons disappear — and, importantly, the given action will not go through even via a direct URL. The permissions therefore cannot be bypassed through a “back door.”
The decision about who may see and create API keys is thus entirely up to the administrator. You can entrust it to a narrow group of people who actually manage the integrations, and not give the rest of the team access to generating keys at all.
Three roles, three reasons to appreciate it
The system administrator finally decides who can see the API. Instead of an “everyone can” state, access is granted deliberately and as needed — and just as easily revoked when staffing changes.
The person responsible for security gets the principle of least privilege in practice: access to the system’s keys is held only by those who truly need it. This is useful not only for peace of mind, but also for demonstrating that access to data is controlled — a topic that more and more providers are addressing with NIS2.
The ISP owner has a simpler assurance: data is not pulled out of their system through a key that no one knows about and that anyone could generate. The risk of a data leak via a “forgotten” token drops significantly.
How it fits into the rest of the system
Token Management is not a standalone feature — it builds on the user permissions on which the security of the entire ISPadmin rests. Just as with other pages, visibility and available actions for API key generation are now controlled through the permissions of a specific user. It also fits into the broader security line of recent versions (passwords, access control, NIS2-related measures), where the point is always the same: keeping control over who can access what in the system.
Three tips for setting it up well
Tip 1 — Grant permissions narrowly right after the update. After upgrading to 5.42, no one has the Token Management permissions at first. Use this and give access only to people who actually manage API keys — not to the whole team “just in case.”
Tip 2 — Review and clean up existing keys. Look at which tokens are in the system and remove those belonging to discontinued integrations or expired trial licenses. An inactive key is an unnecessary open window.
Tip 3 — Separate reading from editing. For most people who need to look at the page, the read permission is enough. Leave add, edit, and delete only to those who actually issue the keys.
What the ISP gains
Lower security risk — an API key can no longer be created by just any logged-in user, so one of the quiet paths to your data disappears.
Control over access — the administrator decides who may see, create, and delete tokens, and can change it at any time.
A step toward NIS2 compliance — controlled access to the system’s keys and the principle of least privilege are exactly what today’s security requirements expect.
Order among your integrations — generating and managing keys is in one place, not scattered “with everyone who logs in.”
How to get started
You will find the Token Management page in ISPadmin 5.42 under Settings / System settings. If you have not deployed the version yet, please request an update. Then we recommend three steps:
Step 1 — Grant the Token Management permissions only to responsible users in their settings; for logged-in users, the change takes effect at their next login.
Step 2 — Review the current API keys and remove those that are no longer needed.
Step 3 — Agree within the team on a simple rule — who issues tokens and how they are revoked after an integration ends — so your overview stays clean going forward.
If you are interested, we are happy to help you set up the permissions.