Manage cPanel API tokens as credentials, not ordinary text

An API token can allow software to perform account operations without an interactive password prompt. Treat it as a credential with potentially broad impact, not as a harmless identifier.

Before creating a token

Identify the service that needs it, the operations required and whether the provider supports appropriate restrictions and expiry. Confirm that the integration is reputable and that its destination URL is correct.

Use a controlled lifecycle

1. Create a separately named token for the integration in the supported cPanel interface.
2. Set an appropriate expiry where available and record the token’s owner and purpose.
3. Transfer it through an approved secret-management method. Store it on the server or in the integration’s protected credential store.
4. Test only the intended operation and check that errors do not log the token.
5. Revoke it when the integration is removed or suspected of exposure.

Never put tokens in public JavaScript, website source, query-string URLs or screenshots. Separate tokens make revocation easier than a single shared credential used by several tools.

Do not assume a token is narrow simply because its name says “read-only.” Verify the actual permission model offered by the host. If a secret appears in Git or a public page, remove the exposure and replace the credential; deleting the visible text alone is insufficient.