Guide to API Authentication in WHM
cPanel & WHM supports several API authentication methods. Whenever code calls an API function, it must first authenticate to the server. The authentication process accesses the server in order to run code as a specific cPanel or WHM user with a specific set of permissions.
This document only includes cPanel & WHM authentication methods.
API calls that use a method that includes a URL must use the correct port:
2082— Unsecure calls to cPanel’s APIs.
2083— Secure calls to cPanel’s APIs.
2086— Unsecure calls to WHM’s APIs, or to cPanel’s APIs via the WHM API.
2087— Secure calls to WHM’s APIs, or to cPanel’s APIs via the WHM API.
2095— Unsecure calls to cPanel’s APIs via a Webmail session.
2096— Secure calls to cPanel’s APIs via a Webmail session.
Otherwise-correct calls will return
Permission denied or
Function not found errors if they use an incorrect port number.
To call API functions through a web browser, you must first log in to WHM or cPanel.
- The API function determines which cPanel, Inc. product to log in to.
- Some functions require specific feature lists or user permissions.
Access hash authentication
This method is only available for WHM authentication. Applications and scripts must authenticate as the
root user in order to use this method.
An access hash is a key that authenticates with the server as the
root user. Scripts can include an access hash in the HTTP header that they send to the server during API functions.
- To view or retrieve an access hash, use WHM’s Remote Access Key interface (Home >> Clusters >> Remote Access Key).
- The system stores access hashes in the
.accesshashfile in each user’s home directory.
Username and password authentication
Do not use this method to authenticate over an unsecured connection (port
2082). Only use this method with a secure SSL connection over port
2083 (cPanel), port
2096 (Webmail), or port
Scripts can include the username and password in an HTTP header. The script sends an HTTP header to the server during API functions. This allows the script to effectively log in as the desired user before the function.
We introduced this feature in cPanel & WHM version 54.
The Two-Factor Authentication feature requires an additional six-digit security code to log in to cPanel & WHM. A smartphone with a supported time-based one-time password (TOTP) app provides the security code.
2FA with Session-based Authentication
This script sends the OTP once to establish an authenticated session, and then performs all of the API calls within that session.
2FA with Basic HTTP Authentication, Not Session-based
This script allows you to perform API calls without the need to establish a session, but requires you to send the OTP token with every request in the
X-CPANEL-OTP header. This script also requires that you know the 2FA secret in order to generate the required tokens.
Single Sign On
We introduced this feature in cPanel & WHM version 11.40.
The Single Sign On feature generates a temporary session to authenticate with cPanel & WHM.
For example, this feature generates a temporary session whenever the
root user or a reseller uses the following methods to access a cPanel user’s account:
- WHM’s List Accounts interface (Home >> Account Information >> List Accounts).
- WHM API 1’s
Third-party applications with WHM access can use this feature to log in to cPanel accounts without the need to store their account passwords. The system automatically destroys the temporary session when it logs out or expires (sessions expire after 15 minutes of inactivity). This feature also creates temporary sessions when a cPanel user logs in to Webmail through the cPanel interface.
To use this method, perform the following steps:
- Call WHM API 1’s
- Send a GET request to the URL that the function returns as the
The session will not function until you send this request. The GET request to the login URL returns a cookie that must exist for subsequent API calls to authenticate successfully.
- Configure your script to use the temporary session ID and security token to access the account through either the access hash or username and password methods.
The Single Sign On session log
Whenever the Single Sign On feature generates or destroys a temporary session, the system stores information to the Single Sign On session log:
127.0.0.1 [12/05/2013:06:36:09 -0000] PURGE fz49w:ym5mFKRIAChAQ_yHyn6i19p6DQupDepQN4I3HnH490AAWPFSP2ZipQ7YpE_uA_CG logout 127.0.0.1 [12/05/2013:06:36:12 -0000] NEW z2p:BADVVmryioLExTGvKITEbSuDFHztNAyEeetBPpUmA8sA8Iu_y4eofHZmbbzIG2UU address=127.0.0.1,app=cpaneld,creator=z2p,method=handle_form_login,path=form,possessed=0 127.0.0.1 [12/05/2013:06:36:13 -0000] PURGE z2p:BADVVmryioLExTGvKITEbSuDFHztNAyEeetBPpUmA8sA8Iu_y4eofHZmbbzIG2UU loginsucess 127.0.0.1 [12/05/2013:06:36:13 -0000] NEW z2p:qgBu2rqQh_9R4tDhD2qgqVx0Oy21Ezy6_E581eYvBv0AbuA5oMZAWw_l0vahOhiH address=127.0.0.1,app=cpaneld,creator=z2p,method=handle_form_login,path=form,possessed=0
The system logs the following types of entries:
NEW— The system logs a
NEWentry for each new temporary session.
PURGE— The system logs a
PURGEentry each time that it removes a temporary session.
NEW entries include the following information in a comma-separated list:
|(Session ID)||The session ID that the system created.|
Unlike other log entry items, the session ID does not appear in
|A valid session ID.|
|The IP address that requested the session.||A valid IP address.|
|The application that created the session.||A valid application or service name.|
|The WHM account that created the session.||A valid WHM username.|
|The method through which the user created the session.|
|The path to the process that created the session.|
|Whether the session runs with another user’s privileges (impersonation).|
PURGE entries include the session ID, and one of the following reason codes:
|The temporary session authentication failed.|
|The session expired.|
|The system stopped the session but did not provide a reason.|
|The creator logged in with a session token that the system destroyed when it created the new session.|
|The creator logged in successfully and the system created a new session.|
|The creator logged out.|
|WHM transferred the session to cPanel.|
|cPanel transferred the session to Webmail.|
|cPanel transferred the session to WHM.|
Secure remote logins
To allow users to log in to cPanel & WHM remotely, write a script that calls the
get_loggedin_url() subroutine. This subroutine returns a URL for remote logins to cPanel, WHM, or Webmail.
- In cPanel & WHM version 11.38.0 and earlier, the URL is a single-use URL.
- cPanel & WHM version 11.38.1 introduced reusable remote login URLs. These URLs expire when the user logs out, or after a normal session timeout.
When you call the
get_loggedin_url() subroutine, you must pass in the following parameters:
The cPanel, WHM, or Webmail username.
|A valid username.|
In most scripts, retrieve this value from user input.
The account’s password.
|A secure password.|
In most scripts, retrieve this value from user input.
The cPanel, WHM, or Webmail account’s main domain.
|A valid domain on the server.|
The account’s service type.
The location to which the script will redirect the user. The
|A valid path, relative to the|
get_loggedin_url() subroutine returns the following values:
|boolean||Whether the function authenticated the user successfully.|
|string||A status message from the subroutine.|
|string||The secure remote login URL.||A valid URL that includes a valid session token and directs the user to the|