The Apperian App Management API is a REST API, which means that you can use standard HTTP methods (GET, POST, PUT, and DELETE) to retrieve, submit, change, and delete data. To ensure data privacy, the API is served over HTTPS; unencrypted HTTP is not supported.

How It Works

Each interface provides a set of API resources that let you perform various mobile application management tasks. Each resource has a URL (or endpoint) on the Apperian server. To call a resource, you send an HTTPS GET, POST, PUT, or DELETE request to the appropriate URL, and the Apperian server responds with JSON-formatted data. When you send a POST or PUT request, the body of data you submit must be sent as JSON by specifying a Content-Type of application/json in the HTTP header.

Your code can be written with any tools capable of sending HTTP requests. The examples in this reference use cURL, an open-source command line tool. If you want to use cURL to interact with the API during your development process, it is available at

Base URL for API Resources

Each API resource has the same base URL. There is a different base URL for each Apperian hosted production environment. If you are not sure which hosted production environment you should use, check with Customer Support.

Environment Base URL
North America

If you are working with an on premise or custom implementation of Apperian, check with your IT administrator who manages the installation to obtain the correct base URL.

API Version

Some resources include a v1 version only, while others may include v1, v2, or v3 versions. When you send a request to an Apperian API resource, you should include the version in the resource URL. For example:

Pointing to a specific version ensures that your codebase is backwards-compatible in the event that a new version of a resource becomes available in the future.

When writing new code, always point to the latest version of a resource. If you have existing code that references a v1 version of a resource that now has a newer version available, the v1 resource will still work but you should update your code to point to the newest version.

Older versions may be supported for a period of time, but they are eventually deprecated. Any older resource that now has a new version available includes an Attention note in its documentation that identifies the new resource and the timeframe for deprecating the older version.


Every request sent through the Apperian API must include a valid access token. An access token is a unique string that identifies a user and grants access based on their permissions.

There are two types of tokens used to access the Apperian API:

  • API Tokens
  • User Tokens

API Tokens

API Tokens are the primary method used to access the Apperian API, and are especially useful for repetitive and automated tasks. API Token sessions never expire, which means they can be used indefinitely.

You can obtain API Tokens for any user in the system, though you should typically only create tokens for users with the Administrator role. One user can have multiple API tokens if necessary.

Apperian recommends using API Tokens to access all endpoints except for those in the Catalog API, Downloads and Installs API, and Reviews API. The endpoints in those APIs require User Tokens, which are discussed in the next section.

You can create and manage API Tokens in the Admin Portal or via the Organizations API.

User Tokens

User Tokens are used primarily for end user access through the Catalog API, Downloads and Installs API, and Reviews API. They provide information relating to the user and the user’s device, which is important if you build your own enterprise app catalog, or integrate the ability for users to access and install apps into another system, such as a corporate portal.

You can obtain a User Token by sending a POST request to /catalog/authenticate/. In your request, you’ll specify the user ID and password for a valid user. Apperian responds with a unique User Token for that user.


It is possible to obtain tokens via /users/authenticate/ and use them for accessing the non-end user APIs, but the reasons for doing so are rare, and the API Token method is preferred.

Using the Tokens

Regardless of which method you use to create the token, you will then provide it in the HTTPS header of each request during the API session, like this:

curl -X GET --header "X-TOKEN: eTg8ktZXRqKIBJTHunwP6A"


This example, like the majority of Apperian endpoints, uses the X-TOKEN parameter. However, a few endpoints use a parameter called token. Refer to the documentation for a specific endpoint when determining which parameter to use.

A token identifies a specific user, so you may need to provide different tokens based on who you need to act on behalf of during the transaction.

To call most API endpoints, you need to provide a token for a user who has been assigned the Administrator role. With other endpoints (Catalog, Downloads and Installs, Reviews), you need to provide a token that authenticates the specific end user (any non-Administrator role) for whom you want to perform a task.

In this guide, each endpoint is flagged with an Authentication box under the endpoint header; it indicates whether the endpoint requires user and device context (use a User Token from /catalog/authenticate) or just user context (use an API Token), and whether you can authenticate as any user or need to authenticate as an administrator.

Token Session Expiration

API Tokens never expire, and can be used indefinitely.

User Tokens expire based on whether the authentication uses Remember Me:

  • With Remember Me, the token will expire based on the Remember Me expiration timeout for the organization, which is set to 1 week by default.
  • Without Remember Me, the token will expire based on the default session expiration defined for the organization, which is set to 10 minutes by default.

You can use the Session API to manually extend the session of a User Token.

Authentication for Affiliated Organizations

If you manage affiliated organizations, you can authenticate as an administrator of the parent organization and then send API requests to perform functions in any of your affiliated organizations—without having to re-authenticate. For instructions on doing this, see Sending Requests for Affiliated (Child) Organizations. Note that you should avoid sharing an administrator account when you manage affiliated organizations, and should therefore create a separate administrator user account to use only with API requests.

Controlling GET Responses

When you send a GET request to the following resources, you can specify parameters to search, sort, and paginate the JSON data returned in the response:

  • GET /users
  • GET /applications
  • GET /groups

For instructions on searching, sorting, and paginating GET responses, see Controlling GET Responses.