Configure values for actions in Postman Flows

When you create an action, you'll often want to include static values for its blocks to use. This includes both parameters used in HTTP requests and variables used in other kinds of blocks.

In Postman these values are called configurations. This topic explains how to use configurations - it's similar to using environments in a collection - and what to expect when others use your deployed action.

The Configurations panel in an action's Settings is the place where you'll specify these values. When you set the type of a configuration to Secret there, Postman encrypts it and stores it securely.

Select the same workspace

Users who clone an action you've deployed won't see the values you've set, but they will see the names of all the configurations you've created. They can then enter the values needed to run it on their own systems.

To use a configuration that you've set, add a Get Configuration block on the canvas or inline within another type of block.

This topic assumes that you have begun to create an action.

Identify values your action will need

Here are some examples of the kinds of values your actions might need:

  • API keys that HTTP Request blocks use to communicate with APIs
  • Channel IDs for Discord, Slack, or similar platforms
  • Version numbers for APIs that your action calls
  • Secret keys that Evaluate blocks use to compute HMAC signatures for HTTP headers

Often, a particular value will be used in multiple places within an action. When you change a value in the Configurations panel, Postman applies that single change throughout the action. This helps when, for example, you need to change the target Slack channel your action sends messages to, or to update the version of an API your action calls.

Before creating configurations for your action, it's a best practice to figure out what values your action will need and decide how you want Postman to treat each value. The options are Secret, String, Bool, and Number.

Create or view configurations for your action

To create configurations, complete the following steps. To view configurations, stop once you get to Configurations.

  1. In the right sidebar, click Setting icon Action Settings.
  2. Under Configurations, create and set the desired values.
  3. By default, Postman designates values entered here as Locked icon Secret, and encrypts the values. For values that you don't want to treat as secrets, use the dropdown to set their type to String icon String.

Create a Get Configuration block

You can either add a Get Configuration block on the canvas, or insert one inline in the blocks listed here.

Override configuration values when deploying actions

When deploying an action, you can temporarily override the value of a configuration. This helps when, for example, you create and test an action in a development environment, but deploying the action into production requires overriding one or more configurations.

To deploy an action while overriding configurations, do the following:

  1. Click Deploy to open the deployment modal.
  2. From the Configurations dropdown, enter new values for the configurations you want to override.
  3. Enter your desired values for all other required or desired settings.
  4. Click Deploy within the deployment modal.

The new value will only override the original value for the deployment where you've configured. For users who access the action at its deployment URL, the new value will apply.

When you return to the action, the Configurations panel keeps the original value. If you deploy the action a second time, Postman restores the original value, because overrides you make in one deployment don't automatically carry over into subsequent deployments.

Use configurations instead of environment variables

When you first create and test requests in a collection, you'll typically use environment variables. When you use those same requests in a flow module or action, however, you'll want to recreate those environment variables as configurations.

Using configurations rather than environment variables is a best practice for the following reasons:

  • While only HTTP Request blocks can access environment variables, any kind of block can access configuration values.
  • For security reasons, cloning an action doesn't clone its environment. By contrast, cloning does clone the key names, but never the values, of the action's configurations. Postman will require whoever clones the action to enter their own values for those configurations. This makes actions that use configurations, rather than environments, ideal for sharing.
  • When deploying an action, you can't override an environment; you'll need to update every request manually.

Note that you can't access configurations from a pre- or post-request script.

Last modified: 2025/06/10