Skip to main content

​
About Sigma Computing

Sigma Computing is a cloud business intelligence and analytics platform. Serval connects to your Sigma environment with an API client (a Client ID and Client Secret) created in Sigma’s Developer Access, plus your regional API base URL. Once connected, Serval handles authentication entirely behind the scenes and workflows can call any part of Sigma’s REST API on demand - roughly 120 endpoints, mostly API versions 2 and 2.1, covering workbooks, members, teams, connections, datasets, data models, workspaces, and governance. Authentication: OAuth 2.0 client credentials - a Sigma API client’s Client ID and Client Secret, exchanged for access tokens that Serval obtains and refreshes automatically. There is no sign-in flow and no scopes to choose. Data sync: None. No background sync or ingestion starts when you connect - the integration is purely on-demand through workflows.

​
What the Sigma Computing integration enables

Anything defined in the Sigma REST API can be accessed through Serval.

​
Get your credentials

Serval needs a Sigma API client - a Client ID and Client Secret - created under Administration > Developer Access, plus the API base URL shown on that same page. Sigma’s OAuth does not use scopes: the API client can do exactly what its owner’s account type allows, so it should be owned by a user with the Admin account type if Serval will manage members, teams, account types, or governance. Sigma’s official guides: Sigma REST API - Get started and Generate Sigma API client credentials.
1

Open Administration in Sigma

Log in to Sigma and click your profile icon in the top right, then open Administration.
2

Go to Developer Access

Select Developer Access from the left sidebar.
3

Create an API client

Create a new API client (Create New / Add Client) and give it a descriptive name such as “Serval Integration”.
4

Copy the Client ID and Client Secret

Copy both values. The Client Secret is shown only once - store it securely before closing the dialog.
5

Note your API base URL

The Developer Access section also shows your API base URL. It depends on your cloud and region - for example aws-api.sigmacomputing.com (AWS US West), api.us-a.aws.sigmacomputing.com (AWS US East), api.eu.aws.sigmacomputing.com (AWS Europe), api.us.azure.sigmacomputing.com (Azure US), or api.sigmacomputing.com (GCP).
Sigma displays the Client Secret a single time, at creation. If you lose it, you cannot view it again - you must regenerate the API client’s credentials in Developer Access and update the Serval connection.
There are no permission checkboxes anywhere in this process. The API client’s access equals the account type of the Sigma user who owns it - many member, team, account type, and governance operations require an owner with the Admin account type.

​
Connect in Serval

1

Open the Sigma Computing connect form

Add a new Sigma Computing connection from your Serval integrations page.
2

Enter the API Base URL

The API Base URL field is required and is described as “Your Sigma API base URL (without https://). Find this in Administration > Developer Access > API base URL”, with the placeholder aws-api.sigmacomputing.com. Enter the bare hostname only - a value with https://, a path, or a trailing slash is rejected with “Must be a valid Sigma API base URL (e.g., aws-api.sigmacomputing.com, api.us-a.aws.sigmacomputing.com)”. Leaving it empty shows “This field is required”.
3

Enter the Client ID

The Client ID field is required and is described as “Client ID from your Sigma API credentials”. Leaving it empty shows “This field is required”.
4

Enter the Client Secret

The Client Secret field is a required password field described as “Client Secret from your Sigma API credentials”. Paste the complete secret you copied from Sigma.
5

Submit the form

Save the connection. Serval stores the credentials and uses them to fetch Sigma access tokens automatically - workflows never handle tokens.
When you later edit a saved connection, the Client Secret is displayed masked (bullet characters plus its last 4 characters). The stored secret is not carried over when you save changes, so always re-enter the complete Client Secret whenever you save - even if you are only updating the API Base URL or Client ID. If you no longer have the secret, regenerate the API client in Sigma’s Developer Access first. The API Base URL and Client ID fields, by contrast, keep their saved values if you leave them blank on an update.

​
Verifying the connection

Saving the form stores the credentials without testing them against Sigma - this connection does not ship any built-in health checks, so there is no automatic healthy/unhealthy status to read. The credentials are first exercised when a workflow makes a call: Serval exchanges the Client ID and Client Secret for an access token at your API base URL and then runs the request.
To confirm a new connection works, run a workflow that makes a simple read-only call - an identity lookup (“who am I”) or listing workbooks both work well. An authentication failure on that first call means a wrong Client ID or Client Secret, a wrong regional API Base URL, or a revoked API client. A successful call proves the credentials authenticate - it does not prove they can do everything; admin operations still depend on the owning user’s account type.

​
Gotchas and troubleshooting

On the edit form the Client Secret appears masked (bullets plus the last 4 characters). The stored secret is not carried over when you save changes, so re-enter the full, real Client Secret every time you save the connection - even when only the API Base URL or Client ID is changing. If the secret is lost, regenerate the API client in Sigma’s Developer Access and paste the new secret. Blank API Base URL and Client ID values do keep their saved settings on update, but re-entering all three fields is the safest path.
Enter the bare hostname only, for example aws-api.sigmacomputing.com. A value with https://, a path, or a trailing slash fails with “Must be a valid Sigma API base URL (e.g., aws-api.sigmacomputing.com, api.us-a.aws.sigmacomputing.com)”. The host must also be a known Sigma API domain - arbitrary domains are rejected by both the form and Serval’s outbound allow-list.
Sigma runs region-specific environments, each with its own API host, and both Serval’s API requests and the token exchange use the domain you entered - so a wrong region means authentication fails even with a correct Client ID and Secret. Your exact base URL is shown in Sigma under Administration > Developer Access. Serval supports: aws-api.sigmacomputing.com (AWS US West), api.us-a.aws.sigmacomputing.com (AWS US East), api.ca.aws.sigmacomputing.com (AWS Canada), api.eu.aws.sigmacomputing.com (AWS Europe), api.uk.aws.sigmacomputing.com (AWS UK), api.au.aws.sigmacomputing.com (AWS Australia), api.us.azure.sigmacomputing.com (Azure US), api.eu.azure.sigmacomputing.com (Azure Europe), api.ca.azure.sigmacomputing.com (Azure Canada), api.uk.azure.sigmacomputing.com (Azure UK), and api.sigmacomputing.com (GCP).
Sigma’s OAuth does not use scopes and Serval requests none - API access equals the account type of the Sigma user who owns the API client. Many operations (members, teams, account types, connection grants) require an owner with the Admin account type. If those calls fail while others succeed, switch to an API client owned by an Admin.
Sigma displays the Client Secret a single time when the API client is created. Copy it immediately and store it securely. If it is lost, regenerate the credentials in Developer Access and update the Serval connection with the new secret.
Sigma access tokens are valid for one hour. Serval obtains and refreshes them automatically, so workflows never manage authentication and nothing needs to be rotated on a schedule - only if you regenerate the API client itself.
Most list operations return a batch of entries plus a nextPage token. Pass that token back as the string page query parameter (optionally with limit) and repeat until nextPage is null - the hasMore field is deprecated in favor of nextPage. A small number of endpoints (account types, data model sources, and the v3 alpha endpoints) instead use pageToken and pageSize parameters with a nextPageToken response field. Paths in the “Sigma API request” action use curly-brace placeholders filled from the action’s path parameters (for example a {workbookId} segment paired with a workbookId path parameter); colon-style segments such as :workbookId are not substituted.
Need help? Contact support@serval.com for assistance with your Sigma Computing integration.