Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt

Use this file to discover all available pages before exploring further.

API tokens are the primary authentication mechanism for the Gatling Enterprise Edition public REST API and its official integrations—CI plugins, Maven/Gradle/sbt build plugins, and the JavaScript CLI. Each token carries a set of permissions that determine which operations the bearer can perform, making it straightforward to grant the minimum necessary access to each integration or automation script.

​
Accessing the API tokens page

Navigate to API Tokens in the Gatling Enterprise navigation bar. Any user with the Leader role or higher can access their own tokens; Administrators can manage tokens for the entire organization.

​
Creating an API token

1

Open the creation form

Click the Create button on the API Tokens page.
2

Name the token

Enter a descriptive name that makes the token’s purpose clear (for example, GitHub Actions CI or Maven build pipeline). This name appears in the tokens table and helps you identify which token to rotate when credentials are compromised.
3

Set permissions

Choose the permission level for this token. Permissions can be set globally (applying to all teams in the organization) or scoped to a specific team.
PermissionWhat it allows
NoneNo access. Useful to explicitly restrict global access while granting team-specific permissions via a separate entry.
ReadRead all data: simulations, runs, reports, trends.
StartStart test runs + Read permissions. Use this for CI plugins that only need to trigger runs.
ConfigureCreate/upload packages, create tests + Start permissions. Use this for build plugins that deploy packages and configure simulations.
AdministrateFull management of all organization resources: users, teams, tokens, packages, tests.
CI plugins (GitHub Actions, Jenkins, etc.) need the Start permission.
Build plugins (Maven, Gradle, sbt, JavaScript CLI) need the Configure permission to upload packages and register simulations automatically.
4

Copy the token value

After creation, the token value is displayed once. Copy it immediately and store it securely (in a secrets manager, CI/CD secrets store, or environment variable). It cannot be retrieved again after you close this dialog.

​
Using the token

All Gatling Enterprise API requests require the token in the Authorization HTTP header: 
Authorization: <your_api_token>
Example with curl: 
curl -X GET "https://api.gatling.io/api/public/simulations" \
  -H "Authorization: <your_api_token>"
For build tool plugins, configure the token as an environment variable or in your build configuration file: 
<plugin>
  <groupId>io.gatling</groupId>
  <artifactId>gatling-maven-plugin</artifactId>
  <configuration>
    <apiToken>${env.GATLING_ENTERPRISE_API_TOKEN}</apiToken>
  </configuration>
</plugin>

​
Managing existing tokens

The tokens table shows all tokens, their names, permission levels, and scope (global or team-specific). Available actions:
ActionHow
Edit permissionsClick the pencil icon (✏️) on the right side of the token row
Regenerate tokenClick the undo/rotate icon (↺) to issue a new token value and invalidate the old one
Regenerating a token immediately invalidates the previous value. Any service or integration using the old token will lose access until it is updated with the new value. Coordinate regeneration with the teams that own the affected integrations.

​
Token scoping best practices

Principle of least privilege

Grant only the permissions a token actually needs. A CI pipeline that only triggers runs does not need Configure or Administrate access.

Separate tokens per integration

Create one token per integration (one for CI, one for Maven, etc.). This way you can rotate or revoke individual tokens without disrupting unrelated workflows.

Use team-scoped tokens

Scope tokens to the specific team whose resources the integration accesses, rather than granting global permissions.

Store tokens as secrets

Never commit tokens to source control. Store them in a secrets manager (AWS Secrets Manager, HashiCorp Vault, GitHub Actions Secrets, etc.).

Build docs developers (and LLMs) love

Get started for freeTalk to us