Can I automate account tasks without sharing my password

Yes, and it is the right way to do it. Issue a limited API token for each automated tool rather than embedding your login credentials anywhere.

Why a token wins

• It is narrow. You grant only the handful of capabilities that one tool requires.
• It cancels independently. Withdrawing one stops one tool. Changing your login stops every tool you own simultaneously, plus you.
• It has a name, so records show which tool did what. Credential use is indistinguishable from you.
• Exposure is bounded. An escaped token performs only what it was granted; escaped credentials hand over the entire estate.

How exposure actually happens

Rarely through anything sophisticated. Far more often a deployment file reaches a public repository, a settings file gets copied between environments, or something is pasted into a message thread. All ordinary, all recoverable when the secret was limited and serious when it was not.

Practical habits

1. A separate token for each tool, never a communal one.
2. Name it for the tool, so it still makes sense to you next year.
3. Begin with too few capabilities and widen only when something genuinely fails.
4. Tie it to a source address wherever the tool permits it.
5. Withdraw tokens belonging to tools you have retired.

Storing it

Handle it the way you would handle a password. Keep it away from version control, away from files the web can serve, and out of archives that land in public directories. Have the script read it from an environment variable or a location above the site root instead of carrying it inline.

If one appears somewhere unintended, withdraw it and issue a replacement. That is a minute of work, and being able to do it without disturbing anything else is the whole reason for working this way.

What we will never ask for

We do not need your login or your token, and you should not put either into a ticket, a message or an email. Our support route is authenticated independently, so handing over secrets adds exposure without adding capability.

Does this apply to the panel logins too?

Tokens cover automation. For the panels themselves, the equivalent discipline is a different password per account and, where offered, a second factor on the login that owns everything.

What if a contractor needs access?

Give them the account they are working on rather than the layer above it, and change that password when the work ends. Never hand over the credential that covers your whole estate.

Also keep account passwords distinct from one another: separation between accounts counts for nothing if a single credential unlocks them all. See WHM and Accounts and the token reference at api.docs.cpanel.net.