Before you give any tool your panel API key — including us

On 11 February 2026, Perfect Panel posted a security notice to its channel. An API key leak had occurred at a third-party solution used for SMM panels and automations, and owners were advised to stop “using any third-party tools or scripts that require your API keys” and to regenerate anything they had exposed.

That notice is the largest single objection standing in front of any tool sold to a panel owner, and a vendor who has not read it carefully will answer it badly. So here is the accurate reading, in both directions, followed by the part where it points at us.

Read it accurately, in both directions

The half a vendor would rather you skipped: this is a direct, public instruction from the platform you pay every month, telling you to stop using software shaped exactly like theirs. It is not a competitor’s marketing and it is not a forum rumour. It came from the people who run your panel, and every prospect any tool vendor speaks to has seen it.

The half owners tend to over-read: the notice closes with a line about panels involved in such activity being blocked, and that is aimed at panels found operating with stolen or purchased keys — not at an owner who chose to connect a legitimate tool. It is not a ban on third-party software. It is a warning about where keys end up.

Both halves are true at once, which is why the useful response is neither to ignore the notice nor to swear off tools entirely. It is to get specific about what a key can actually do.

A panel admin key is not a read-only key

This is the part that gets glossed over, usually by people selling something. A panel admin API is not a reporting interface with a read-only mode bolted on. The same key that reads an order’s status can also cancel orders, change the link an order points at, mark orders partial, request refills and open tickets — and then two more that are different in kind from all of those: create a user account, and put balance on one.

Adding balance is moving money. Not access to data — money, on your panel, into an account somebody else chose. Any evaluation that stops at do I trust these people has skipped the only question that matters, which is what that key is able to do at four in the morning when nobody is watching it.

Five questions, for every vendor, ours included

1. 01Does the product do anything at all before I hand over a key? If the first screen is a key field, the answer is no, and you are being asked to take the entire risk before you have seen the thing work once. A tool that installs on a script tag and treats the key as a separate, later, optional step has decided you should be able to evaluate it first. That ordering is a design choice, and it tells you what the vendor thinks they are entitled to.
2. 02Where is the key stored, and can a person there read it? “Encrypted” on its own is a word, not an answer. Encrypted with what, under a key held where, and is it ever decrypted anywhere a human being can see the result.
3. 03Which endpoints does it call? A vendor who cannot list them has not thought about it. A vendor who lists twelve when the feature plainly needs three has told you something useful about how the thing was built.
4. 04What runs on a schedule? This is the real one. Anything that happens while you are asleep is the risk surface; a screen that acts only when you click is not. Ask specifically whether anything automated can create an account or credit a balance — and ask how that is prevented, rather than whether they intend to.
5. 05What happens when I revoke the key? The tool should degrade — fewer answers, less data, a feature switches off — not break in a way that costs you customers. If revoking it is frightening, you never actually had the option, and the key was never really on loan.

And rotate

If you have ever pasted a panel key into a script from a forum thread, a Telegram DM or a nulled copy of anything, stop reading and rotate it. It is a two-minute job in the admin panel and it is the entire mitigation for a key you cannot account for. The February notice said the same thing, and it was the most useful sentence in it.

The case against us, stated by us

We ask for a panel admin key. There is no scoped, read-only, limited key available to ask for instead — the platform does not issue one — so anything we say about least privilege is a statement about what our code does with a full key, not about a smaller key existing somewhere. That is a genuine weakness and it does not stop being one because it is phrased well.

What we do about it is structural rather than a promise. Nothing that runs on a schedule, no background engine and no AI path in our codebase can create a panel account or add balance to a user; those two calls are reachable only from a screen where an operator clicks them himself. A test asserts it and fails our build if it ever stops being true, which is a different kind of statement from we would never. Keys are encrypted at rest, used only server-side, and never sent to a browser.

What we do not have: no SOC 2, no ISO 27001, no PCI, no independent penetration test, and no uptime SLA. None of them has been attempted. We would rather write that list out than let you find it empty later, and the longer version — including the parts that do not flatter us — is on the security page.

The reasonable position after February is suspicion, and we are not going to try to argue anyone out of it. What we would ask is that it be pointed at the right thing. The question is not whether a vendor seems trustworthy. It is what their software is able to do with your key while you are not looking, and whether they can show you rather than tell you.