Page tree
Skip to end of metadata
Go to start of metadata

Many actions in the GoodData platform require or result in the generation of a token. Typically, a GoodData token is a hashed value that provides a unique reference within your GoodData organization to an object, which can be an object (like a project) or an action (which would be a SQL query that performs a specific change in the platform).

This article attempts to provide basic information on the different types of GoodData tokens.


Project Tokens

When you are performing technical references to a project in the GoodData platform, you typically refer to the project using a token of one of the following types.

Project Authorization tokens

If you are creating new projects in the GoodData platform, you must submit to the project creation API a project authorization token. This token enables the user of it to create a new, empty project in the platform.

For example, in the image below, your project authorization token must be inserted into the Authorization Token field in order to create a new GoodData project on the server through CloudConnect Designer:

Using a project authorization token in CloudConnect

Depending on your GoodData license, you should have been provided a project authorization token, which enables you to create a predefined number of projects in the platform.

Project tokens

After a project has been created, all references to the objects in the project, including data model objects, metrics, etl graphs, and more, must include the internal identifier for the project.

The easiest way to retrieve the project identifier is through the GoodData Portal. In the image below, the project token can be extracted from the URL:

URL contains project token
In the above, the project token is the following value:


When you are referencing objects of this specific project via API, you must include this identifier as part of your reference to the appropriate API endpoint. For example, a GET to the following API endpoint returns a list of the user roles defined in the above project:

For more information, see Acquiring Object Identifiers Project Metadata.

Project Template tokens

When you are publishing multiple projects from a single project, you can create a project template of the source project. This template contains all of the reporting objects and the data model of the source project. When this template is created, a token is returned for your use.

When you are creating the new projects via API, you can reference the project template token, which instructs the platform to add all of the templated assets into the new project. So, your new project is prepopulated with content from the old project.

Some objects are not created in the new project from the source project, including ETL graphs and any Data Permissions.

For more information, see Create Project Template.

Export/Import Tokens

When you use the GoodData APIs to perform full or partial exports of a project, the platform returns a token, which you can use to reference the bundled content. The export API generates a token in the response, which must be retained. When the import API call is made, the token must be included in the request. For more information on full or partial project exports and imports, see the API documentation on projects.

Authentication Tokens

Logging to the GoodData platform requires two tokens.

Use of these tokens is necessary if you are accessing the platform from a non-browser interface, such as the GoodData APIs.

The tokens:

  1. super-secure token (SST) - When you first login to the GoodData platform, you receive in the response header the SST. This token must be included whenever you query for a temporary token.
  2. temporary token (TT) - Using the token API, you can generate a temporary token, which is valid for 10 minutes. Any request for project objects requires the use of a temporary token as part of the request. When it expires, you must renew it.

For more information, see Authentication via API.

And Other Tokens…

Since GoodData supports integration with a wide variety of enterprise platforms, you may be required to manage tokens issued from those platforms for authentication and object reference.

  • No labels