DigDash REST API

Last modified by Aurelie Bertrand on 2026/06/19 10:37


DigDash provides a REST API for interacting with a number of DigDash objects.
You can use Swagger to test it.

Accessing Swagger UI

Swagger UI allows you to view and interact with API resources.
This interface also provides visual documentation to make them easier to use.

To open Swagger UI, you can:

This will take you to the interface displaying the available API resources, categorised by type.

💡 If the domain name has been changed, you can specify a custom ddapi domain in the ‘domain’ field.

Interface Swagger

Authentication

To interact with the APIs, you must authenticate yourself.

  • Click the ‘Authorise’button in the top right-hand corner of the Digdash API page. (The open padlock icon means you are not authorised.)
    The ‘Availableauthorisations’window will appear.

Three authorisation methods are available:

  • BasicAuth: The Basic Authentication method, which allows you to log in using your LDAP username and password.

  • BearerAuth: The Bearer Authentication method, which uses security tokens known as bearer tokens.

  • ApiKeyAuth: The API Key Authentication method, which allows you to authenticate using an API key.

The BasicAuth method will be used for the initial authentication. You can then generate a security token or an API key and use one of the other two methods.

❗For security reasons, it is not recommended to use theBasicAuth method systematically.

ℹ It is not possible to create a security token (JWT) when authenticated with a security token (JWT).

Authenticating via BasicAuth

  1. Enter your Digdash username and password.
  2. Click the ‘Authorise’ button, then, once authentication is complete, click ‘Close’.
    ➡ The padlock is now closed, indicating that you are authorised.
    You can now create a JWT token or an API key to log in.

Authenticating via BearerAuth

Once logged in via BasicAuth, you can generate a security token to authenticate using the BearerAuth method.

Creating a JWT token

Here, we will create a JSON Web Token (JWT):

  1. Go to the Authentication section.
  2. Click to expandPOST ddenterpriseapi/api/v1/auth/jwt.
  3. Before you begin, you can view an example request and, by hovering over the Schema tab, a description of the various elements.
  4. Click on ‘Try it out’ in the top right-hand corner to define your request. This includes the following elements:
    • targetUser: (Optional) Specify the name of the user to impersonate. This only works if the user used to create the JWT has the Admin > Allow impersonation authorisation (ACL).
      If left blank, the default user is the one currently logged in, which will generally be the case.
    • expires: (Optional but recommended) Specify the JWT’s validity period in the form of a time period in ISO 8601 format (e.g. PT5M for 5 minutes). For further information, see https://en.wikipedia.org/wiki/ISO_8601#Durations.⚠ Only the PnDTnHnMnS format is supported: you can specify days, hours, minutes and seconds, but not years, months or weeks (PnYnMnWnDTnHnMnS).
    • Permissions: Set the permissions for each API type: “none” for no permissions, “r” for read-only, “rw” for read-write.
      For example:
      Exemple authentification

❗A check will be carried out on the user’s permissions in Digdash (ACLs) in addition to the token’s permissions.

  1. Click theExecute buttonto generate the token (JWT).
    ➡ The response is displayed in the Server response section below.
    Réponse serveur
  2. Copy the JWT token.

Signing the security token

A private key used to sign the JWT is generated by default. This key is temporary and is regenerated every time the server is restarted.

To avoid this issue and improve security, it is strongly recommended that you use your own private key to sign JWT tokens using the following environment variables:

  • DD_JWT_SECRETKEY_PATH: this variable is used to specify the path to an RSA private key.
  • DD_JWT_SECRETKEY: this variable allows you to define a custom password.

Please note that the DD_JWT_SECRETKEY_PATH variable takes precedence over the DD_JWT_SECRETKEY variable.

The RSA private key can be generated using the following command (requires the OpenSSL tool):

openssl genrsa -out /path/to/privatekey.pem 2048

The RSA public key can be generated from the private key using the following command (optional):

openssl rsa -in /path/to/privatekey.pem -pubout -out /path/to/publickey.crt

Authenticating

Once the security token has been generated, you can authenticate using this method:

  1. Click theAuthorise button.
  2. In theBasicAuth section, log out by clicking theLogout button.
  3. In theBearerAuth section, paste the JWT token into theValue field.
  4. ClickAuthorise.

Authenticating via ApiKeyAuth

Once logged in via BasicAuth, you can generate a security token to authenticate using the BearerAuth method.

Create an API key

We’re going to create an API key here:

  1. Go to the Authentication section.
  2. Click to expandPOST ddenterpriseapi/api/v1/auth/apikeys
  3. Before you begin, you can view an example request and, by hovering over the Schema tab, a description of the various elements.
  4. Click on ‘Try it out’ in the top right-hand corner to define your request. This includes the following elements:
    • targetUser: (Optional) Specify the name of the user whose identity you wish to assume. This only works if the user used to create the API key has the Admin > Allow identity borrowing authorisation (ACL).
      If left blank, the default user is the one currently logged in, which will generally be the case.
    • expires: (Optional) Specify the validity period of the API key in the form of a time period in ISO 8601 format (i.e. PT5M for 5 minutes). For further information, see https://en.wikipedia.org/wiki/ISO_8601#Durations.⚠ Only the PnDTnHnMnS format is supported: you can specify days, hours, minutes and seconds, but not years, months or weeks (PnYnMnWnDTnHnMnS).
      If the ‘expires’ element is not included in the request, the key has an infinite duration.
    • permissions: Set the permissions for each API type: “none” for no permissions, “r” for read-only, “rw” for read-write.
      For example:
      1745928168043-553.png

❗A check will be carried out on the user’s permissions in Digdash (ACLs) in addition to the token’s permissions.

  1. Click theExecute buttonto generate the API key.
    ➡ The response is displayed in the Server response section below.
    Réponse serveur
  2. Copy the API key.
    ❗The key is only displayed once and cannot be retrieved in any other way, as it is hashed (irreversibly encrypted) when stored on the server for security reasons.

    If a key is lost or no longer required, it must be invalidated and a new key created if necessary.

The API key is stored on the server in a CSV file named apikeys.csv, located by default in the appdata/EnterpriseServer/ddenterpriseapi/config directory.
However, if a custom location has been defined via the ddenterpriseapi.ServerSettingsPathin the digdash.properties file, this configuration takes precedence over the default path.
You can change this directory, or specify multiple directories in the case of multiple domains, in the digdash.propertiesfile by adding them in the following format: ddenterprise.api_keys_path=/path/to/csv-file. 
This property takes precedence over ddenterpriseapi.ServerSettingsPath.

Authentication

Once the API key has been generated, you can authenticate using this method:

  1. Click the Authorise button.
  2. In the BasicAuth section, log out by clicking the Logout button.
  3. In the ApiKeyAuth section, paste the API key into the Value field.
  4. Click Authorise.

Available API resources

List of resources

The available resources are categorised by type:

  • Authentication: for creating security tokens (JWT)
  • User Management: for managing users and related elements: profiles, roles, authorisation groups, role authorisation groups, user settings, etc.
  • Session Management: for retrieving the list of sessions and terminating sessions.
  • System: for system information, audit service and scheduler.
  • Licence Management: for managing licences: activation, users covered by the licence, etc.
  • Event Management: for adding events using fireEvent.
  • Connections: for managing database connections: listing, creating, replacing and deleting.
  • Versions: for retrieving the version of the API or Digdash.

ℹ The closed padlock to the right of the resource indicates that you have authorisation.

Available operations

There are several types of operations that can be performed via the API:

  • GET: to retrieve information. For example, the list of users or system information.
  • POST: to create items. For example, a role or users within a licence.
  • PATCHto update items (only replaces the data to be updated). For example, a user or a permissions group.
  • PUTto replace items (overwrites all data and replaces it).
  • DELETE: to delete items. For example, a user’s permissions.

Sending requests

❗Please note that a check is carried out on the user’s permissions in Digdash (ACLs) in addition to the token’s permissions.

Once you have been authorised, you can make requests:

  1. Expand the resource on which you wish to perform an operation. A closed padlock indicates that you are authorised.
  2. Before you begin, you can view an example request and, by hovering over theSchema tab, see a description of the various elements.
  3. In the expanded method window, click ‘Try it out ’.
  4. Specify the parameter values if necessary. A description is provided in the table below.
  5. Click ‘Execute’.
    The request is executed and the response is displayed.
    A bearer authorisation header is automatically used for your requests.

Swagger also provides curl command-line options when executing requests to help with testing or coding a tool outside the browser (in a script, for example).
Please note that, whether using curl or another tool, you must specify the HTTP headers “Accept” (format of the content to be retrieved) and “Content-Type” (format of the content sent) for the requests to work correctly. These two headers can take the values “application/json” for JSON or “application/xml” for XML.
1725441504464-493.png

Settings

User management
includesYou can add roles, authorisations (ACLs) and/or authorisation groups (groupACLs), as well as licence information, to the query result.
id (required)Specify the name of the user, role, etc., depending on the API to be used for the operation.
resolveGroupAclsIf set to true, the permissions that are part of the profile’s authorisation groups are displayed.
resolveProfilesIf set to true, and if the user has a profile, the profile information will be displayed.
For example, if the user has roles derived from a profile, the roles from the profile will be displayed rather than the user’s own roles.
Session management
usersYou can specify users for the query: click the ‘Add string item’ button and enter a user’s name. Repeat this step as required for other users.         
idSpecify the session name.
System
period numberSpecify the period for which to retrieve the latest cube and security failures in DDAudit (60 seconds by default).
auditServiceSpecify the audit service of your choice: ChangeAuditor, FlowAuditor, SystemAuditor, CubeAuditor, SecurityAuditor, DashboardAuditor or SessionAuditor.
syncher

Specify the synchroniser of your choice: PlayTP, SyncTP, CopyTP or ExportTP.

Connection management
itemRoleYou can restrict the query to database connections limited to the roles specified here.
nameFilterYou can restrict the query to database connections whose name contains the text string specified here.
typeFilterYou can restrict the query to database connections of the type(s) specified here.
id (required)Specify the identifier for the database connection.
Licence management
patternYou can specify a regular expression to filter the users to be retrieved.
For example, the pattern test.* will retrieve all users whose name begins with test.

Authentication expiry

When the security token (JWT) or API key expires, you will receive a 401response :“Unauthorised”.
The Bearer authorisation header is still present in your requests, but the token has expired. When this happens, you must log out of BearerAuth and generate a new access token.

  1. Click the Authorise button to open the Available authorisations window.
  2. Click the Logout button belowBearerAuth or ApiKeyAuth.
  3. ClickClose to close the window.
  4. Generate a new access token or API key as described in the section Authenticating.

Revoke a JWT token or API key

Revoking a JWT token

For a JWT token, revocation is carried out globally only by changing the private key used for signing and the associated public key used to validate signatures.

Revoking an API key

For an API key, revocation can be carried out on an individual or global basis.

To revoke one or more keys:

  1. You can first retrieve the list of API keys and their identifiers by usingGET /api/v1/auth/apikeys. You will receive the list in the following format:
    Liste clés API
  2. Send a list of identifiers (in JSON or XML depending on the Content-Type, as explained in the section Sending Requests) to "POST /api/v1/auth/apikeys/delete" to revoke one or more keys

To revoke all API keys, either delete all keys as described above or delete the csv file `apikeys.csv` containing the keys whilst the server is switched off.