Skip to main content
The beta Adaxes integration lets Serval workflows read and manage directory objects, enable, disable, or unlock accounts, reset passwords, manage group membership, and execute Adaxes custom commands. Requests use your Adaxes REST API component and run with the permissions of the account that issued the connection token. Adaxes business rules and approval requirements still apply.

​
Prepare Adaxes

  1. Install the Adaxes REST API component and record its HTTPS base URL. The URL includes the IIS virtual directory chosen during installation, for example https://adaxes.example.com/restApi.
  2. Create a dedicated service account. Grant it the Adaxes security roles and directory scope required by your workflows. For inventory workflows, start with read permissions. Grant account, membership, or custom command permissions only when those operations are required.
  3. Generate an access token for that account using New-AdmAccountToken from the Adaxes PowerShell module. Keep the token private.
  4. Review the REST API’s allowed operations and custom commands and directory object access restrictions. These settings can restrict calls even when the account has permission.
Adaxes tokens inherit the issuing account’s security roles. Disabling or expiring the account makes its tokens unusable until the account becomes active again. See the Adaxes authentication documentation. This connector uses access token authentication. The legacy username/password authentication documented for Adaxes 2025.1 and earlier is not supported.

​
Connect in Serval

  1. Open Integrations, select Adaxes, and start a connection.
  2. Enter the REST API URL, including the configured virtual directory. Enter the base URL only, without an /api/directoryObjects endpoint, query string, or fragment.
  3. Enter the Access token and submit the form.
  4. Run the read-only healthchecks to check connectivity, authentication, and directory read permissions. These checks do not establish that the account can perform writes.
Serval stores the token as a secret and adds it to the Adm-Authorization header. Workflow authors do not need to supply it. Changing the server or REST API path requires entering the token again. Leaving the token unchanged while editing the same endpoint preserves the stored secret.

​
Private networks

Your configured Serval deployment must be able to reach the REST API over HTTPS and trust its TLS certificate. For an Adaxes installation reachable only within your network, use a compatible self-hosted worker and configure the connection to route requests through that worker. See private network access. A private hostname alone does not select a worker route.

​
Use in workflows

Use adaxes.apiRequest with a supported method, path, query, and JSON body. Object identifiers, properties, search criteria, and permissions follow the Adaxes REST API reference. Search is a POST /api/directoryObjects/search request. Set a narrow search base, criteria, and a sizeLimit appropriate for the workflow. The endpoint does not expose a continuation cursor: reaching the limit may mean the result is incomplete. Do not infer that an object was deleted or that an inventory is complete from a bounded search. Group-member reads can also be limited with sizeLimit. Directory-property writes use Adaxes property names, types, and value arrays. Check the property value documentation when setting multivalued properties or replacing, appending, and deleting values.

​
Operation results and approvals

Adaxes can return HTTP 200 even when a write fails or requires approval. The SDK checks the returned operation result and fails the action for an error or a suspended operation. A suspended operation may have submitted an approval request; it has not completed the requested change. Check the actual Adaxes state before retrying a write whose result is uncertain. Retrying can duplicate a provisioning action or approval request. Synchronous execution is supported; opting into asynchronous execution with Adm-Wait is outside this connector’s API.

​
Scope and troubleshooting

This integration provides workflow API access on demand. It does not automatically synchronize users or groups into Serval and does not include knowledge ingestion. Available operations depend on your Adaxes release, REST API configuration, account security roles, and directory scope. If a healthcheck fails, check the complete REST API base URL, DNS and worker routing, TLS trust, token validity, account status, and read permissions. Adaxes uses HTTP 440 for an invalid or expired access token. See Adaxes errors and status codes. Validate the particular write operations your workflows need against a non-production Adaxes installation before using them in production. Read-only healthchecks do not validate password changes, provisioning, membership changes, custom commands, or approval outcomes.