API tokens instead of your WHM password

If a script needs to talk to your server, give it a token rather than your password. A token can be limited to the few things that script actually does, revoked on its own, and traced when something goes wrong. A password can do everything, forever, and tells you nothing about who used it.

The difference that matters

• Scope. A token can be restricted to a small set of permissions. Your password grants everything you can do.
• Revocation. Deleting a token breaks one script. Changing your password breaks every script at once and locks you out of your own routine.
• Attribution. Tokens are named, so a log entry tells you which integration acted. Password use is anonymous by design.
• Blast radius. A leaked token does what it was scoped to. A leaked password owns the network.

Where the leak usually comes from

Not from an attack. From a credential written into a file that later ends up somewhere it should not be:

• A deployment script committed to a repository.
• A backup of that repository sitting in a web-accessible directory.
• A configuration file copied between environments.
• A password pasted into a chat message or a ticket.

Every one of these is ordinary carelessness rather than sophistication, and every one is survivable with a scoped token and fatal with an unscoped password.

How to use them well

1. One token per integration. Not one shared token for everything. The point is to be able to revoke a single thing.
2. Name it after what uses it. Six months later "backup-script" is useful and "token1" is not.
3. Grant the narrowest permission set that works. Start with too little and add, rather than starting with everything and never trimming.
4. Restrict by source address where the tool allows it. A token that only works from your own machine is dramatically less useful to anyone else.
5. Review the list periodically. Tokens for tools you stopped using are pure liability.

Storing them

Treat a token like a password, because it is one. Keep it out of source control, out of world readable files, and out of anything that gets backed up into a web directory. Read it from an environment variable or a file outside the document root rather than embedding it in a script.

If a token appears in a place you did not intend, revoke it and create a new one. That takes a minute and is the entire benefit of using tokens in the first place.

Never in a support conversation

Nobody here will ask for your password or your token, and you should never send either in a ticket, a chat or an email. Support can act on your account through its own authenticated route; sharing credentials adds risk without adding capability. This is the same rule as the one on our contact page, and it holds in both directions.

On a network, this compounds

One WHM login owning many accounts means one leaked credential exposes every site you run. That is the specific reason tokens matter more here than on a single site: the thing you are protecting is not one account, it is the whole portfolio and every dedicated address in it.

Pair this with distinct credentials per account rather than one reused everywhere. Filesystem isolation between accounts, covered in Platform and Limits, does nothing if the same password opens all of them.

The API and token documentation is at api.docs.cpanel.net.