Authenticate, explore, and test Sigma's REST API using Postman — step-by-step setup from first request to a working reusable test environment.

Postman is an API platform for developers to design, build, test and iterate their APIs. Postman reports having more than 20 million registered users and 75,000 open APIs, which it says constitutes the world's largest public API hub.

Postman offers a tiered pricing model, with a free option that allows for "designing, developing, and testing APIs". We will use the free tier for testing.

For more information on Sigma's product release strategy, see Sigma product releases

If something doesn't work as expected, here's how to contact Sigma support

Target Audience

Developers who are interested in using the API methods provided by Sigma to automate operations or use functionality embedded in their own commercial applications.

Prerequisites

Free Trial

Footer

Postman offers a native web experience as well as a Desktop version. Either is fine; we will use the web version for simplicity. For this QuickStart there is not much difference in the web/desktop versions of Postman.

If you already have a Postman account you can use that or otherwise you will have to sign up for an account (free tier for our use case):

Login or Sign Up to Postman

After signing into Postman, click into Workspaces:

There are several workflows available in Postman and we will use this one:

Create a new Workspace called Sigma:

Give it the name and description and click Create Workspace:

We want to create a new "Collection" and there are several ways to do that. In our case, we will use the Import option as we will grab the latest Sigma API release from our public API Reference page.

Click the 3-dot menu icon and select Import:

We need to provide the URL to the latest Sigma API. This is available from the Sigma API Reference under the button Download the Sigma OpenAPI Definitions.

Here is that URL:

https://help.sigmacomputing.com/openapi/sigma-computing-public-rest-api.json

Paste the URL into Postman. When ready, we are prompted:

Click Import.

The import will run and Postman will show a running icon:

When done, the API will appear as a new Collection. It may be helpful to rename the collection if you have more than one copy.

Expand the Sigma Computing Public REST API > v2 to see the available methods as below:

To use any API in the web version of Postman, you can either use the Cloud Agent or install the Postman Desktop Agent on your local machine. We will let Postman decide and use the Cloud Agent to keep things simple.

Footer

In preparation for using the API we need to use Sigma to generate a new API Token.

Log onto Sigma (as Administrator). Navigate to Administration > Developer access.

Click the Create New button:

Select REST API, give it a name and description. Some customers create a Service Account user for automation purposes; this is a best practice. Since we are just testing, you can choose any Admin user you prefer. Click Create.

Copy the ClientID and Secret and save them to a secure location. We will use them later. Then click Close:

Footer

Postman variables enable us to store and reuse values in Postman. By storing a value as a variable, we can reference it throughout our API Collection (API).

Creating a dedicated environment in Postman is a great approach for managing variables such as the Sigma access_token.

It not only helps in organizing and isolating your variables based on different stages of development (like testing, staging, and production) but also enhances security by keeping sensitive information such as tokens and secrets scoped to specific environments.

We will only be using one environment, but this is great functionality to know when using Postman to work with APIs.

In any case, we need to manage the Sigma bearer token, so let's do it using Postman environment variables, which is a best-practice.

Here's how you can set up an environment in Postman:

Create a New Environment

Environment variables in Postman allow values to be referenced dynamically. For example, {{access_token}} will retrieve the most recent value stored in that variable, for the current selected environment.

Expand Environments in the lower left side of Postman.

Click + Create:

Give the new environment a meaningful name, such as Sigma API Testing.

Copy and paste the values below into the respective Variable and Value fields:

Variable       /   Initial Value
baseUrl        /   https://api.us-a.aws.sigmacomputing.com
tokenBaseURL   /   https://api.us-a.aws.sigmacomputing.com/v2/auth/token
clientID       /   "Your Client ID"
secret         /   "Your secret"
access_token   /   Leave blank
refresh_token  /   Leave blank
token_type     /   Leave blank
expires_in     /   Leave blank

If unsure where Sigma is hosted, this is found in Sigma > Administration > General Settings > Site:

For the list of API endpoints by cloud platform and region, see Supported regions, data platforms, and features

Modify the baseUrl and tokenBaseURL as needed for the cloud provider.

Use the new environment

Don't miss this step!

Once we have the new environment saved, we need to make it the active one for our API to use it:

Footer

Sigma's API requires that we authenticate prior to use.

We will be using variables that we set up in the last step to request an access_token. This access_token is also known as a Bearer or JSON web token (JWT).

We are going to add a POST method to automate authenticating, retrieving an access_token, and persisting it in a variable.

New POST Method

Click 3-dot menu > Add request:

This opens a new request which we will rename to Authenticate.

Change the method to POST and Authorization to No Auth:

Under the Body tab, add the following values (two are environment variables and one is static):

Be sure to select the x-www-form-urlencoded message type.

grant_type      / client_credentials
client_id       / {{clientID}}
client_secret   / {{secret}}

Provide the request url using the curly-brace format to leverage our environment variable:

{{tokenBaseURL}}

We want to persist this new access_token in our environment variable under the same name.

To do that, we need to add this script to the authenticate method, under the Scripts > Post-response tab:

let responseData = pm.response.json(); // Extract the JSON response
pm.environment.set("access_token", responseData.access_token);   // Bearer token
pm.environment.set("refresh_token", responseData.refresh_token); // Refresh token
pm.environment.set("token_type", responseData.token_type);       // Always "bearer"
pm.environment.set("expires_in", responseData.expires_in);       // Seconds until expiry

Now that we are configured, click Save and Send to try our request. If all is correct, we will get a Status 200 OK and an access token:

We can verify that the access_token has been stored by going back to the environments icon, opening it, clicking edit, and observing that the value has been stored:

We are now ready to proceed to using other API methods.

Footer

Set Bearer Auth Once at the Collection Level

Rather than configuring Bearer Token authorization on every request, we configure it once at the parent Collection and let every child request inherit it. The only exception is the Authenticate request, which already overrides this with No Auth (since it has no token yet — it's the one fetching it).

Click the parent Collection (e.g., Sigma Computing Public REST API) and open the Authorization tab. Set:

Field

Value

Auth Type

Bearer Token

Token

{{access_token}}

Save the change.

List Connections

Let's use the API to Get a list of available Connections.

Expand the API to show the method under V2, connections, List connections and click to select open it in a new tab.

We need to uncheck the checkboxes (item #4 in the screenshot) for Params as we just want to return all the connections:

Confirm the Authorization tab shows Inherit auth from parent — no per-request changes needed.

Click Send. The Body panel returns the list of connections as JSON:

Even if you are only using a Sigma Trial, and have not created a connection yourself, there will be one shown. This is Sigma's sample database, and is included on all Sigma instances by default. Your ID values will be different, of course.

Footer

The API provides methods to add/update/delete connections on a Sigma instance using POST messages. We will demonstrate this by creating a new Snowflake connection that mirrors an existing working one.

For more information, see Create a connection

The easiest way to build a valid payload is to start from an existing, working connection. Use the List connections method from the previous section and locate the connection you want to model. A typical response looks like this:

{
    "name": "Snowflake East",
    "type": "snowflake",
    "account": "YOURORG-YOURACCOUNT",
    "host": "YOURORG-YOURACCOUNT.snowflakecomputing.com",
    "warehouse": "COMPUTE_WH",
    "user": "SIGMA_SERVICE_USER",
    "role": "SIGMA_SERVICE_ROLE"
}

Take note of the account, host, warehouse, user, and role values — these are the fields Sigma needs to reach your Snowflake instance.

Use the following payload as the request body for the Create a connection method, replacing the placeholder values with your own:

{
    "name": "Snowflake via API POST",
    "details": {
        "type": "snowflake",
        "account": "YOURORG-YOURACCOUNT",
        "host": "YOURORG-YOURACCOUNT.snowflakecomputing.com",
        "warehouse": "COMPUTE_WH",
        "user": "SIGMA_SERVICE_USER",
        "role": "SIGMA_SERVICE_ROLE",
        "authType": "key-pair",
        "privateKey": "-----BEGIN ENCRYPTED PRIVATE KEY-----\nMIIFHDBO...\n...\n-----END ENCRYPTED PRIVATE KEY-----",
        "privateKeyPassphrase": "YOUR_PASSPHRASE"
    }
}

Configure the Create a connection method as shown and click Send. A successful result returns a 201 Created response with the new connection's connectionId:

Logging into the Sigma portal we can see we have a new connection:

Footer

You now have a working Postman environment for the Sigma REST API — one you can keep extending as new endpoints become relevant to your work. The setup is more than a one-off test harness; the patterns used here are the foundation for any automation, embedded workflow, or CI/CD integration built on top of Sigma's API.

A few techniques are worth carrying forward to other API work:

From here, the API opens up the broader surface area of Sigma — administration, embedding workflows, content lifecycle, and integration with external systems — all using the same authenticated environment you just built.

Additional Resource Links

Blog
Community
Help Center
QuickStarts

Be sure to check out all the latest developments at Sigma's First Friday Feature page!

   

Footer