# Postman > Postbot add-on is available in [Enterprise plans](https://www.postman.com/pricing/) with a limited number of activities per user each month. If you purchased Postbot on a Free, Basic, or Professional --- # About Postbot Postbot add-on is available in [Enterprise plans](https://www.postman.com/pricing/) with a limited number of activities per user each month. If you purchased Postbot on a Free, Basic, or Professional plans before December 1, it'll continue to work for you. Learn more about [resource usage in Postman](/docs/billing/resource-usage/). Postbot is your AI assistant for API workflows in Postman. You can ask Postbot to help you troubleshoot API requests, write test scripts and documentation, and make sense of large data sets. You can also ask Postbot if you need help using Postman or aren't sure what to do next. Postbot provides the following benefits for Enterprise teams: * **Enterprise-grade availability** - With dedicated infrastructure and separate compute bandwidth for your team, Postbot is always there when you need it. * **Enhanced privacy** - Training data from your Postbot activities is used to improve the experience for your team only. You can manage Postbot access for your team in your [product access dashboard](/docs/administration/managing-your-team/manage-team-product-access/). To get unlimited Postbot activities for team members, you can [purchase add-on seats](/docs/billing/billing/#purchasing-add-on-products). ## Get started with Postbot To use Postbot, click ![Image 1: Postbot icon](https://assets.postman.com/postman-docs/v10/icon-postbot-v10-16.jpg#icon) **Postbot** in the Postman footer. Postbot offers suggested actions based on what you're doing in Postman. Select one to get started. Or enter your own prompt using natural language, and Postbot will help you complete your work. ![Image 2: Postbot usage example](https://assets.postman.com/postman-docs/v11/postbot-example-v11a.jpg) ## What you can do with Postbot Here are ways you can use Postbot to assist your work in Postman: * **Add API tests** - Postbot can add test scripts to your API requests. Use Postbot to add a new set of tests, fix your existing tests, or save a field from a response. Postbot also provides real-time code completion suggestions as you type. Learn more at [Write tests using Postbot](/docs/tests-and-scripts/write-scripts/test-scripts/#write-tests-using-postbot). * **Write API documentation** - Postbot can write documentation for API requests. Use Postbot to automatically add descriptions, including request parameters and response examples, to your requests, or make edits to existing documentation. Learn more at [Writing documentation with Postbot](/docs/publishing-your-api/authoring-your-documentation/#writing-documentation-with-postbot). * **Debug requests** - Getting an unexpected error when sending a request? Postbot can help you find the source of the problem and fix it. Learn more at [Debugging requests with Postbot](/docs/sending-requests/response-data/troubleshooting-api-requests/#debugging-requests-with-postbot). * **Visualize response data** - Use Postbot to view API response data as a table, chart, or graph. Or you can ask Postbot to visualize the data in other ways by entering a prompt. Learn more at [Use Postbot to create visualizations](/docs/sending-requests/response-data/visualizer/#use-postbot-to-create-visualizations). * **Get help** - Postbot is trained on Postman Docs content. If you get stuck in Postman, try asking Postbot for help. It will offer steps you can follow and point to more in-depth documentation. ## Turn off Postbot If you don't wish to use Postbot, you can turn it off in Postman's settings. 1. Go to ![Image 3: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the Postman header. 2. Click **Settings > AI**, and toggle off **Keep using legacy chat**. --- # Deploy flows as actions in Postman Flows An _action_ is a flow that's deployed in the Postman cloud. Unlike [_flow modules_](/docs/postman-flows/get-started/build-your-first-flow/), which must be run manually, actions can be scheduled, or triggered by external systems like third-party services, other APIs, or webhooks. Actions are useful for running automations and exposing functionality as an API or as an AI tool for MCP servers. ## Create an action To create a new action, do the following: 1. In the **Flows** tab, select ![Image 1: Create a new folder or flow](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create a new folder or flow** > ![Image 2: Flows action icon](https://assets.postman.com/postman-docs/aether-icons/action-flowsAction-stroke.svg#icon) **Create action**. The action appears with a [**Request** block](/docs/postman-flows/reference/blocks/request/), a placeholder [**Template** block](/docs/postman-flows/reference/blocks/template/), and a [**Response** block](/docs/postman-flows/reference/blocks/response/). The **Request** block's three output ports will send headers, query parameters, and body data received from an external API call. 1. Delete the **AI Agent** and **Display** blocks if you don't need them. 1. Set up the [**Request** block](/docs/postman-flows/reference/blocks/request/). 1. Add and connect blocks to [create a flow](/docs/postman-flows/get-started/build-your-first-flow/) that processes data from one or more of the **Request** block's output ports. The flow will also route data to the **Response** block's **Status Code**, **Headers**, and **Body** ports. 1. Set up the [**Response** block](/docs/postman-flows/reference/blocks/response/) to return status codes and include routed data in the response's headers and body according to your requirements. 1. Click **Run** to test your action locally with [scenario](/docs/postman-flows/build-flows/configure/scenarios/) data. You can design your actions to be _synchronous_ (sync) or _asynchronous_ (async). In a sync action, all the blocks complete their functions before the action sends a response. An async action sends a response before its blocks finish running. For more information, see [Synchronous and Asynchronous actions](/docs/postman-flows/reference/flows-actions-overview/#synchronous-and-asynchronous-actions). Learn more about creating actions with this [video tutorial](/docs/postman-flows/tutorials/video/work-with-actions/). ## Deploy an action After you create an action you can _deploy_ it to make it publicly available. For more information about deploying actions, see [Deploy actions with snapshots](/docs/postman-flows/reference/flows-actions-overview/#deploy-actions-with-snapshots). To deploy an action to the cloud, do the following: 1. In your action, click **Deploy** and enter the following: * **Snapshot** - Create a new [snapshot](/docs/postman-flows/build-flows/configure/snapshots/) of the action or select an existing snapshot. This is the version of the action that will be deployed. * **Action URL** - This path will be added to the domain where the action is deployed. You can use the resulting URL to call the action. * **Timeout** - Sets the amount of time that the action will wait before sending a 408 Request Timeout error if it hasn't finished running. Enter a value between 5 and 30 seconds (inclusive). For more information, see [Manage long-running actions](/docs/postman-flows/reference/flows-actions-overview/#manage-long-running-actions). * **Description** - Describe the action's purpose and any important details. 1. Click **Deploy**. The action runs in the Postman cloud at the specified URL, and a summary of the action appears. The summary includes the action's status, URL, and version. ## Deploy a new snapshot of an action If you make changes to your action, you can deploy the new version and create a new [snapshot](/docs/postman-flows/build-flows/configure/snapshots/) of it. To deploy a new version of an existing action, do the following: 1. In your action, click **Deploy**. 1. (Optional) Enter a description of the changes. 1. Click **Deploy**. The new version of the action is deployed to the original URL and a new snapshot is created. ## Deploy a previous snapshot of an action To revert an action to a previous [snapshot](/docs/postman-flows/build-flows/configure/snapshots/), do the following: 1. In your action, click **Deploy**. 1. Click the ![Image 3: Versions icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-versions-stroke.svg#icon) **Snapshots** dropdown list. 1. Select the snapshot you want to deploy. 1. Click **Deploy**. The local version of your action doesn't automatically restore the snapshot when you deploy it. To learn about restoring snapshots and more, see [Version flows with snapshots](/docs/postman-flows/build-flows/configure/snapshots/). ## Schedule an action to run automatically You can trigger actions at regular intervals or at specific times. To trigger an action with a schedule, do the following: 1. In the **Request** block in your action, click **Change trigger** and select ![Image 4: Calendar icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-calendar-stroke.svg#icon) **Schedule**. The **Request** block changes to a **Schedule** block. 1. In the text box, enter when you want the action to run in plain language. For example, you could enter "Run once per minute for five minutes." The shortest time increment you can schedule is one minute. The longest is one year. 1. Click **Apply**. 1. [Deploy the action](#deploy-an-action). The **Deploy** window shows the action's current schedule and next scheduled run. When deployed, the action runs automatically on the specified schedule. 1. (Optional) To trigger the action with a request instead of a schedule, in the **Schedule** block click **Change trigger**, select ![Image 5: Open right icon](https://assets.postman.com/postman-docs/aether-icons/action-openRight-stroke.svg#icon) **Request**, and deploy the action again. ## Enforce bearer token authorization for actions You can configure actions to authorize requests with a [_bearer token_](/docs/sending-requests/authorization/authorization-types/#bearer-token). To require a bearer token for your action, do the following: 1. [Create](#create-an-action) and [deploy](#deploy-an-action) an action. 1. In the **Deploy** dialog, click **Turn on \u003e Turn on**. ![Image 6: Enable auth](https://assets.postman.com/postman-docs/v11/flows-enable-actions-auth-v11-52.jpg) 1. Click ![Image 7: Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy** to copy the **Auth** token. You can then share the token with authorized users so they can include it in requests to the action's URL. ![Image 8: Async action](https://assets.postman.com/postman-docs/v11/flows-actions-copy-auth-v11-52.jpg) 1. (Optional) Click ![Image 9: Refresh icon](https://assets.postman.com/postman-docs/aether-icons/action-refresh-stroke.svg#icon) **Regenerate token** to create a new token. --- # Add input blocks to your notebook You can add variables and reference them elsewhere in your notebook to create an interactive experience. For example, you can add an input block for your API consumer's email address and [use a request block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-request-blocks/) to send them a welcome message. ## Add an input block To add an input block, do the following: 1. Open your notebook or [create a new one](https://www.postman.com/notebook/new). 2. Place your cursor where you want to add the input block. Then, type a forward slash (\"/\"). Postman displays a block menu. 3. Choose an input block type: - ![Image 1: String icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-string-stroke.svg#icon) **Text** - Choose for strings, such as names or email addresses. - ![Image 2: Number icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-number-stroke.svg#icon) **Number** - Choose for numbers, such as integers or floats. - ![Image 3: Lock icon](https://assets.postman.com/postman-docs/aether-icons/action-lock-stroke.svg#icon) **Secret** - Choose for sensitive data, such as API keys or tokens. [!Important] Protect your sensitive data. If Postman detects any API keys, tokens, or similar, it replaces them with placeholders. To learn more, see [Postman Secret Scanner](/docs/administration/managing-your-team/secret-scanner/overview/). 4. Name your input block. 5. (Optional) Define a default value. ## Reference your input block You can reference your input block by name. For example, if you name your input block "email", you can reference it in text, another input block, or a [request block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-request-blocks/) with the syntax `{{email}}`. Or you can reference it in a [script runner block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-code-runner-blocks/) with the syntax `$email`. To reference your input block, do the following: 1. Open your notebook or [create a new one](https://www.postman.com/notebook/new). 2. Get your input block's name. 3. Reference your input block: - To reference your input block in text, another input block, or a request block, use the syntax `{{inputBlockName}}`. - To reference your input block in a script runner block, use the syntax `$inputBlockName`. [!TIP] From a specification, you can also copy the URL to the latest version of a component. Click ![Image 4: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. Then hover over a component and click ![Image 5: Link icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-link-stroke.svg#icon) **Copy link**. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## Enable Local Secret Protection Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values [!Important] The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 6: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 7: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 8: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 9: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 10: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 11: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 12: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 13: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 14: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 15: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 16: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 17: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 18: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 19: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 20: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 21: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 22: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. [!Important] This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 23: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner --- # Add request blocks to your notebook You can add API requests and reference their responses elsewhere in your notebook to create an interactive experience. For example, you can [add an input block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-input-blocks/) for your API consumer's email address and use a request block to send them a welcome message. ## Add a request block To add a request block, do the following: 1. Open your notebook or [create a new one](https://www.postman.com/notebook/new). 2. Place your cursor where you want to add the request block. Then, type a forward slash (\"/\"). Postman displays a block menu. 3. Choose ![Image 1: Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Request Block**. 4. Search for your public request or paste its URL or UUID. Then, select it. Postman displays the request, any variables you or your API consumers may need to define, a way for you or your API consumer to define the request body, and a button to send the request. 5. Name your request block. 6. If necessary, define the variables. These may include query and path parameter values, or other values defined in the request. 7. (Optional) Define an override. This overrides the request's body. 8. Click ![Image 2: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Send**. Postman sends the request and returns the response. If the request changes, you can refresh the request block. To refresh it, next to the endpoint, click ![Image 3: Refresh icon](https://assets.postman.com/postman-docs/aether-icons/action-refresh-stroke.svg#icon) **Refresh**. To start over, click ![Image 4: Clear icon](https://assets.postman.com/postman-docs/aether-icons/action-clear-stroke.svg#icon) **Clear**. ## Reference your request block You can reference your request block by name. For example, if you name your request block "getUser", you can reference its response in another request block with the syntax `{{getUser}}`. Or you can reference it in a [script runner block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-code-runner-blocks/) with the syntax `$getUser`. Furthermore, you can use dot notation to reference data within a response. For example, in another request block, you can reference the user's first email with the syntax `{{getUser.emails.0}}`. Or in a [script runner block](/docs/postman-api-network/showcase/publish/notebooks/draft/add-code-runner-blocks/), you can reference the same value with the syntax `$getUser.emails[0]`. To reference your request block, do the following: 1. Open your notebook or [create a new one](https://www.postman.com/notebook/new). 2. Get your request block's name. 3. Reference your request block: - To reference your request block in an input or another request block, use the syntax `{{requestBlockName}}` or `{{requestBlockName.path.to.data}}`. - To reference your request block in a script runner block, use the syntax `$requestBlockName` or `$requestBlockName.path.to.data`. ## Send requests in sequence If you can use the data from one response in the request of another, you can send those requests in sequence. For example, you can get a user's email from a response and use it to send a different request. To send requests in sequence, do the following: 1. Open your notebook or [create a new one](https://www.postman.com/notebook/new). 2. In the first request block, click ![Image 5: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Send**. 3. In the second request block, reference the first request block with the syntax `{{requestBlockName.path.to.data}}`. Then, click ![Image 6: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Send**. Postman uses the first request's response to send the second request. You can add more requests to the sequence. --- **Note:** Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: - HTTP collections - Environments variable values - Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 7: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 8: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: - To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. - To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). --- **Note:** You can't delete component files. ### View live documentation Postman displays a live preview of your API's documentation as you edit your component file. To show the documentation preview, click ![Image 9: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Live preview** in the right sidebar. Click ![Image 10: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) **Close** to hide the documentation preview. ### Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. **Note:** Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 11: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. Click **Version & Publish** in the upper right corner. ![Image 12: Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 1. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 2. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. **Note:** You can't delete published versions of component files. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 13: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 14: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 15: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. **Note:** From a specification, you can also copy the URL to the latest version of a component. Click ![Image 16: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. Then hover over a component and click ![Image 17: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy link**. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- **Note:** You can't delete component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). --- **Note:** You can't delete published versions of component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the documentation preview, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your --- # Add API requests to Postman Collections After you [create a Postman Collection](/docs/collections/use-collections/create-collections/), you can use it to save and organize API requests. Use any of the methods below to add requests to a collection. You can add HTTP requests to a collection, or you can add requests that use other protocols to a [multi-protocol collection](#about-multi-protocol-collections). ## Add a request to an empty collection 1. Select the collection in the sidebar. 2. Click ![Image 1: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) or **Add a request**. ![Image 2: Add a request to an empty collection](https://assets.postman.com/postman-docs/v11/add-new-request-v11.51.png) 3. Enter a name for the request. 4. Select the collection you want to save the request to. > To create a new collection to save the request to, click **New Collection**. ![Image 3: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 5. Click **Save**. ![Image 4: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 5: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 6: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. ![Image 7: Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 4. Click ![Image 8: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 5. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 6. Click **Create**. ![Image 9: Create a component file](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 10: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 11: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 12: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. > From a specification, you can also copy the URL to the latest version of a component. Click ![Image 13: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. Then hover over a component and click ![Image 14: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy link**. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 15: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 16: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component in the left sidebar that you'd like to version and publish. 5. Click **Version & Publish** in the upper right corner. ![Image 17: Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 6. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 7. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. > You can't delete published versions of component files. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 18: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ## Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 19: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ## Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ## Manage workspace scan policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 20: The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 21: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Image 22: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 23: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 24: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 25: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 26: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 27: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 28: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Image 29: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 30: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 31: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 32: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 33: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 34: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 35: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Image 36: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 37: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 38: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 39: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 40: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 41: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 42: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Image 43: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 44: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 45: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 46: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 47: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 48: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 49: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/sl --- # The AI Request block ![AI Request block](https://assets.postman.com/postman-docs/v11/flows-ai-request-block-v11-50-1.jpg) The **AI Request** block runs an [AI request](/docs/postman-ai/ai-requests/create/) from your collection and sends the result from one of its output ports. The **AI Request** block is similar to the [**HTTP Request**](/docs/postman-flows/reference/blocks/http-request/) block, but instead of sending an HTTP request to an API, it sends a prompt to an AI model. If the prompt in your AI request includes variables in curly braces (`{}`), the variables appear at the bottom of the block. To learn more about Postman's AI capabilities, see [Evaluate AI models and MCP servers with Postman](/docs/postman-ai/overview/). ## Input **Send** - If you connect another block to this input port, that block triggers the **AI Request** block to run. This connection is optional. If no blocks are connected to the **Send** input, the **AI Request** block will run when the flow runs. ## Outputs **Success** - Sends the response of a successful AI request. A successful request has a 2xx status code. **Fail** - Sends the response of an unsuccessful AI request. An unsuccessful request has a status code other than 2xx. ## Setup **Select a request** - Click this dropdown list to view all the collections in your workspace that contain AI requests. Select a collection, then select a request. To create a new request, select a collection then click ![Image 2: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create a new request**. To edit the request in the right sidebar, hover over the request and click ![Image 3: Edit icon](https://assets.postman.com/postman-docs/aether-icons/action-edit-stroke.svg#icon) **Edit request**. **Variables** - If the selected request has [variables](/docs/sending-requests/variables/variables-intro/) in its prompt, they'll be listed here. You can assign a value to a variable by connecting another block's output port to the variable's input port, or by [inserting a data block](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) with ![Image 4: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks**. If your request uses environment variables, you can select the environment from the **Add environment** dropdown list. ### Specify how to parse the response The **AI Request** block can parse its response as JSON, XML, HTML, or text. To choose how to parse the response, do the following: 1. Click the **AI Request** block, then click ![Image 5: Additional Settings](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Additional Settings**. 2. Click ![Image 6: Parse Response](https://assets.postman.com/postman-docs/aether-icons/descriptive-code-stroke.svg#icon) **Parse Response**. 3. Select a format from the dropdown list. You can also select **Auto** to let the **AI Request** block decide how to parse the response. The default setting is **Auto**. ## Example To see the **AI Request** block in an example flow, check out [Flow Snippets: AI Request](https://www.postman.com/postman/flows-snippets/flow/6849e3778fff02003235757d). ## Related blocks The **Select** and **Evaluate** blocks are often connected to the **AI Request** block's **Success** output port. The **Select** block is useful for extracting specific information from a response. The **Evaluate** block is useful for transforming response data and creating conditions to route data in your flow based on a response. You can also insert or connect data blocks to provide values for any variables in the AI request's prompt. * [**AI Agent**](/docs/postman-flows/reference/blocks/ai-agent/) * [**Bool**](/docs/postman-flows/reference/blocks/bool/) * [**Create with AI**](/docs/postman-flows/reference/blocks/create-with-ai/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Get Configuration**](/docs/postman-flows/reference/blocks/get-configuration/) * [**Get Variable**](/docs/postman-flows/reference/blocks/get-variable/) * [**Number**](/docs/postman-flows/reference/blocks/number/) * [**Select**](/docs/postman-flows/reference/blocks/select/) * [**String**](/docs/postman-flows/reference/blocks/string/) --- # api-documentation-overview Document your APIs in Postman ============================= [Documentation](https://www.postman.com/api-platform/api-documentation/) is an important part of your API. You can add documentation to any Postman Collection and its API requests. You can also use Postman to create API documentation and share it with your API's consumers, so they know what endpoints are available and how to interact with them. Postman automatically generates documentation for your collections and APIs. To give your users more help and context, use Postman's built-in editing tools to add descriptions, images, videos, and more to your documentation. ## Document collections and APIs Postman automatically creates documentation for your collections, including request details, authorization type, and sample code. You can [add descriptions to the items in your collection](/docs/publishing-your-api/document-a-collection/) to provide more information for users. With types in collections, you can [add details about your API with the Postman Collection format](/docs/publishing-your-api/documenting-your-api/). Postman also generates documentation based on your API definition (for OpenAPI 2.0 and 3.0 APIs). To create more detailed API documentation, [add one or more collections to the Postman API Builder](/docs/publishing-your-api/documenting-your-api/), and then add descriptions to the collections. You can add an existing collection or generate a collection based on your API definition. ## Write your documentation Add descriptions to your collections to [enhance your documentation and provide more detail](/docs/publishing-your-api/authoring-your-documentation/). You can use the Postman editor to view how your content will look as you write it, or use standard Markdown syntax to write content. With either editor, you can format text, add links, and insert images and videos. > **Postbot can write documentation for you.** Use Postman's AI assistant, Postbot, to automatically add descriptions to your API requests, including parameters and response examples. Learn more about [writing documentation with Postbot](/docs/publishing-your-api/authoring-your-documentation/#writing-documentation-with-postbot). ## Publish and view documentation To learn more about how to use a collection or an API, you can [view documentation in Postman](/docs/publishing-your-api/viewing-documentation/). Collection documentation provides details for each request, along with sample code. To view API documentation, open an API in Postman, or search for APIs on your [Private API Network](https://go.postman.co/network/private) or [Postman API Network](https://www.postman.com/explore/apis/). [Publishing a collection](/docs/publishing-your-api/publishing-your-docs/) makes your documentation publicly available on getpostman.com or your own [custom domain](/docs/publishing-your-api/custom-doc-domains/). As you update your collection, the published documentation automatically syncs with your latest changes. > You can't publish a collection that's linked to an API. Instead, you can [publish a version of an API in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/) to make your API and its documentation available to consumers. ## Create a Run in Postman button You can [create a **Run in Postman** button](/docs/publishing-your-api/run-in-postman/introduction-run-button/) to share a collection and its documentation with users. When users select the button, they have the option to fork the collection to their workspace, view the collection in a public workspace, or import the collection into Postman. ## Integrate Postman with Azure API Gateway Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ### Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ### Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 5. Click **Next**. 6. Select the **Type** dropdown list. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage secret policies with Local Secret Protection With the Postman Component Library, you can manage reusable components for your team's OpenAPI specifications in [Spec Hub](/docs/design-apis/specifications/overview/). Maintain and standardize commonly used components in a central location, without having to redefine them in each specification. Reusable components can include schemas, responses, parameters, and more. Publish a new version when you're ready to share changes with your team, maintaining support for earlier versions. Anyone on your team can reuse published components and choose the version they'd like to reference in their specifications. > **Notes:** > > * Only a Team Member can create workspaces in the team. > * Sharing an element with a new user triggers the process of adding that user to the Team's user list. > * Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). > > Learn more about: > > * [Creating organization teams and workspaces](/docs/administration/organization/create/) > * [Organization roles](/docs/administration/organization/roles/) > * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) connection. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage behavior** to **Move to vault**. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. Users can't delete component files. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. > By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. * If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 4. Add the team to the organization by selecting the appropriate option in the drop-down list. ## Move work into Teams You can move work into Teams manually, but if a significant number of workspaces need to be moved, you can move it in bulk. Any Workspace Admin can move their workspaces into any team where they are a member, so the responsibility of migrating work can be delegated to all the members of the Team that was created. If you can identify team workspaces ahead of time, Postman provides public API endpoints and collections that you can use to move large numbers of workspaces in bulk. After you move workspaces, do the following: 1. Determine the Admins for each workspace from the list of workspace users. 2. Review the roles on the workspaces you moved, and align them with these best practices: * If the workspaces were previously shared with the Organization, ensure they remain shared with the Organization. * If the APIs are intended to be consumed by others, ensure those people still have access to view them. * If you require limited sharing, consider sharing APIs with specific Teams that are interested in them, leveraging the Team memberships, rather than inviting individuals. * Ensure that workspaces are viewable by the Team it was moved into, unless there is a specific reason it shouldn’t be shared with other Team members. * Make the workspace editable by the Team. * Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. * The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. * Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) connection. 5. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. > > Learn more about: > > * [Organization roles](/docs/administration/organization/roles/) > * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) connection. 5. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. > > Learn more about: > > * [Organization roles](/docs/administration/organization/roles/) > * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) connection. 5. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. > > Learn more about: > > * [Organization roles](/docs/administration/organization/roles/) > * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) connection. 5. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets --- # View security warnings in API requests Postman applies security rules configured for your API requests when you send requests to any API using either the Postman web app or the Postman desktop app. A security warning doesn't mean your API is broken. Instead, it indicates there are potential security risks your API might be vulnerable to. Postman highlights these security warnings and helps you understand their implications and possible ways to fix the warnings. > [Enterprise teams](https://www.postman.com/pricing/) can also customize the rules that Postman applies to API requests. For more information, see [Configure API Governance rules](/docs/api-governance/configurable-rules/configuring-api-governance-rules/). When you [send an API request](/docs/sending-requests/create-requests/request-basics/#send-a-request), Postman scans it for potential security risks. If any are found, Postman adds the number of warnings to the **Security** tab in the response. ![Security tab showing one warning](https://assets.postman.com/postman-docs/v10/api-response-security-tab-v10.jpg) To learn about API security warnings and how to hide warnings that aren't relevant to your team, see [Security warnings](/docs/sending-requests/response-data/responses/#security-warnings). For the list of all the security warnings that Postman might show for API requests, see [Security warnings in API requests](/docs/api-governance/api-testing/security-warnings/). --- ## Postman Vault integrations Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ### Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ### Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 5. Click **Next**. 6. Select the **Type** dropdown list. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ### Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ### Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- ## Organization Settings _Postman Organizations_ streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. ### Create Organization teams To create an Organization Team, do the following: 1. Access ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. ### Manage workspace scan policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** – [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** – Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** – [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** – Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** – Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. * This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. * The policy you select is automatically applied to the selected workspaces. --- ## Organization roles ### Team roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | * Has edit access to all elements within the Team and the capability to edit the Team's Settings. * Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | * Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. * Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. * Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | * Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. * Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | * **Notes:** * Only a Team Member can create workspaces in the team. * Sharing an element with a new user triggers the process of adding that user to the Team's user list. * Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. The Team Manager is the delegated owner of the Team’s content and membership and controls how the Team’s content is shared. The Team Manager is the leader of people responsible for the Team’s content. 1. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 1. Populate the team with the members who are responsible for the team’s contents. * If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. ### Move work into Teams You can move work into Teams manually, but if a significant number of workspaces need to be moved, you can move it in bulk. Any Workspace Admin can move their workspaces into any team where they are a member, so the responsibility of migrating work can be delegated to all the members of the Team that was created. If you can identify team workspaces ahead of time, Postman provides public API endpoints and collections that you can use to move large numbers of workspaces in bulk. After you move workspaces, do the following: 1. Determine the Admins for each workspace from the list of workspace users. 1. Review the roles on the workspaces you moved, and align them with these best practices: * If the workspaces were previously shared with the Organization, ensure they remain shared with the Organization. * If the APIs are intended to be consumed by others, ensure those people still have access to view them. * If you require limited sharing, consider sharing APIs with specific Teams that are interested in them, leveraging the Team memberships, rather than inviting individuals. * Ensure that workspaces are viewable by the Team it was moved into, unless there is a specific reason it shouldn’t be shared with other Team members. * Make the workspace editable by the Team. * Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. * The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. * Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then select [Teams](https://go.postman.co/teams) and open a specification. 2. Click ![Image 12: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 13: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click ![Image 14: Add Organization Team members](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add Organization Team members**. 1. Enter a name for the team and select the OpenAPI specification format it’ll be used in. You can’t change the name or OpenAPI specification version of a team file later. 1. Click **Create**. ![Image 15: Create Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you’d like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 16: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 17: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click ![Image 18: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 4. Enter a name for the component file and select the OpenAPI specification format it’ll be used in. You can’t change the name or OpenAPI specification version of a component file later. 5. Click **Create**. ![Image 19: Create a component file](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Under **Workspace description**, add a description. 1. Under **About**, add a summary. 1. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- ## Organization roles ### Team roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | * Has edit access to all elements within the Team and the capability to edit the Team's Settings. * Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | * Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. * Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. * Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | * Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. * Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | * **Notes:** * Only a Team Member can create workspaces in the team. * Sharing an element with a new user triggers the process of adding that user to the Team's user list. * Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). --- # Automate repetitive tasks using Postman Flows You can use Postman Flows to complete repetitive tasks. Businesses often need to delete emails from multiple systems. Logging in, searching, and deleting emails from multiple locations can be time-consuming. This tutorial shows you how to create a flow that deletes an email from three locations each time you run the flow. For this tutorial, the locations are [Stripe.com](https://stripe.com/), [Brevo.com](https://www.brevo.com/), and a Postman mock server that acts as a hypothetical internal system. You can find the [complete flow](https://www.postman.com/postman/devops-flows/flow/6417a7608c4c54003a4ad899) in the [DevOps Flows](https://www.postman.com/postman/devops-flows/overview) workspace. ## Prerequisites * A Stripe account with a customer with the `test@email.com` email address. * A Brevo account with a contact with the `test@email.com` email address. * A Stripe secret key. * A Brevo API key. ## Fork the collections and environment [Fork](https://www.postman.com/docs/collaborating-in-postman/using-workspaces/public-workspaces/public-workspaces/ "Fork") these collections from the [**DevOps Flows**](https://www.postman.com/postman/devops-flows/overview) workspace into your workspace: * [**Stripe API**](https://www.postman.com/postman/devops-flows/collection/xuxoonj/stripe-api?action=share&creator=21580188) * [**Brevo**](https://www.postman.com/postman/devops-flows/collection/lwjd0gh/brevo?action=share&creator=21580188) * [**customer-list**](https://www.postman.com/postman/devops-flows/collection/inwryya/customer-list?action=share&creator=21580188) Fork this environment into your workspace: * [**gdpr-delete-email**](https://www.postman.com/postman/devops-flows/environment/21580188-d7306a24-e742-42e2-8bfd-d122bd1e52ca) In the **gdpr-delete-email** environment, replace `your-brevo-api-key` with your Brevo API key. Replace `your-stripe-secret-key` with your Stripe secret key. ![Add API keys](https://assets.postman.com/postman-docs/v11/flows-tut-rep-update-env-v11.jpg) ## Create the flow 1. Part one: Delete the contact from Stripe * Create a new flow. Add a **String** block and enter `test@email.com`. * Connect a **Create Variable** block and enter `Customer Email`. ![Create a variable](https://assets.postman.com/postman-docs/v10/flows-tut-rep-create-variable-v10.gif) * Connect three **HTTP Request** blocks to the **Start** block, arranged vertically. ![Create three HTTP Request blocks](https://assets.postman.com/postman-docs/v10/flows-tut-rep-3send-requests-v10.jpg) * In the top **HTTP Request** block, select **Stripe API > Customers > Search customers**. * Select the **gdpr-delete-email** environment. * For the `email` variable, add a **Get Variable** block and click **Customer Email**. ![Get the variable](https://assets.postman.com/postman-docs/v10/flows-tut-rep-get-variable-v10.gif) * Create an **If** block next to the **HTTP Request** block. Add a **Select** block to the **If** block and change `value1` to `contacts`. ![Add an If block](https://assets.postman.com/postman-docs/v10/flows-tut-rep-if-block-v10-2.gif) * Connect the **HTTP Request** block's **Success** output to the **If** block's `contacts` and **Data** inputs. Next to `contacts`, select `body.data`. In the FQL window, enter `$count(contacts) > 0`. * Connect the **If** block's **FALSE** output to a **Display** block. * Rename the **Display** block `Contact not found` and select **Boolean** from the dropdown list. * Connect the **If** block's **TRUE** output to an **HTTP Request** block. Select **Stripe API > Customers > Delete a customer**. * Also connect the **If** block's **TRUE** output to the **HTTP Request** block's **customer_id** input and select `body.data.0.id`. * Connect the **HTTP Request** block's **Success** output to a **Display** block. * Rename the **Display** block `Contact deleted` and select **Boolean** from the dropdown list. ![Stripe contact deleted](https://assets.postman.com/postman-docs/v10/flows-tut-rep-stripe-deleted-v10.jpg) 2. Part two: Delete the contact from Brevo * In the middle **HTTP Request** block, select **Brevo > Contact management > Contacts > Get a contact's details**. * Select the **gdpr-delete-email** environment * For the `email` variable, add a **Get Variable** block and click **Customer Email**. * Connect this block's **Success** output to another **HTTP Request** block and select **Brevo > Contact management > Contacts > Delete a contact**. Also connect the middle **HTTP Request** block's **Success** output to the new **HTTP Request** block's **contact_id** input and select `body.id` ![Add Brevo requests](https://assets.postman.com/postman-docs/v10/flows-tut-rep-brevo-requests-v10.jpg) * Connect the **Delete a contact** block's **Success** output to a **Display** block. Rename the **Display** block `Contact deleted` and select **Boolean** from the dropdown list. * Connect a **Display** block to the **Get a contact's details** **HTTP Request** block's **Failure** output. Rename the **Display** block `Contact not found` and select **Boolean** from the dropdown list. ![Brevo contact deleted](https://assets.postman.com/postman-docs/v10/flows-tut-rep-brevo-deleted-v10.jpg) 3. Part three: Delete the contact from an internal system * In the bottom **HTTP Request** block, select **customer-list > customer/email**. * For the email variable, add a **Get Variable** block and click **Customer Email**. * Connect the **Success** output to an **HTTP Request** block and select **customer-list > customer/id**. * Also connect the **customer/email** **HTTP Request** block's **Success** output to the **id** input and select `body.id`. * Connect the **customer/id** **HTTP Request** block's **Success** output to a **Display** block. Rename the **Display** block `Contact deleted` and select **Boolean** from the dropdown list. * Connect the **customer/id** **HTTP Request** block's **Failure** output to a **Display** block. Rename the **Display** block `Contact not found` and select **Boolean** from the dropdown list. ![Internal contact deleted](https://assets.postman.com/postman-docs/v10/flows-tut-rep-internal-deleted-v10.jpg) ## Run the flow Select **Run**. The flow finds and deletes the contact with the `test@email.com` email address on Brevo, Stripe, and the internal system. When the contact is deleted, the `Contact deleted` **Display** block shows **True**. If there is no contact with that email address, the `Contact not found` **Display** block shows **False**. --- # Manage billing Postman provides a self-serve billing process. Refer to the following sections for guidance on managing your account, plan, and payment. For help with any account or billing issues, go to the Postman [support center](https://www.postman.com/support/) and select **Submit a request**. You can also browse the [Postman billing and payment FAQs](https://support.postman.com/hc/en-us/categories/115000609205-Billing-and-Payment) there. ## Billing dashboard The Postman [billing dashboard](http://go.postman.co/billing) enables you to manage your team's billing. ### Viewing billing overview The billing overview is your billing dashboard's default view. You can view the details of your Postman plan, including your subscription cycle and a calculation of your expected cost upon renewal. ![Billing overview](https://assets.postman.com/postman-docs/billing-plan-and-payments-dash-v9.14.jpg) ### Managing resources Open the [**Resource usage** dashboard](http://go.postman.co/billing/add-ons/overview) to see your team's usage of resources such as mock servers and monitors, APIs created, collection runner runs, image and file storage, and other items. To open the **Resource usage** dashboard, do one of the following: * **Free users** - In the Postman header, select the dropdown list next to **Upgrade** then select **Resource Usage**. * **Paid users** - In the Postman header, select **Team > Resource Usage**. To learn more about the resources included with your Postman plan and what happens when you reach your usage limits, go to [About resource usage](/docs/billing/resource-usage/). ![Add-ons usage and purchase](https://assets.postman.com/postman-docs/resource-usage-9.13.jpg) Select **View detailed usage** next to **Monitoring Usage** to view your team's active monitors and their impact on your team's usage during the current billing period. You can opt to activate or deactivate overages for mock server, Postman Monitor, and Postman Flows usage by activating **Pay-as-you-go** for each item. If activated, you will be charged on a pay-as-you-go basis. Users with the [Billing role](/docs/administration/roles-and-permissions/) can also [purchase add-ons](#purchasing-add-on-resources) in the **Resource usage** dashboard. If your API development pipeline is dependent on Postman Monitor, deactivating overages may cause unintended consequences for your bill. To avoid fluctuating pay-as-you-go charges, consider adding [pre-paid Postman Monitor blocks](#purchasing-add-on-resources) to your team plan. ### Viewing account history In your [billing dashboard](http://go.postman.co/billing), select **Plan and payments**, then **History**. ![Account history view](https://assets.postman.com/postman-docs/billing-history-v9.1.jpg) Items such as updates to your Postman subscription, payment method changes, payments, and charges are all listed in chronological order. ### Viewing past invoices In your [billing dashboard](http://go.postman.co/billing), select **Plan and payments**, then **Invoices**. You can get a copy of your past invoices by selecting the download icon ![Download icon](https://assets.postman.com/postman-docs/icon-download-v9.jpg#icon) for the specific invoice you want to retrieve. ![Invoices view](https://assets.postman.com/postman-docs/billing-invoices-v9.1.jpg) To add or edit the information on an invoice, see [adding custom information to invoices](#adding-custom-information-to-invoices). ## Payments Postman offers various payment options dependent on your plan type. ### Managing payment methods In your [billing dashboard](http://go.postman.co/billing), select **Plan and payments**, then **Payment methods**. To add a new payment method, select **Add Payment Method**. Select the payment method you would like to use. Depending on your location, you can pay using credit card, [direct debit](#setting-up-direct-debit-payments), or other payment methods. To remove a payment method, hover over the payment method in question and select **Delete Payment Method**. To set a payment method as your primary, hover over it and select **Set as Primary**. ![Payment methods view](https://assets.postman.com/postman-docs/payment-methods-page.jpg) #### Setting up direct debit payments The option to pay with direct debit is only available for customers in the United States. Postman accepts direct debit payments, in which payment funds are taken directly from a linked bank account using ACH. To use direct debit as your payment method, do the following: 1. Select **Add payment method**, then select **ACH Direct Debit**. 1. Enter your email, your name, and either enter or search for your bank name. This process will verify your bank account immediately. If you want to use a manual verification process instead, see [Verifying your bank account manually](#verifying-your-bank-account-manually). 1. To accept the Terms and Privacy Policy, select **Agree**. You can select **Learn more** to view the whole policy. 1. Stripe, the payment service Postman uses, will open a new window where you can sign in to your bank account. Select **Continue**. 1. Select the account you want to use, then select **Link account**. After Stripe verifies the account, select **Done**. Stripe will return you to the Postman billing dashboard. 1. Select **Add account**. After account verification, Postman will send you a confirmation email. It can take up to four days to withdraw funds from your bank account using direct debit. * **Direct debit payment failures** - In the event of a direct debit payment failure, Postman will email you with information about how to fix the issue. The billing dashboard will also contain this information. * **Direct debit disputes** - If you believe there has been an error with your direct debit payment, contact [Postman support](https://www.postman.com/support/) to resolve the issue. If you dispute the payment through your bank, Stripe removes your bank account's verified status and you won't be able to use the account for Postman payments until you [verify it](#setting-up-direct-debit-payments) again. #### Verifying your bank account manually You can choose to verify your bank account manually instead of using the automatic process documented in [Setting up direct debit payments](#setting-up-direct-debit-payments). This manual process may take up to two days. To verify your bank account manually, do the following: 1. Select **Add payment method**, then select **ACH Direct Debit**. 1. Enter your email and your name, then select **Enter bank details manually instead**. 1. Enter your routing number and bank account number. Confirm your account number, then select **Continue**. In one to two business days, Stripe will make a small test deposit into your bank account that you will use to verify your bank account and will email you with further instructions. To verify your bank account using the test deposit, do the following: 1. After the test deposit arrives in your bank account, go back to the Postman billing dashboard. Select **Plans and payments > Payment methods**. 1. Hover over the bank account and select **Verify**. 1. Under **Enter code**, paste the six digit transaction code from the test deposit. Select **Verify**. 1. Select **Confirm** to accept the Terms and Privacy Policy. If you don't verify your account within ten days, Postman will delete your bank account information. If you want to add a direct debit payment method later, you will need to re-enter your bank account information. After your bank account is verified, Postman will send you a confirmation email. It can take up to four days to withdraw funds from your bank account using direct debit. ### Using the Pay Now option In some circumstances, including an overdue or [failed payment](#failed-payments), you may receive an invoice for your Postman payment. From the invoice, select **Pay Now** to pay immediately using your primary [payment method](#managing-payment-methods), or Apple Pay or Google Pay if supported. ### Paying by invoice Invoicing is available for Postman [Enterprise teams](https://www.postman.com/pricing/) only. If you are a new Enterprise customer, contact the [Postman Sales team](https://www.postman.com/pricing/get-started-postman-plans/) to get started. You will receive a response within three business days. If you are an existing Enterprise customer, submit a request to the [Postman Support team](https://support.postman.com/hc/en-us) to be invoiced instead of automatically charged. You can pay invoices online, with ACH, or with wire transfer. Postman sends invoices to the billing email address listed in your [billing details](http://go.postman.co/settings/team/billing-details). The invoice includes offline payment instructions. View your pending payments in your [billing dashboard](http://go.postman.co/billing). ### Adding custom information to invoices In your [billing dashboard](http://go.postman.co/billing), select **Plan and payments**, then **Invoices**. Select **Edit billing information**. Add or update your company name, billing email, address, and your VAT ID if applicable, then select **Save**. All future [invoices](https://go.postman.co/billing/invoices) will have the updated copy. To change an existing invoice, submit a request to [Postman support](https://support.postman.com/hc/en-us). ![Edit billing details](https://assets.postman.com/postman-docs/update-billing-details-v9.jpg) ### Failed payments If you have a payment method on file, Postman will automatically try three times to charge it. If this is unsuccessful, team members with the [Billing team role](/docs/administration/roles-and-permissions/#team-roles) receive an email notification. Use the link in the email to access and pay for your [invoice](#using-the-pay-now-option). If payment is unsuccessful, Postman offers a grace period of 21 days to avoid service disruption. For invoice-based teams, this means 21 days following the due date listed on the invoice. In the event of non-payment and service deactivation, Postman sends an email notification to the billing email address listed in your [billing details](http://go.postman.co/settings/team/billing-details). ## Team and plan changes You can change your team's plan and billing cycle in your [billing dashboard](https://go.postman.co/billing/overview). ### Changing your plan To change your plan, billing frequency, team size, and add-ons, open your [billing dashboard](https://go.postman.co/billing/overview) and select **Edit plan**. 1. You can adjust your billing frequency and plan type. 1. Select **Next** to adjust your team size and add-on seats such as Postman Flows, Postbot, and Enterprise add-ons. You can opt to apply changes right away or on renewal. 1. Select **Next** to adjust your team's add-on resources, including Postman Monitor blocks, mock server blocks, and custom domains. 1. Select **Next** then **Confirm Changes**. Certain changes, such as switching from an annual plan to a monthly plan or plan downgrade, can only be applied to your team upon renewal. If you make adjustments to your plan that can't be applied right away, and have **Immediately** selected, you will be prompted to switch your selection to **On renewal**. The cost of your new plan and any new seats, if applicable, are prorated based on the time left in your team's billing cycle. ### Purchasing add-on resources The base number of Postman Monitor requests, mock server calls, Postman Flows credits, and custom domains included with your plan depends on your [plan type](https://www.postman.com/pricing/). You can activate or deactivate overages for Postman Monitor, mock server calls, and Postman Flows by [managing your team's resources](#managing-resources). If activated, you will be charged on a pay-as-you-go basis. Pay-as-you-go for Postman Flows isn't available with the Enterprise plan. If you're an Enterprise customer, please contact the Postman sales team when approaching your Flows credit limit. To purchase more blocks of Postman Monitor requests, mock server calls, and custom domains, navigate to your [billing dashboard](http://go.postman.co/billing) and select **Resource usage**, then **Purchase Add-ons**. Update the number of Flows seats, Postman Monitor blocks, mock server blocks, and custom domains you would like to have included with your team plan. Select **Next** to confirm your changes. ### Purchasing add-on products Several add-ons can be purchased to add features to your teams: * All teams can purchase Postbot as an add-on. To learn more about Postman's AI assistant, see [About Postbot](/docs/getting-started/basics/about-postbot/). * All teams and free users can purchase the [Collection Runner add-on](/docs/administration/managing-your-team/manage-team-product-access/#collection-runner-add-on). * Professional and Enterprise teams can purchase the [Partner Editor add-on](/docs/administration/managing-your-team/manage-team-product-access/#partner-editor-add-on). * Enterprise teams can purchase the [API Builder add-on](/docs/administration/managing-your-team/manage-team-product-access/#api-builder-add-on) and [Advanced Security Admin add-on](/docs/administration/managing-your-team/manage-team-product-access/#advanced-security-admin-add-on). (To purchase the Advanced Security Admin add-on, contact the [Postman sales team](https://www.postman.com/company/contact-sales/).) To purchase add-on licenses: 1. Navigate to your [billing dashboard](https://go.postman.co/billing/overview) and select **Edit plan**. 2. Select **Modify Plan** under the plan type for your team. You can also select **Add to Plan** next to the add-on you want to purchase more licenses for. Update the number of licenses in the **add-ons** section, then select **Next**. Select **Confirm Changes** to purchase more licenses. You can manage which team members consume add-on seats from the [product access dashboard](https://go.postman.co/settings/team/products-access). Learn how to [manage your team's access to add-ons](/docs/administration/managing-your-team/manage-team-product-access/#manage-access-to-add-ons). If you are on a Free plan, you can purchase Postbot seats by selecting **Upgrade** in the Postman header and navigating to the bundle section to add Postbot. Update the number of Postbot seats and select from Annual or Monthly payment options, then select **Next**. Enter your billing information and payment method, then select **Confirm**. To learn more about the added capabilities of each add-on, see [add-ons](https://www.postman.com/pricing/#add-ons). Auto-Flex enables your team to add more Team members without having to pay upfront. Newly added members to the Team and the add-ons will be billed in the next Auto-Flex cycle. ### Using Auto-Flex Auto-Flex is a flexible billing feature available to Postman teams. Auto-Flex applies to both plan seats and any add-on seats such as Postman Flows, Postbot, Partner Editor, and other add-ons. With Auto-Flex activated, your team can [invite](/docs/administration/managing-your-team/team-members/invite-members/) users or provision add-on capabilities to your team members without having to pay in advance for more seats, then opt to retain or remove them before being [billed](#billing-for-auto-flex). All [Postman Basic, Professional, and Enterprise plans](https://www.postman.com/pricing/) have Auto-Flex activated automatically. #### Billing for Auto-Flex Your Auto-Flex billing cycle is dependent on your team's plan: * Monthly plans are charged for newly added users on a monthly basis. * Annual plans are charged for newly added users on a quarterly basis. At any time during your Auto-Flex billing cycle, your team can [invite](/docs/administration/managing-your-team/team-members/invite-members/) users regardless of available seats. Before your Auto-Flex billing cycle renews, all Billing and Admin team members receive a notification about any new users you added during that time period. * Shortly before the applicable billing date, users with Billing or Admin roles will receive a notification that reflects the number of added users during that monthly or quarterly cycle. * You can use this reminder to make any necessary changes to your team before the end of your current Auto-Flex cycle, when you will be billed for any newly added users. * If you have already been billed for the users you added and retained in an earlier Auto-Flex cycle, you can't remove those seats until your plan renews. * You won't be billed if the number of users remains unchanged during your Auto-Flex cycle, or if you remove any added users prior to Auto-Flex billing. * If your team incurs any overages and you have an Auto-Flex bill for that cycle, your invoice will combine your overage charges with your Auto-Flex charges. In your [billing dashboard](http://go.postman.co/billing), you can view: * Your current number of additional team members and additional add-on seats * How much you will be billed at the end of your cycle (unless you add or remove users in the interim) * Additional information about your Auto-Flex and regular billing cycles For customers on Postman plans who are paying by invoice, your account manager will share an invoice once per Auto-Flex cycle (quarterly) to settle any outstanding balances. [Contact Postman support](https://www.postman.com/support/) with any questions about Auto-Flex. ## Canceling your plan To cancel your Postman plan, select **Cancel plan** at the bottom of your [billing dashboard](http://go.postman.co/billing). If you have canceled your Postman plan and want to reverse this action, select **Undo cancellation** next to the cancellation notice in your [billing dashboard](http://go.postman.co/billing). If you are on a Free plan with Postbot subscription and want to cancel your Postbot subscription, select **Remove add-on** at the bottom of [billing dashboard](http://go.postman.co/billing). ## Next steps After learning how to navigate the billing dashboard, you can learn more about the Billing role and managing your team. * To learn more about the Billing team role, visit [Roles and permissions](/docs/administration/roles-and-permissions/). * For information on team management, visit the [Team management overview](/docs/administration/managing-your-team/overview/). --- # Build a "Hello, world" flow module Postman Flows is a visual, low-code editor you can use to build almost any workflow you can imagine. With Postman Flows you can create *flow modules* that run locally, and [*actions*](/docs/postman-flows/build-flows/structure/actions/) that can be deployed in the Postman cloud. In this tutorial, you'll create a two-block flow module that displays the text **Hello, world**. You'll learn how blocks and connections work and prepare yourself to build larger and more complex flows. ## Create a new flow module With flows, you can create reusable flow components that can be added to multiple other flows. Then you can share your flows with teammates so they don't need to rebuild the same components. You create flows in a workspace. Use workspaces to organize your API projects and collaborate with your team. To create a new flow module, do the following: 1. Choose an existing workspace or [create a new one](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). 1. In the upper left corner, click **New** \> ![Image 1: Flow icon](https://assets.postman.com/postman-docs/aether-icons/entity-flow-stroke.svg#icon) **Flow**. 1. In the sidebar, hover over the new flow module, click ![Image 2: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**, then select **Rename**. 1. Rename the flow module to **Hello, world**. 1. Press the **Return** or **Enter** key. ## Add a String block Use the **String** block to define text, which you can send to another block. To add a **String** block, do the following: 1. On the canvas toolbar, click ![Image 3: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Block**. 1. Select ![Image 4: String icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-string-stroke.svg#icon) **String**. You can also search for the block by entering "string" in the search box. 1. To the right of the **Start** block, click the canvas to place the **String** block in that location. 1. In the **String** block, enter the text **Hello, world**. In the next procedure, you'll connect this block to a **Display** block to display your text. ## Connect a Display block When you connect two blocks, you connect one block's input to another block's output. Inputs are on the block's left side and outputs are on its right side. The **Display** block displays incoming data, such as the **String** block's string value. To connect a **Display** block, do the following: 1. Hover over the **String** block's output port. The pointer changes to a crosshair. 1. Drag the output port to the right of the **String** block to place the **Display** block in that location. 1. Select ![Image 5: Output icon](https://assets.postman.com/postman-docs/aether-icons/action-output-stroke.svg#icon) **Display**. You can also search for the block by entering "output" in the search box. ## Run the flow module On the canvas toolbar, click ![Image 6: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. ![Image 7: "Hello, world" flow](https://assets.postman.com/postman-docs/v11/postman-flows-build-your-first-flow-v11-40.jpg) Congratulations! You built your first flow module and displayed **Hello, world** in a **Display** block. --- # Customize request order in a collection run By default, when you [run a collection](/docs/collections/running-collections/intro-to-collection-runs/), Postman runs all requests in the order they appear in your collection. Requests in folders run first, followed by requests in the root of the collection. To dynamically change the order of requests during a collection run, use the `pm.execution.setNextRequest()` function in a post-response [script](/docs/tests-and-scripts/write-scripts/intro-to-scripts/). Instead of manually changing the order of requests each time you start a collection run, you can automate this behavior. Add `pm.execution.setNextRequest()` to your post-response scripts to specify which request Postman runs next, following the current request. With this function, you can build workflows that chain requests, running them one after the other in a custom order. ## Set the next request To specify the request to run next, add the following code on the **Scripts > Post-response** tab of a request. Replace `request_name` with the name or ID of the request you want to run next, in quotes. ```js pm.execution.setNextRequest("request_name"); ``` Postman runs the specified request after completing the current request. ## Loop over a request If you pass the name or ID of the current request to the `setNextRequest` function, Postman will run the current request again after it's completed. > **Important:** To prevent the request from looping indefinitely, add extra logic to the `setNextRequest` function. For example, you can set the request to exit the loop after a certain number of iterations or when another condition is met. Otherwise, to end the loop, you can force close the Collection Runner. For example, use the following post-response script in a request in a collection. When the collection is run, it runs the request three times, then exits. ```js var i = !pm.variables.get("i") ? 1 : pm.variables.get("i"); if (i < 3) { console.log("this is run " + i + " for request " + pm.execution.location.current); pm.execution.setNextRequest(pm.execution.location.current) i++; pm.variables.set("i", i); } else { pm.execution.setNextRequest(null); } ``` ## Stop a workflow To stop a workflow, you can enter "null" as the `pm.execution.setNextRequest()` function's argument in your post-response script. The collection run stops after the current request runs. If your collection run is configured to run more than one iteration, Postman stops each iteration after the current request runs. ```js pm.execution.setNextRequest(null); ``` > You can also skip a request using the `pm.execution.skipRequest()` method in your post-response script. Learn more about [skipping requests from pre-request scripts](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-execution/#pmexecutionskipRequest). ## Tips for building request workflows Keep the following tips in mind when using the `pm.execution.setNextRequest()` function. ### Use setNextRequest() when you run an entire collection Use the `pm.execution.setNextRequest()` function when running a collection with the Collection Runner, the Postman CLI, or Newman. It has no effect when you run a request in Postman using **Send**. ### Use setNextRequest() in pre-request or post-response scripts You can use `pm.execution.setNextRequest()` in the pre-request script or the post-response script of a request. If more than one value is assigned, the last value that's set takes precedence. ### Specify the next request using the request ID A request's name may change, but changing its name doesn't change its ID. For this reason, it's best to use the request ID when you specify the next request. When specifying the ID, it must be in quotes. For example: `pm.execution.setNextRequest("1ab12345-4ab4-4124-c000-12341abc1234");` To get the request ID of the currently running request, use `pm.info.requestId`. For example, run `console.log(pm.info.requestId)` to see the current request's ID. To learn more, see [Script Workflows](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-info/). You can also get the request ID in Postman. Open the request and, from the right sidebar, click \[![Image 1: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon)\] **Info**. The request ID is prepended with your user ID (the first block of characters). ### setNextRequest() always runs last The `pm.execution.setNextRequest()` function always runs at the completion of the current request, regardless of its location in the script. If you put code in the pre-request script or post-response script after this function, the code blocks will still run before `pm.execution.setNextRequest()`. ### setNextRequest() scope is limited to the collection The scope of `pm.execution.setNextRequest()` is the source of your collection run. * If you run an entire collection, you can set any request in the collection as the next request, even requests inside folders. * If you run a folder, the scope of `pm.execution.setNextRequest()` is limited to that folder. In this case, you can set any request in the same folder as the next request, but not requests located in other folders or at the root of the collection. Learn more about [running collections or folders](/docs/collections/running-collections/intro-to-collection-runs/). ## Next steps After learning about how to build request workflows, you can write some scripts. * To learn more about writing pre-request and post-response scripts, visit [Use scripts to add logic and tests to Postman requests](/docs/tests-and-scripts/write-scripts/intro-to-scripts/). --- # Capture HTTP traffic and sync cookies in Postman Capturing HTTP traffic is an important tool for API development and testing. Postman enables you to inspect the requests passing between client applications and your API and save them to a collection. You can use the saved requests to understand how your API is behaving and to assist with debugging. Postman's built-in proxy and Postman Interceptor provide two ways to capture HTTP and HTTPS traffic in Postman. You can also use the proxy or Interceptor to capture and sync cookies to the Postman cookie jar. To capture traffic, begin a proxy or Interceptor session. A session represents a specific time frame during which you want to capture traffic. For example, you can capture traffic while a client application is sending a series of requests that you want to observe or debug. After you stop the session, you can view the captured requests in Postman. You can also use Postman's search and filtering capabilities to narrow down the requests based on the criteria you choose. ## The Postman proxy A proxy is an intermediary server that sits between a client application (like a mobile app) and the destination server the client is communicating with (like an API). When the Postman proxy is enabled and a client has been configured to use the proxy, a request from the client goes to Postman first. Postman then forwards the request on to the destination server. If you start a proxy session while the proxy is enabled, Postman can capture any HTTP or HTTPS traffic passing through the proxy. You can then search or filter the requests, or save them to a collection. To capture requests using the Postman proxy, view the instructions for your operating system and Postman version: * If you're on macOS (Postman v10.17 or later) or Windows (Postman v10.18 or later), go to [Capture traffic using the Postman built-in proxy](/docs/sending-requests/capturing-request-data/capture-with-proxy/). * If you're on Linux (all Postman versions), macOS (Postman v10.16 or earlier), or Windows (v10.17 or earlier), go to [Capture HTTP requests in Postman](/docs/sending-requests/capturing-request-data/capturing-http-requests/). * To capture secure HTTPS traffic from a client device like a phone, you need to install the Postman security certificate on the device. To learn more, go to [Capture HTTPS traffic using the Postman built-in proxy](/docs/sending-requests/capturing-request-data/capturing-https-traffic/). To check which version of Postman you're using, click ![Image 1: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the header, click **Settings**, then click **About**. ## Postman Interceptor Postman Interceptor provides another way to capture requests sent between a client and a server. Interceptor uses a browser extension rather than Postman's built-in proxy. With Postman Interceptor, you can capture HTTP and HTTPS requests sent from a web browser. Learn more about [using Postman Interceptor](/docs/sending-requests/capturing-request-data/interceptor/). ## Capture and sync cookies Along with capturing requests, Postman can capture cookies during a proxy or Interceptor session. You can manually add any captured cookies to the [Postman cookie jar](/docs/sending-requests/response-data/cookies/) and use them when sending requests from Postman. Postman's built-in proxy and Interceptor also support continuous cookie syncing. Once enabled, all captured cookies for the domains you specify are automatically synced to the Postman cookie jar. Learn more about [syncing cookies](/docs/sending-requests/capturing-request-data/syncing-cookies/). ## Postman Power Pass FAQ ### General Information * **What is the Postman Power Pass?** Your team’s activity unlocked the best Postman experience. For free, you can explore premium access to unlimited invites, most Enterprise features, and add-on products. Designed to empower seamless collaboration across the entire API development lifecycle, the Postman Power Pass lets you explore our platform’s full potential. * **How long does the Postman Power Pass last?** The Postman Power Pass provides you with premium access for an extended period, but we recommend taking full advantage of this opportunity as soon as possible. While there’s no fixed access period, we encourage you to explore all the premium features and maximize your experience while the Postman Power Pass is active. We’ll keep you informed of any changes or updates regarding your access. * **What features are included in the Postman Power Pass?** You have access to almost all of the features with the Enterprise plan, enabling you to unlock seamless collaboration across the API development lifecycle. * **What add-on products are included in the Postman Power Pass?** You have complimentary access to the following add-on products: * **Unlimited tests with [Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/):** Collection Runner is designed for QA/QE Engineers who want to simplify the complexity of API testing across the entire development lifecycle. With just one click, you can set up regression, end-to-end, and scenario testing, ensuring your APIs are functional and stable within any application. * **Unlimited AI support with [Postbot](/docs/getting-started/basics/about-postbot/):** Postbot is an AI assistant within Postman designed to make API development more efficient. It helps you instantly test and document APIs, visualize API responses, and troubleshoot workflows. Postbot also provides expert support for tasks like building and debugging flows, making it a versatile assistant for every stage of your API lifecycle. * **Unlimited [Partner Editors](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/):** Accelerate partner onboarding, improve API adoption, and take collaboration with external partners to the next level. Partner Workspaces are secure, access-controlled spaces for you to invite one or multiple external partners to build and collaborate on APIs. With Postman Power Pass, you can invite as many Partner Viewers and Partner Editors as you’d like. * **Unlimited [runs on Flows](/docs/postman-flows/overview/):** Postman Flows is a powerful visual tool that simplifies the development and sharing of API-powered applications. An intuitive drag-and-drop interface it helps developers build API workflows from the ground up allowing them to understand how APIs and their components interact, much like an x-ray or blueprint. ### Organization Settings To configure your Organization Settings, click **Organization** in the Postman header, then select **Organization Settings**. ![Image 2: Organization settings](https://assets.postman.com/postman-docs/v11/organization-settings-v11.67.png) The settings enable you to do the following: * Create [Organization Teams](/docs/administration/organization/create/). * Configure your [team settings](/docs/administration/managing-your-team/team-settings/). * Manage [team members](/docs/administration/managing-your-team/team-members/overview/). * Manage [team resources](/docs/administration/managing-your-team/manage-team-workspaces/). * Manage [product access](/docs/administration/managing-your-team/manage-team-product-access/). * Manage [security](/docs/administration/managing-your-team/overview/#secure-your-postman-team). Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Organization roles * **Organization Managers** are responsible for creating Teams in the Organization and can manage any Team. They're also responsible for assigning individual Team Managers to the teams they create. * **Team Managers** can approve the adding of Members and the sharing of content from the Teams they manage. * **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ### Team roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | ------------ | ----------- | | Team Manager (Team Super Admin) | * Has edit access to all elements within the Team and the capability to edit the Team's Settings. * Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | * Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. * Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. * Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | * Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. * Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | ### Notes * Only a Team Member can create workspaces in the team. * Sharing an element with a new user triggers the process of adding that user to the Team's user list. * Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Connect Zoom to your Flows action You can connect [Zoom](https://www.zoom.com/) to a flow with the Zoom **Connector** block. Use this block to perform the following operations: * Create Meeting * Update Meeting * Get Meeting * Get Meeting By ID * Delete Meeting * Add Meeting Registrant * Get Meeting Registrant * Delete Meeting Registrant * Get Recording By Meeting ID * Search Recording To connect Zoom to a Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 1. Click ![Image 3: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. 1. Right-click the canvas and select **Zoom** from the list of blocks. 1. Click **Select an operation...** and select the operation you want the action to perform. 1. Click **Select an account...** and follow the prompts to connect your Zoom account. 1. Connect the **Request** block's output ports to the Zoom **Connector** block's input ports, based on the selected operation. 1. Connect the Zoom **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ![Image 4: Connect Zoom to your Flows action](https://assets.postman.com/postman-docs/v11/zoom-connector-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 5: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 1. Click ![Image 6: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 1. Click **Open Component Library**. ![Image 7: Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 1. Click ![Image 8: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 1. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 1. Click **Create**. ![Image 9: Create a component file](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 10: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 1. Click ![Image 11: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 1. Click **Open Component Library**. 1. Click a component file in the left sidebar. 1. Choose a published version of the component file using the version dropdown list. 1. In the left sidebar, click ![Image 12: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 1. Add the URL to a reference (`$ref`) in your specification. ![Image 13: Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 14: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 1. Click ![Image 15: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 1. Click **Open Component Library**. 1. Click a component in the left sidebar that you'd like to version and publish. 1. Click **Version & Publish** in the upper right corner. ![Image 16: Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 1. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 1. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ### Notes You can't delete published versions of component files. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 17: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 1. Click ![Image 18: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of a specification. 1. Click **Open Component Library**. 1. Search for a component file and select it in the left sidebar. 1. Choose a published version of the component file using the version dropdown list. 1. In the left sidebar, click ![Image 19: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 1. Add the URL to a reference (`$ref`) in your specification. ![Image 20: Reference a component in a specification](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 1. Click **Create Team**. ![Image 21: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 1. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 22: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click **Add Members**. To be added, members need to be part of the organization. ### Notes * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 23: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 1. Click **Create Workspace**. ![Image 24: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Select a blank workspace or a workspace template. Click **Next**. 1. Name the workspace. ![Image 25: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 1. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 1. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 1. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 1. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 1. Under **About**, add a summary. 1. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 1. Click **Post an Update**. 1. Enter a title and a description of your update. 1. Select **Announcement** from the dropdown list. 1. (Optional) Add a summary describing the change. 1. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 26: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 27: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 1. Click **Create Team**. ![Image 28: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 1. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 29: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click **Add Members**. To be added, members need to be part of the organization. ### Notes * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 30: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 1. Click **Create Workspace**. ![Image 31: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Select a blank workspace or a workspace template. Click **Next**. 1. Name the workspace. ![Image 32: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 1. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 1. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 1. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 1. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 1. Under **About**, add a summary. 1. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 1. Click **Post an Update**. 1. Enter a title and a description of your update. 1. Select **Announcement** from the dropdown list. 1. (Optional) Add a summary describing the change. 1. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 33: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 34: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 1. Click **Create Team**. ![Image 35: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 1. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 36: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click **Add Members**. To be added, members need to be part of the organization. ### Notes * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 37: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 1. Click **Create Workspace**. ![Image 38: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Select a blank workspace or a workspace template. Click **Next**. 1. Name the workspace. ![Image 39: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 1. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 1. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 1. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 1. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 1. Under **About**, add a summary. 1. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 1. Click **Post an Update**. 1. Enter a title and a description of your update. 1. Select **Announcement** from the dropdown list. 1. (Optional) Add a summary describing the change. 1. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 40: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 41: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 1. Click **Create Team**. ![Image 42: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 1. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 43: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click **Add Members**. To be added, members need to be part of the organization. ### Notes * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 44: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 1. Click **Create Workspace**. ![Image 45: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Select a blank workspace or a workspace template. Click **Next**. 1. Name the workspace. ![Image 46: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 1. Select the team for --- # Capture traffic using the Postman built-in proxy If you're using APIs to build client-side applications like mobile and desktop apps or websites, you may want to check the HTTP and HTTPS request traffic sent and received in the app. Sometimes you might discover undocumented APIs. You can capture network traffic, including requests, responses, and cookies, using the proxy that's built into Postman. ## How the built-in proxy works The Postman desktop app has a built-in proxy that can capture HTTP and HTTPS traffic. Here's how it works: 1. The Postman desktop app listens for any calls made by a client app or device using the proxy. 2. The Postman proxy captures the request and forwards it to the server. 3. The server returns a response to the Postman proxy, where it can also be saved. 4. The response is returned back to the client. ![Postman capture proxy](https://assets.postman.com/postman-docs/proxymobile-aa.jpeg) Similar to the [Interceptor extension](/docs/sending-requests/capturing-request-data/interceptor/), the Postman proxy intercepts and captures your requests. It can also capture responses and cookies. Starting the Postman proxy begins a _proxy session_, which is a time-bound period of traffic capture. You can pause, restart, and stop a proxy session, then later start another one. Each session is logged in the **History** tab and displays the total session time, a traffic overview, and all traffic captured. You can also send requests and responses to a collection and [save cookies to the Postman cookie jar](/docs/sending-requests/capturing-request-data/syncing-cookies/). ## Using the Postman proxy In the steps below, you'll use the Postman proxy to inspect HTTP and HTTPS communication going to and from your computer and phone. To get started, make sure your computer and phone are connected to the same local wireless network. ### Step 1: Start a proxy session You can't use the Postman proxy with the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations). Make sure you've installed the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/). 1. Click ![Image 2: Capture icon](https://assets.postman.com/postman-docs/aether-icons/action-capture-stroke.svg#icon) **Start Proxy** in the Postman footer. 2. (Optional) Click the port number to change it. By default, the port is set to 5559. Make a note of the port number, as you'll use it later when configuring clients. 3. Click **Start Proxy Session**. The first time you start a proxy session, Postman installs the **Postman Proxy CA** certificate on your computer. If prompted, enter your computer password to install the certificate. Installing the certificate enables the Postman proxy to capture secure HTTPS traffic sent from browsers and other client apps on your computer. ![Image 3: Start a proxy session](https://assets.postman.com/postman-docs/v10/proxy-start-session-v10-22.jpg) ### Step 2: Control the proxy session You can't have more than one proxy or Interceptor session running at the same time. When you start the proxy session, the Postman proxy begins capturing traffic sent from your computer. After you start a proxy session, you can pause, restart, or stop it. You can also select what traffic you want to capture during the session. To control an active proxy session, click ![Image 4: Capture icon](https://assets.postman.com/postman-docs/aether-icons/action-capture-stroke.svg#icon) **Proxy active** in the footer to display the proxy session tab. (If the proxy session is paused, click ![Image 5: Capture icon](https://assets.postman.com/postman-docs/aether-icons/action-capture-stroke.svg#icon) **Start Proxy** in the footer.) The proxy tab shows the total duration of the session and the size of the data captured. With the proxy active, open a web browser and navigate to a website, or open an app that communicates with a server. Requests appear in the proxy session tab as they're captured. From the proxy session tab, you can take the following actions: * Click **Pause** to temporarily stop capturing traffic, then click **Resume** when you're ready to begin capturing traffic again. When you're finished capturing traffic, click **Stop** to end the proxy session. * Click **Save responses for requests** to save each request's response along with the captured request. * Click **Capture cookies** if you want to capture cookies along with requests during the proxy session. \u003e You can also capture cookies and sync them to Postman without starting a proxy session. Learn more about [syncing cookies](/docs/sending-requests/capturing-request-data/syncing-cookies/). * Click ![Image 6: Sort icon](https://assets.postman.com/postman-docs/aether-icons/table-sort-stroke.svg#icon) in the column headers to sort the results in ascending or descending order. * Click ![Image 7: Filter icon](https://assets.postman.com/postman-docs/aether-icons/action-filter-stroke.svg#icon) in the column headers to limit the requests and responses that are captured while the session is active. Postman captures requests that match the selected criteria and ignores requests that don't match. You can change the filters at any time during the session: * **Status** - Limit captured requests to the selected status codes. * **Method** - Limit captured requests to the selected methods. * **URL** - Limit captured requests to URLs that match the specified criteria. You can specify text that URLs must contain and can't contain, and you can use regular expressions. Click **Enter** to apply the specified filters. To remove a filter, click ![Image 8: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) next to the filter. * **Type** - Limit captured requests to the selected content types. \u003e In responses with a `content-type` that has images, audio, or video, the content is intercepted but not captured. The information captured is response headers, time taken, and the status code. ![Image 9: Control a proxy session](https://assets.postman.com/postman-docs/v10/proxy-control-session-v10-22.jpg) ### Step 3: View the proxy session results While your proxy session is running, the proxy session tab shows captured traffic as you use a browser or apps on a client device. You can view the status, method, URL, type, response size, response time, and timestamp for each captured request including. You can view and work with the proxy session results while the session is active or paused, or after you stop the session. * To rename the proxy session, click **Proxy debug session** and enter a new name. * Select the **Requests** tab to view information about incoming requests and responses, or select the **Cookies** tab to view information about captured cookies. * Use the search box to find specific requests or cookies. * Click a request to view more details. * Click a request URL to open it as a new API request in Postman. * To delete a request or cookie, select it and click ![Image 10: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. * To add a cookie to the [Postman cookie jar](/docs/sending-requests/response-data/cookies/), select it and click **+ Add to Cookie Jar**. ![Image 11: View proxy session results](https://assets.postman.com/postman-docs/v10/proxy-view-results-v10-22.jpg) ### Step 4: Stop the proxy session When you're finished capturing traffic, click **Stop** to end the proxy session. To view the proxy session again later, click **History** in the sidebar, then select the proxy session. You can also click ![Image 12: History icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-history-stroke.svg#icon) **View Past Sessions** on the proxy session tab. The **Overview** tab shows summary graphs of traffic captured in the proxy session. Use the dropdown menu to group requests by method, domain, content type, or status code. The header also displays the session start time, session size, duration, and source. To filter the list of requests, click ![Image 13: Filter icon](https://assets.postman.com/postman-docs/aether-icons/action-filter-stroke.svg#icon) in the column headers. Postman displays requests that match the selected filters and hides requests that don't match. To save captured requests to a collection, do the following: 1. Stop the proxy session if it's still active. 1. Select the checkbox next to the requests you want to save, or select the checkbox in the column header to select all requests. 1. Click **Save Requests**. 1. Select the collection where you want to save the requests, or click **New collection** to create a new collection. 1. Choose how to organize the requests in the collection. You can select the checkboxes to group the requests in folders organized by **Domain name**, **Endpoints**, or both. 1. Click **Save**. ![Image 14: Save captured requests to a collection](https://assets.postman.com/postman-docs/v10/proxy-create-collection-v10-22.jpg) ### Step 5: Configure the proxy on a client device You can use the Postman proxy to capture traffic from a client device such as a phone. 1. Start a new proxy session. Click ![Image 15: Capture icon](https://assets.postman.com/postman-docs/aether-icons/action-capture-stroke.svg#icon) **Start Proxy** in the Postman footer, then select **Start Proxy Session**. 2. Find the local IP address of the computer running the proxy: * On macOS, you can find your computer's IP address in **System Settings > Network**. Select a network interface, and if necessary select **Details > TCP/IP** to view your system's IP address. * On Windows, select **Start > Settings > Network & Internet > Wi-Fi** or **Ethernet**, and then select your connection. Your IP address is listed under **Properties**. 3. Open the wireless settings of your client device and update the configuration of the network connection to use an HTTP Proxy. For example, in iOS: 1. Select **Settings > Wi-Fi**. 1. Click ![Image 16: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) next to your Wi-Fi connection. 1. Select **Configure Proxy > Manual**. 1. Set **Server** and **Port** to the local IP address and proxy port. 1. Click **Save**. 4. Open a web browser or app on the device, then view captured traffic on the proxy session tab in Postman. \u003e To capture secure HTTPS traffic, you need to install the `postman-proxy-ca.crt` certificate on the client device. To learn how to install the certificate on your device, go to [Capturing HTTPS traffic](/docs/sending-requests/capturing-request-data/capturing-https-traffic/). #### Configuring a proxy on other devices The broader development community has published some useful tutorials for setting up a proxy server on various operating systems: * [macOS](https://support.apple.com/en-gb/guide/mac-help/mchlp2591/mac) * [Windows](https://support.microsoft.com/en-us/windows/use-a-proxy-server-in-windows-03096c53-0554-4ffe-b6ab-8b1deee8dae1#ID0EFD=Windows_10/) * [Linux](https://www.shellhacks.com/linux-proxy-server-settings-set-proxy-command-line/) * [Android](https://proxyway.com/guides/android-proxy-settings) ## Troubleshoot vault secrets You can reference vault secrets stored in your Postman Vault by adding a vault secret reference in the request body. For example, to reference a vault secret named `postman-api-key`, use the following syntax: ```txt {{vault:postman-api-key}} ``` To learn more about troubleshooting empty and unresolved vault secrets, see [Troubleshoot vault secrets](#troubleshoot-vault-secrets). ## Postman Vault integrations Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) * [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) You can create Postman Vault integrations from the Postman desktop app or the Postman web app. If you're using the Postman web app, you can add new vault secrets to your Postman Vault by selecting the appropriate option from the Vault settings. ## Organization settings To configure your Organization Settings, click **Organization** in the Postman header, then select **Organization Settings**. ![Image 17: Organization settings](https://assets.postman.com/postman-docs/v11/organization-settings-v11.67.png) The settings enable you to do the following: * Create [Organization Teams](/docs/administration/organization/create/). * Configure your [team settings](/docs/administration/managing-your-team/team-settings/). * Manage [team members](/docs/administration/managing-your-team/team-members/overview/). * Manage [team resources](/docs/administration/managing-your-team/manage-team-workspaces/). * Manage [product access](/docs/administration/managing-your-team/manage-team-product-access/). * Manage [security](/docs/administration/managing-your-team/overview/#secure-your-postman-team). Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. The Team Manager is the delegated owner of the Team’s content and membership and controls how the Team’s content is shared. The Team Manager is the leader of people responsible for the Team’s content. 1. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** — Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** — Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 1. Populate the team with the members who are responsible for the team’s contents. * If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 18: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 19: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. ![Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 4. Click ![Image 20: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 5. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 6. Click **Create**. ![Create a component file](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 21: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 22: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 23: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 24: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 25: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component in the left sidebar that you'd like to version and publish. 5. Click **Version & Publish** in the upper right corner. ![Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 6. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 7. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 26: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 27: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of a specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 28: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 29: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team Settings** in the Postman header, then click **Organization Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Click **Add**. 6. Enter a name for the team. 7. Click **Add Members**. To be added, members need to be part of the organization. 8. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) Postman adds a new team file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. \u003e If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 30: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 31: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Manage secret policies with Local Secret Protection With the Postman Component Library, you can manage reusable components for your team's OpenAPI specifications in [Spec Hub](/docs/design-apis/specifications/overview/). Maintain and standardize commonly used components in a central location, without having to redefine them in each specification. Reusable components can include schemas, responses, parameters, and more. Publish a new version when you're ready to share changes with your team. ### Create a component file Create a component file in your team's component library. Name the file and specify the OpenAPI specification format the components will be used in. In the file, define components that your teammates can reuse in their specifications. 1. Click ![Image 32: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 33: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. ![Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.jpg) 4. Click ![Image 34: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 5. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 6. Click **Create**. Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ### Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 35: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 36: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 37: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 38: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 39: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component in the left sidebar that you'd like to version and publish. 5. Click **Version & Publish** in the upper right corner. ![Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 6. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 7. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 40: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 41: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of a specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 42: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the --- # Collaborate in Postman Postman has a variety of features that enable you to collaborate with your team and API consumers. You can design and implement an API lifecycle, organize your team and work, communicate changes, and share your work internally and with the world. With these features, you can tailor your collaboration strategy to each project's specific goals. ## Understand how teams and workflows function in Postman You can collaborate on your APIs within [one or more teams](/docs/collaborating-in-postman/use-teams/), across the entire company, or with partner companies. Implement collaboration workflows across different phases of the API development lifecycle, including prototyping, iterating, building, testing, deploying, and integrating with partners. Learn more about [Postman collaboration concepts](/docs/collaborating-in-postman/collaboration-concepts/). ## Learn about Postman's collaboration features Postman enables you to collaborate with your teammates and the Postman community by organizing, sharing, and communicating work to your APIs. Learn about [Postman's collaboration features](/docs/collaborating-in-postman/api-collaboration-features/). ## Organize your projects using workspaces Workspaces enable you to collaborate with teammates or anyone in the Postman community. When you create a workspace, you can choose an empty workspace or use a workspace template to help you get started. You can also view changelogs for collections, workspaces, and APIs, enabling you to review actions taken on elements in your workspaces. Learn how you can [organize your projects using workspaces](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Share your workspaces and elements You can share your workspaces and elements with specific [team members and users who aren't part of your team](/docs/collaborating-in-postman/sharing/). You can share with internal team members to your team's [Private API Network](/docs/collaborating-in-postman/private-api-network/overview/), and share with your API consumers on the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). You can also [start a live session](/docs/collaborating-in-postman/live-sessions/) in an HTTP request to collaborate with your team in real time as you test, develop, and troubleshoot. Super Admins and Community Managers can use the [Manage public elements dashboard](/docs/collaborating-in-postman/manage-public-elements/) to control which public workspaces, documentation, and collections are shared with external users. ## Define roles and permissions You can define the [roles and permissions](/docs/administration/roles-and-permissions/) assigned to team members at the team, workspace, and element levels. You can also define roles and permissions that relate to Partner Workspaces and your Private API Network. Postman enables you to [organize team members into groups](/docs/administration/managing-your-team/user-groups/) that reflect your organization. Add users to a group, then assign that group roles and access to the resources they'll be using across Postman. This also enables you to efficiently onboard new team members by adding them to existing groups assigned relevant roles. You can also [manage access to workspaces and elements](/docs/collaborating-in-postman/requesting-access-to-elements/) in your team. ## Build APIs using Postman's version control You can [use Postman's version control](/docs/collaborating-in-postman/using-version-control/version-control-overview/) to collaboratively build APIs with your team. This enables you and your team to fork a new instance of an element, make updates to the fork, create a pull request, and merge your changes into the parent element. --- # Collaborate with your team on your collection Once you [connect your GitHub repository and primary branch to your collection](/docs/integrations/available-integrations/github/collections/connect/#connect-a-github-repository-and-branch-to-your-collection), you can fork your collection and collaborate with your team on it. ## Fork a collection connected to your GitHub repository and branch Before you get started, create your feature branch. To fork a collection connected to your GitHub repository and branch, do the following: 1. Open your primary collection. 2. Next to your collection, click ![Image 1: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Fork**. 3. Select a workspace. 4. Confirm your fork is linked to your branch. Then, select a branch. 5. Click **Fork Collection**. Postman creates a collection file in the connected repository and branch. The collection's file name is the collection ID. Each time you save your collection in Postman, your changes are committed to the connected GitHub repository and branch. ## Collaborate on your collection With GitHub and Postman, you start collaborating by [forking your primary collection](#fork-a-collection-connected-to-your-github-repository-and-branch) and making changes in Postman. Your teammates can join you and contribute to your changes. When you're ready for your team to review your changes, you create a pull request and merge it in GitHub. To collaborate on your collection's next release, do the following: 1. Open your forked collection and make changes to it in Postman. 2. When you're ready for your team to review your changes, create a pull request in GitHub and ask your team to review it. 3. When you're ready to merge your changes with your primary collection, merge your pull request in GitHub. 4. (Optional) Delete your forked collection. When you merge your pull request in GitHub, Postman updates your primary collection in Postman with the updates from your forked collection. --- # collection-sdk Create and manage collections using the Collection SDK | Postman Docs =============== Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK to automate part of your collection run workflow, you can integrate your Collection SDK development with the Postman CLI or with Newman. * To learn more about integrating your Collection SDK development with the Postman CLI, visit [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * To learn more about running collections with Newman, visit [Run and test collections from the command line using Newman CLI](/docs/collections/using-newman-cli/command-line-integration-with-newman/). --- Create and manage collections using the Collection SDK ==================================================== The Collection SDK is a Node.js module that enables you to work with Postman [Collections](/docs/sending-requests/create-requests/intro-to-collections/) and build them dynamically into your API project pipeline. With the Collection SDK, you can create and manipulate, and export collections. You can then run them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) and the [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) command-line collection runner. ## Accessing the Collection SDK The Collection SDK is an open-source project. [Visit the repo](https://github.com/postmanlabs/postman-collection) for more detail on using the module in your own projects. The [SDK documentation](http://www.postmanlabs.com/postman-collection/) provides an overview of the available objects and methods within the SDK, and an intro to the related [concepts](http://www.postmanlabs.com/postman-collection/tutorial-concepts.html). You can install the SDK from [npm](https://www.npmjs.com/package/postman-collection) or directly from the repo. The following excerpt demonstrates using the SDK to read a file and parse it into a collection object in JavaScript: ```js var fs = require('fs'), Collection = require('postman-collection').Collection, myCollection; myCollection = new Collection(JSON.parse (fs.readFileSync('sample-collection.json').toString())); console.log(myCollection.toJSON()); ``` The Collection SDK provides an interface for working with the data structures defined by the [Postman Collection Schema](https://schema.postman.com/). You can use the SDK methods to create and manipulate collection elements, define request detail, variables, and authentication. Get started with the Collection SDK from the [project repo](https://github.com/postmanlabs/postman-collection), installing it and using the methods to build collections in a way that suits your development or testing project. You can also fork and contribute to the project, or create issues for any problems or feature requests. ## Next steps If you're working with the Collection SDK --- # Run and test collections from the command line using Newman CLI Newman is a command-line tool for running Postman Collections. Use Newman to run and test collections from the command line instead of in the Postman app. Newman is built with extensibility in mind, so you can incorporate it in your continuous integration (CI) pipelines and build systems. The topics in this section will help you get started with Newman. For complete usage information, see Newman in the [npm registry](https://www.npmjs.com/package/newman) or on [GitHub](https://github.com/postmanlabs/newman). > **You can also run collections from the command line with the [Postman CLI](/docs/postman-cli/postman-cli-overview/).** For more information on the differences between Newman and the Postman CLI, see [Decide which command-line companion to use](/docs/postman-cli/postman-cli-overview/#decide-which-command-line-companion-to-use). ![Running Newman](https://assets.postman.com/postman-docs/newman-running-in-terminal.gif) ## Get started in Newman To get started, install Node.js and Newman, then run your collections. Learn more about [installing and running Newman](/docs/collections/using-newman-cli/installing-running-newman/). You can also run Newman using Docker. Learn more about [running Newman with Docker on macOS, Ubuntu, and Windows](/docs/collections/using-newman-cli/newman-with-docker/). ## Newman options Newman provides a rich set of options to customize a collection run. Learn more about [Newman options](/docs/collections/using-newman-cli/newman-options/). ## Upload files in Newman Newman supports file uploads, so you can use a data file (such as a text file) to fill in form data fields. Learn more about [uploading files in Newman](/docs/collections/using-newman-cli/newman-file-uploads/). ## Newman reporters Reporters can generate collection run reports for specific use cases, for example, logging the response body when a request (or its tests) fail. Learn more about using [Newman built-in reporters](/docs/collections/using-newman-cli/newman-built-in-reporters/) and [Newman external and custom reporters](/docs/collections/using-newman-cli/newman-custom-reporters/). ## Newman and continuous integration (CI) You can integrate Newman in your continuous integration (CI) environment. Run your collections and tests automatically after every code push. Learn more about [using Newman with CI](/docs/collections/using-newman-cli/continuous-integration/), [using Newman with Travis CI](/docs/collections/using-newman-cli/integration-with-travis/), or [using Newman with Jenkins](/docs/collections/using-newman-cli/integration-with-jenkins/). ## Troubleshoot vault secrets You can reference vault secrets stored in your local vault or a cloud vault by adding the vault secret inside double curly braces (`{{vault:secret-name}}`) and appending the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` To learn more about troubleshooting empty and unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). --- # The Condition block ![Condition block](https://assets.postman.com/postman-docs/v11/flows-condition-block-v11-50.jpg) The **Condition** block is a logical gate that routes data through one of multiple output ports based on the results of one or more conditions. It assigns incoming data to variables and checks the variables against a series of true/false expressions you provide. You can write the expressions using [TypeScript](/docs/postman-flows/typescript/typescript-overview/) or [Flows Query Language](/docs/postman-flows/flows-query-language/introduction-to-fql/) (FQL). Each condition has an output port. The first condition that returns true sends the data from its corresponding output port. If no conditions return true, the data is routed through the **Default** output port. By combining multiple conditions, a single **Condition** block can do the work of multiple [**If**](/docs/postman-flows/reference/blocks/if/) or [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) blocks. ## Inputs **variable** - You can connect a block to this input port or [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) a data block to assign data to a [variable](/docs/sending-requests/variables/variables-intro/). You can then reference the variable in your expressions. You can also click ![Add data blocks](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks** to insert a data block into the **Condition** block. You can change an inserted block to a different data block by clicking the inserted block's icon and selecting a different block from the dropdown list. **Condition ** - Enter a true/false expression here using TypeScript or FQL. Click the dropdown list at the top of the block to select TypeScript or FQL. Click ![Add condition](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add condition** to add another **Condition** field. To rename a condition, hover over the condition's name and click ![Edit icon](https://assets.postman.com/postman-docs/aether-icons/action-edit-stroke.svg#icon) **Edit Title**. To delete a condition, hover over it and click ![Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon). ## Outputs The first condition that evaluates to true routes the input data through its output port, and the block stops checking conditions. For example, if **Condition 1** evaluates to false and **Condition 2** evaluates to true, the input data is routed through the **Condition 2** output port. Once a condition returns true, no other conditions are checked. If no conditions are true, the input data is routed through the **Default** output port. ## Setup 1. To receive and evaluate data from another block in your flow, connect the **variable** input port to the other block's output port. 2. (Optional) To [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) a block and evaluate its data, click ![Add data blocks](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks** then select a block from the dropdown list. You can reference the inserted block's value as a variable in your true/false expressions. To rename the variable, click the inserted block's name and enter a new name. 3. Click the dropdown list next to the block's title and select **TypeScript** or **FQL**. 4. Enter your true/false expression in the text box. 5. (Optional) Click ![Add condition](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add condition** to add another condition and enter an expression. ## Example To see the **Condition** block in an example flow, check out [Flow Snippets: Condition](https://www.postman.com/postman/flows-snippets/flow/677c1263c3b62c003d81e9f8). ## Related blocks * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**If**](/docs/postman-flows/reference/blocks/if/) You can insert the following blocks into the **Condition** block to evaluate their data: * [**Bool**](/docs/postman-flows/reference/blocks/bool/) * [**Date**](/docs/postman-flows/reference/blocks/date/) * [**Date & time**](/docs/postman-flows/reference/blocks/date-and-time/) * [**Get Configuration**](/docs/postman-flows/reference/blocks/get-configuration/) * [**Get Variable**](/docs/postman-flows/reference/blocks/get-variable/) * [**List**](/docs/postman-flows/reference/blocks/list/) * [**Now**](/docs/postman-flows/reference/blocks/now/) * [**Null**](/docs/postman-flows/reference/blocks/null/) * [**Number**](/docs/postman-flows/reference/blocks/number/) * [**Record**](/docs/postman-flows/reference/blocks/record/) * [**Select**](/docs/postman-flows/reference/blocks/select/) * [**String**](/docs/postman-flows/reference/blocks/string/) --- # Configure API Governance rules in Postman > Configurable governance rules are available with [Postman Enterprise plans](https://www.postman.com/pricing/). If you don’t have an Enterprise account, you’ll be able to see the API Governance page, but you won’t be able to add new rules. You can configure the API Governance rules that Postman applies to your [API specifications](/docs/api-governance/api-definition/api-definition-warnings/) in the Postman API Builder and Spec Hub. Follow API Governance rules at the beginning of the [API lifecycle](https://www.postman.com/api-platform/api-lifecycle/) to keep your APIs consistent without requiring more work later. Super Admins and API Governance Managers can configure rules and turn them on and off for public workspaces and internal workspaces everyone in your team can access. See [Define roles and permissions within a Postman team](/docs/administration/roles-and-permissions/#team-roles) for more information. You can [create](#add-custom-rules) and [edit](#edit-custom-rules) your own custom rules to evaluate your team’s APIs. You can also [import existing rules](#add-rules-to-your-api-governance-configuration) into your team’s rule library. Then [create a workspace group](#turn-configured-rules-on-and-off) with the workspaces and rules you’d like Postman to apply to your APIs. ![Image 1: API governance dashboard](https://assets.postman.com/postman-docs/v11/api-governance-dashboard-v11.jpg) To access the configurable API Governance rules, do the following: 1. Go to the [Postman home screen](https://go.postman.co/). 2. Click **API Governance** in the team information pane. ## Add custom rules You can create new custom rules that Postman can use to evaluate your API specifications in the API Builder or Spec Hub. Postman provides you with a boilerplate rule to help you start writing your custom rules. You can also use snippets of commonly used property-value pairs to help you write your custom rules. To add a custom rule, do the following: 1. Go to the [Postman home screen](https://go.postman.co/), and then click **API Governance** in the team information pane. 1. Click **Create Rule**. 1. Define the rule in the editor. It must adhere to [custom Spectral rule guidelines](/docs/api-governance/configurable-rules/spectral/). You can use a curated list of commonly used property-value pair snippets to write your rules. Snippets are available in the right pane of the editor. Selecting a snippet adds the property-value pair automatically to your rule, helping you get started with writing rules. Once added to your rule, you can edit the snippets to meet your specific requirements. > Postman will prompt you with suggestions as you enter text. Select one to autocomplete your rule. 1. The rule must be valid YAML or JSON. Use the dropdown list to choose the correct syntax. 1. Click **Create**. ![Image 2: Create a custom API Security rule](https://assets.postman.com/postman-docs/v11/api-governance-create-new-custom-rule-v11-40.jpg) 1. Find your new rule under **Custom Rules** and [turn it on](#turn-configured-rules-on-and-off). You can also click **Upload file(s)** to upload a new rule in valid YAML or JSON format. > You can't create a custom rule that duplicates an existing rule. > You can write and add custom functions to your custom governance rules that Postman applies to your API specifications. For more information, see [Create custom governance functions in Postman](/docs/api-governance/configurable-rules/configuring-custom-governance-functions/). ## Edit custom rules You can edit custom governance rules you created earlier. To edit a custom rule, do the following: 1. Select the **Rule Library** tab, and then select the **Rules** tab. 1. Under **Created by your team**, select the name of the custom rule you’d like to edit. ![Image 3: Create a custom API Governance rule](https://assets.postman.com/postman-docs/v10/edit-custom-governance-rule-v10.jpg) 1. Edit the custom rule, and then click **Save**. You can also click **Delete** to delete the custom rule. Then click **Delete** to confirm. If you delete a custom rule, and you want to add it back into Postman, you must click **Create Rule** to create the rule again. ## Add rules to your API Governance configuration In addition to the rules turned on by default in Postman, you can add other rules to your team's rule library from the rule library. You can also create your own custom rules. ### Import rules from the rule library The rule library has Postman's API governance guidelines, Zalando's RESTful API and event guidelines, and Postman's OWASP API guidelines. 1. Select the **Rule Library** tab, and then select the **Rules** tab. 1. Click **Import** to open the rule library. 1. Click **Import** next to a rule to import it. Details and API format requirements are available under the rule name. > You can click **View all** below a set of guidelines to view all of its rules. To import all rules for a particular set of guidelines, click **Import All**. ![Image 4: Import API Governance rule from Postman library](https://assets.postman.com/postman-docs/import-postman-rule-from-rule-library-10.12.0.jpg) 1. Once you import new rules from the library, add the rules to a workspace group to [turn them on](#turn-configured-rules-on-and-off) for the workspaces in the group. ## Turn configured rules on and off To meet your team's development needs, you can turn individual governance rules on or off for public workspaces and internal workspaces everyone in your team can access. To do so, select the **Workspace Groups** tab. You can create a new group of workspaces to apply individual governance rules to by clicking **Create Group**, or you can select an existing group to update its governance configuration. To apply individual governance rules to all workspaces, select the default **All workspaces** group. To turn a governance rule on or off for a workspace group, select an existing group, and then click **Edit**. To turn a governance rule on, select the checkbox next to the rule name. To turn a governance rule off, clear the checkbox next to the rule name. ![Image 5: Turn individual rules on and off](https://assets.postman.com/postman-docs/api-governance-turn-rules-on-off-10.12.0.jpg) Once you've made the desired changes, click **Review Changes**, then **Apply Changes** to save them. Your team will only see violations for the governance rules that have been explicitly applied to the workspace the API resides in. You can view detailed metrics on API Governance rule compliance in your specifications. Learn how to view metrics for specifications in [Spec Hub](/docs/reports/api-governance-specifications-reports/) and [the Postman API Builder](/docs/reports/api-builder-reports/). ## Remove rules from your API Governance configuration To remove an API Governance rule, locate the rule in your team's rule library and click ![Image 6: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke-small.svg#icon) **Remove** next to its name. You can later choose to [re-import it from the rule library](#import-rules-from-the-rule-library). If you remove a custom rule, you'll need to add it back into Postman using [**Create Rule**](#add-custom-rules) if you want to use it again. --- # Connect a GitHub repository to your collection Connect a GitHub repository and branch to your collection and collaborate with your team on your collection's releases. For example, connect your repository's primary branch to your collection, [fork that collection in Postman](/docs/integrations/available-integrations/github/collections/collaborate/#fork-a-collection-connected-to-your-github-repository-and-branch), and [collaborate with your team on your collection's next release](/docs/integrations/available-integrations/github/collections/collaborate/#collaborate-on-your-collection). ## Connect a GitHub repository and branch to your collection Before you get started, create your repository and primary branch. To connect a GitHub repository and branch to your collection, do the following: 1. Open your collection. 2. Next to your collection, click ![Image 1: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **More** > **Connect repository**. 3. Choose where you host your repository: - If you choose **GitHub**, Postman asks you to authenticate. Follow the onscreen instructions. - If you choose **GitHub Enterprise Server**, Postman asks you for your GitHub domain. Enter or select it, and click **Authenticate**. Then, follow the onscreen instructions. 4. Select an organization. 5. If you don't see your organization, you may need to [install the GitHub App to your organization first](https://docs.github.com/apps/using-github-apps/installing-a-github-app-from-a-third-party). To get started, follow the onscreen instructions. 6. Select a repository and branch. 7. (Optional) Enter a directory path for your collection file. 8. Click **Connect**. Postman creates a collection file in the connected repository and branch. The collection's file name is the collection ID. Each time you save your collection in Postman, your changes are committed to the connected GitHub repository and branch. To start collaborating on your next release, see [Collaborate on your collection's release](/docs/integrations/available-integrations/github/collections/collaborate/). ## Disconnect a GitHub repository and branch from your collection If you want to connect a different repository or branch to your collection, or need to troubleshoot your connection, you can start by disconnecting GitHub from your collection. To disconnect a GitHub repository and branch from your collection, do the following: 1. Open your collection. 2. Next to your collection, click ![Image 2: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **More** > **Disconnect repository**. 3. Enter your collection's name. Then, click **Disconnect repository**. Your collection is no longer connected to the GitHub repository and branch. --- ## Connect Postman with Azure API Gateway Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ### Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ### Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: - Azure Tenant ID - Azure Client ID - Azure Client Secret - Azure Subscription ID 5. Click **Next**. 6. The new installed app appears on the Installed apps page with the status as **Connected**. 7. Click **Next**. 8. Select the API you want to import. 9. Select the stage on which the API is deployed. 10. Create an environment (optional). This creates a new environment on Postman for the API variables from the gateway. 11. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 12. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 13. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ### Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ### Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 3: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. 4. Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: - HTTP collections - Environments variable values - Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage workspace scan policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: - To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. - To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). --- ## Organization Settings Postman has a variety of tools you can use to set up, manage, and secure your Postman team. ### Create Organization Teams To create an Organization Team, do the following: 1. Access ![Image 4: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Organization Settings** in the Postman header, then click **Organization Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. ### Team roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | - Has edit access to all elements within the Team and the capability to edit the Team's Settings. - Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | - Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. - Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. - Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | - Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. - Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | ### **Notes** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. 4. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 5. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 6. Ensure that workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. 7. Make the workspace editable by the Team. - Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. 8. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 5: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Organization Settings** in the Postman header, then click **Team Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 8. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 9. Ensure that workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. 10. Make the workspace editable by the Team. - Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. 11. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. ### **Notes** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ### Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ### View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). --- ## Organization roles _Postman Organizations_ streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives each team better control over its membership. ### Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 6: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Organization Settings** in the Postman header, then click **Team Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 8. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 9. Ensure that workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. 10. Make the workspace editable by the Team. - Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. 11. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. ### **Notes** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. 4. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 5. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 6. Ensure that workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. 7. Make the workspace editable by the Team. - Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. 8. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. ### **Notes** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 7: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Organization Settings** in the Postman header, then click **Team Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 8. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 9. Ensure that workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. 10. Make the workspace editable by the Team. - Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. 11. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. ### **Notes** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ### Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file --- # Run Postman Collections in your CI environment using Newman You can use [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) and the [Postman API](https://api.postman.com/) to run Postman Collections in your continuous integration (CI) environment. First install Node.js and Newman in your CI environment. You can then use Newman to get and run your collection using the Postman API. ## Prerequisites Before you begin, check the following prerequisites for running collections using Newman and the Postman API: * Make sure you have a CI system setup that can run shell commands and that you have edit access. * [Generate a Postman API key](/docs/developer/postman-api/authentication/#generate-a-postman-api-key), and copy it for later use. * Make sure you have a Postman Collection that tests your localhost server, and copy the collection ID for later use. If your collection needs an environment, copy the environment ID for later use. **Developing an API?** Postman offers built-in tools to integrate your API with some of the most popular continuous integration (CI) tools. After you set up CI for your API, you can view the status of builds or start a new build, all from within Postman. You can also use Newman to run API tests as part of your CI pipeline. To learn more, see [CI integrations](/docs/integrations/ci-integrations/). ## Install Newman and Node.js To learn how to install Newman and Node.js, see [Install and run Newman](/docs/collections/using-newman-cli/installing-running-newman/). You don't need to install Node.js if your CI environment already has it installed. ## Run a collection using Newman and the Postman API To run a collection using Newman and Postman API, use the following command: ```bash newman run "https://api.getpostman.com/collections/collection-id?apikey=postman-api-key" ``` If you need to provide an environment to the collection, add the `--environment` option with the appropriate parameters to the Newman command: ```bash newman run "https://api.getpostman.com/collections/collection-id?apikey=postman-api-key" --environment "https://api.getpostman.com/environments/environment-id?apikey=postman-api-key" ``` Learn more about [using Newman with the Postman API](https://github.com/postmanlabs/newman?tab=readme-ov-file#using-newman-with-the-postman-api). --- # cookies Create and capture cookies using Postman's cookie manager ======================================================== Postman's cookie manager enables you to view and edit cookies that are associated with different domains. You can manually create cookies for a domain, or you can [capture cookies](/docs/sending-requests/capturing-request-data/syncing-cookies/) using the Postman proxy or Postman Interceptor. You can then use the cookies stored in the Postman cookie jar when sending requests in Postman. To turn off sending cookies with a request, select the request's **Settings** tab, then select **Disable cookie jar**. ## About cookies A _cookie_ is a packet of data that a computer receives and then sends back without changing or altering it. Most cookies have two pieces of data: a unique ID for each user and a site name. Websites can retrieve the cookie when you revisit them, so they can remember you and your preferences and tailor page content for you based on this information. Without cookies, you'd have to sign in again after you leave a site or rebuild your shopping cart if you closed a web page. This makes cookies an important part of the internet experience. ## Use the cookie manager To manage cookies in Postman, open a request, then select **Cookies** (under **Send**). ![Cookies link](https://assets.postman.com/postman-docs/v11/cookies-link-v11-b.jpg) In the **Cookies** window, select the **Manage Cookies** tab to display a list of domains and the cookies associated with each one. If you want to view cookies for a domain that isn't in the list, you can [add a domain](#add-a-domain). ![Managing cookies](https://assets.postman.com/postman-docs/v11/manage-cookies-v11-1.jpg) ## Add a domain To add a new domain to the cookie manager, do the following: 1. Select the **Type a domain name** search box. 1. Enter the domain name. If you enter a protocol (such as `http://`) or port number, they won't be stored with the domain name in the cookie manager. 1. Select **Add domain**. ## Create cookies To add a new cookie for a domain, select \u003cimg alt=\"Add icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon\" width=\"16px\"\u003e **Add Cookie** under the domain. A pre-generated cookie string compliant with [HTTP State Management standards](https://datatracker.ietf.org/doc/html/rfc6265#section-4.1) is created. ```js Cookie_1=value; Path=/; Expires=Wed, 09 Oct 2024 21:49:26 GMT; ``` Postman supports the following attributes: * **cookieName** = **cookieValue** - The name of the cookie and its stored value. * **Domain** - The domain Postman will send the cookie to. * **Path** - The URL path that the cookie is restricted to. If the path is `/`, the cookie will be sent to all requests in the specified domain. * **HttpOnly** - If present, the cookie won't be available to the client-side scripts run on the page (for example, with `document.cookie` in JavaScript). The cookie will only be added to the cookie header in requests that are made. This field doesn't have an effect on Postman's behavior. * **Secure** - If present, the cookie is only sent when the URL begins with `https://` and won't be sent over an insecure connection. * **Expires** - The time after which the cookie expires and won't be sent by Postman. Select **Save** to save the cookie to the Postman cookie jar under the relevant domain. Postman doesn't support the `SameSite` attribute, or the `__Secure-` and `__Host-` prefixes. You can also add or edit the cookies in a response with the [Set-Cookie header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie). ## Edit or delete cookies To update an existing cookie for a domain, select the cookie you want to edit, edit any attribute, then select **Save**. To delete a domain and all cookies associated with it, select \u003cimg alt=\"Close icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon\" width=\"16px\"\u003e next to the domain. To delete an individual cookie, select \u003cimg alt=\"Close icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon\" width=\"16px\"\u003e next to the cookie. To remove all cookies and domains from the Postman cookie jar, select **Clear All Cookies**. ## Send cookies with a request When you make a request to a domain you have added a cookie to, the cookie automatically appears in your request **Headers** tab. If the cookie isn't visible, select **hidden** to show autogenerated headers. ![Cookie header](https://assets.postman.com/postman-docs/v11/autogenerated-cookie-header-v11-b.jpg) You can't override cookie headers directly in the **Headers** tab. Edit the cookie in the cookie manager, or delete the cookie and set your request headers manually. You can add cookies in the cookie manager and the **Headers** tab, and Postman will merge the cookies before sending the request. ## Script with cookies You can write scripts that create, get, and delete cookies, giving you more control over your cookies. Use the `pm.cookies` object to access cookies associated with the request. Use the `pm.cookies.jar()` methods to create, get, and delete cookies for a specific domain. To access cookies for specific domains using the `pm.cookies.jar()` methods, you must first [add domains to the allowlist](#access-cookies-in-scripts). Learn more about [writing scripts that create, get, and delete cookies](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-cookies/). ### Access cookies in scripts When you add a domain to the allowlist, cookies for that domain can be accessed in scripts using the `pm.cookies.jar()` methods. To add a domain to the allowlist, do the following: 1. In the **Cookies** window, select **Domains Allowlist**. 1. Select **Add a domain to the Allowlist**. 1. Enter the allowed domain. If you include anything other than the domain name, such as a protocol, you won't be able to access cookies for that domain. 1. Select **Add**. To remove a domain from the allowlist, select \u003cimg alt=\"Close icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon\" width=\"16px\"\u003e next to the domain. ![Manage cookies domains allowlist](https://assets.postman.com/postman-docs/v11/domains-allowlist-cookies-v11.jpg) ## Sync cookies Postman can capture cookies for a browser or client application using the [Postman proxy](/docs/sending-requests/capturing-request-data/capture-with-proxy/) or [Postman Interceptor](/docs/sending-requests/capturing-request-data/interceptor/). For the domains you select, captured cookies are continuously synced with the Postman cookie jar. This enables you to use any authentication sessions in your browser or client application to make API calls in Postman. Learn more about [capturing cookies with the Postman proxy or Postman Interceptor](/docs/sending-requests/capturing-request-data/syncing-cookies/). ## Feature availability The following features require the Postman desktop app: * **Open Postman Vault from public workspaces** - You must use the Postman desktop app to open your Postman Vault from a [public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/), and reference vault secrets in a public workspace. If you're using the Postman web app, you must add new vault secrets to your Postman Vault if you're opening it from a public workspace. * **Create and manage Postman Vault integrations** ([Enterprise teams only](https://www.postman.com/pricing/)) - You can create a new integration. To learn more, see [Create custom properties for Stripe](#create-custom-properties-for-stripe). * **Create Organization Teams** - You can create a Team and invite other Team Members to it. For more information, see [Creating organization teams and workspaces](/docs/administration/organization/create/). * **Manage team members** - You can add, remove, and manage team members. For more information, see [Team members](/docs/administration/managing-your-team/team-members/overview/). * **Manage team resources** - You can add, remove, and manage team resources. For more information, see [Team resources](/docs/administration/managing-your-team/manage-team-workspaces/). * **Manage product access** - You can add, remove, and manage product access. For more information, see [Team product access](/docs/administration/managing-your-team/manage-team-product-access/). * **Manage security** - You can manage security settings. For more information, see [Security](/docs/administration/managing-your-team/overview/#secure-your-postman-team). ## Troubleshoot vault secrets Vault secrets can be empty or unresolved in your HTTP requests. An *empty vault* secret is a vault secret that doesn't have a value but is referenced in your request. An empty vault secret may or may not exist in your Postman Vault. An *unresolved vault secret* is a vault secret that exists in your Postman Vault but the value can't be accessed from your request. A vault secret in a cloud vault may be empty if the cloud vault's name was updated, but references to the vault secret use the previous cloud vault name. To fix this, update references to the vault secret with the correct cloud vault name. To configure HubSpot to process data from Stripe, create new properties in HubSpot based on the flows you plan to run. ### Add new Stripe customers to HubSpot To configure HubSpot to process data from Stripe about new customers, do the following: 1. In HubSpot, navigate to **Settings > Properties**. 2. Select **Contact properties > Create property**. 3. Create the following custom property: * `stripe_id` * `stripe_customer_id` ### Add new Stripe subscriptions to HubSpot contacts list To configure HubSpot to process data from Stripe about new subscriptions, do the following: 1. In HubSpot, navigate to **Settings > Properties**. 2. Select **Contact properties > Create property**. 3. Create the following custom property: * `stripe_id` * `stripe_customer_id` * `stripe_currency` * `stripe_period_end` * `stripe_period_start` * `stripe_total` * `stripe_customer_email` ### Create or update HubSpot contacts for new Stripe subscriptions To configure HubSpot to process data from Stripe about new subscriptions, do the following: 1. In HubSpot, navigate to **Settings > Properties**. 2. Select **Contact properties > Create property**. 3. Create the following custom property: * `stripe_id` ### Create or update HubSpot contacts with new Stripe payments To configure HubSpot to process data from Stripe about new payments, do the following: 1. In HubSpot, navigate to **Settings > Properties**. 2. Select **Contact properties > Create property**. 3. Create the following custom properties: * `stripe_id` * `stripe_customer_id` * `stripe_currency` * `stripe_amount` * `stripe_customer_email` ## Next steps After you've completed your Stripe configuration, you can return to the flow template or set up authorization for another integration in Postman. * [Set up HubSpot authorization for Postman Flows](/docs/postman-flows/templates/hubspot-setup/) * [Set up Mailchimp authorization for Postman Flows](/docs/postman-flows/templates/mailchimp-setup/) * [Set up Notion authorization for Postman Flows](/docs/postman-flows/templates/notion-setup/) * [Set up Slack authorization for Postman Flows](/docs/postman-flows/templates/slack-setup/) * [Set up Stripe authorization for Postman Flows](/docs/postman-flows/templates/stripe-setup/) --- # create-collections Create collections of API requests in Postman ============================================= Create a Postman Collection to save and share your favorite requests, to group requests you use for testing an API, or to document your API. You can create a new collection from scratch, or jump-start your collection with a template. Once created, you can customize your collection by adding a name and description. You can also specify authorization details and add scripts and variables. ## Create a new collection To create a collection, you must be [signed in to your Postman account](/docs/getting-started/first-steps/sign-up-for-postman/). You can create a new collection in the following ways: * Click **Collections** in the sidebar, then select **+ \u003e Blank collection**. * Click **New** in the sidebar, then click **Collection**. * In an empty workspace, click **Create Collection**. * You can also [create a collection from a template](#create-a-collection-from-a-template). Once you've created a new collection, you can [add API requests](/docs/collections/use-collections/add-requests-to-collections/) to it. You can also [name and configure your collection](#configure-a-collection). ![Create new collection](https://assets.postman.com/postman-docs/v11/new-collection-v11-6a.jpg) ## Create a collection from a template Not sure how to get started with your collection? Instead of creating a collection from scratch, you can use a template with predefined content. Postman has templates designed for integration testing, API documentation, conditional workflows, data visualization, and more. To create a collection from a template, do the following: 1. Click **Collections** in the sidebar, then select **+ \u003e Collection template**. 2. Select a recommended template. You can also search for a template, or browse templates by role or use case. 3. Review the information about the template, and when ready click **Use template**. You can also apply a template to an existing, empty collection. In the collection's overview, select a template or click **More templates**. You can't apply a template to a collection that already contains items. ## Configure a collection To customize and configure your new collection, do any of the following: * Click the collection name in the workbench to rename your collection. You can also select a collection in the sidebar and press the **Enter** or **Return** key to rename it. * You can add a [description](/docs/publishing-your-api/authoring-your-documentation/) for your collection in the **Overview** tab. The description also appears in the collection's documentation. * Click **Authorization** to configure [authorization details](/docs/sending-requests/authorization/specifying-authorization-details/) for all requests in the collection. * Select **Scripts \u003e Pre-request** to add a [pre-request script](/docs/tests-and-scripts/write-scripts/pre-request-scripts/) for your collection. The script will run before each request in the collection is sent. * Select **Scripts \u003e Post-response** to add a [post-response script](/docs/tests-and-scripts/write-scripts/test-scripts/) for your collection. The script will run after each request in the collection is sent. * Click **Variables** to define [collection variables](/docs/sending-requests/variables/variables/). Collection variables are reusable values you can use across all requests and documentation in a collection. Double-click a collection in the sidebar to persist its tab as you navigate the Postman app. ![Edit collection details](https://assets.postman.com/postman-docs/v11/collection-details-v11-68.png) Turn on autosave to automatically save your changes to requests. Learn more about [autosave](/docs/getting-started/installation/settings/#application). ## Postman Vault integrations Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team \u003e Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, --- # create-issue Create a Jira issue from Postman =============================== Once you [connect your Jira account to your Postman account](/docs/integrations/available-integrations/jira/connect/), you can create a new Jira issue from an HTTP collection, collection run, or response in Postman. You can also link to an existing issue. With Jira and Postman, you can see the status of all open issues, track your project's status, and assess your API's performance, all from Postman. ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 1: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 2: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 3: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Link to an existing Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can link to an existing Jira issue from Postman. To link to an existing Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 4: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 5: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 6: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Under **Select option**, select **Connect existing issue**. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select an issue. To search for an issue, start typing its name. You can also paste a link to an issue. 1. (Optional) Edit the comment. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Click **Connect Issue**. Postman links your existing Jira issue to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection and collection runs](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 7: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 8: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 9: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 10: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 11: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 12: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 13: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 14: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 15: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 16: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 17: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 18: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 19: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 20: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 21: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 22: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 23: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 24: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 25: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 26: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 27: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 28: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 29: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 30: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 31: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 32: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 33: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 34: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 35: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 36: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira issue from a collection, collection run, or response If there's an issue with your HTTP collection, [collection run](/docs/collections/running-collections/intro-to-collection-runs/), or one of your HTTP responses, you can create a new Jira issue from Postman. To create a Jira issue from a collection, collection run, or response, do the following: 1. Open an HTTP collection or request. Then, open the collection's known issues, run the collection, or send the request: - To open the collection's known issues, under **Known issues**, click the number of issues. - To run the collection, click ![Image 37: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**, set up the run, and run it. To learn more, see [Test your API using the Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). - To send the request, click **Send**. 1. Open the Jira form: - From a collection's known issues, click ![Image 38: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New**. Postman prompts you to create a new issue or link to an existing one. - From the collection run or response pane, click ![Image 39: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, click **Add to Jira Cloud**. Postman prompts you to create a new issue or link to an existing one. 1. Select a Jira site and project. To search for a project, start typing its name. 1. Select a work type. Postman displays any required and optional fields. 1. Edit the summary and (optional) description. 1. (Optional) If you sent a request, choose to include the response in the issue. 1. Select an assignee. To search for an assignee, start typing their name. 1. Complete any required fields. (Optional) Then, complete any optional fields. To see the optional fields, click **‌Show optional fields**. 1. Click **Create Issue**. Postman creates a new Jira issue for you and links it to your collection, collection run, or response. When you view your issue’s description in Jira, you’ll see a link to your collection, collection run, or response in Postman. You can also [view all issues linked to your request](/docs/integrations/available-integrations/jira/view-issues/#view-your-requests-jira-issues) and [all issues linked to your collection](/docs/integrations/available-integrations/jira/view-issues/#view-your-collections-jira-issues). ## Create a Jira --- # create-requests Create and send API requests in Postman --------------------------------------- You can use the Postman API client to connect to APIs you're building, testing, or integrating with. Build and send API requests with parameters, body data, and headers. Save your requests in collections so you can collaborate on them with your team or use them in automated testing. ## Build API requests in Postman Use Postman to [create and send API requests](/docs/sending-requests/create-requests/request-basics/) using HTTP or other common protocols such GraphQL, gRPC, and WebSocket. You can [send parameters and body data](/docs/sending-requests/create-requests/parameters/) with your requests, and [send request headers](/docs/sending-requests/create-requests/headers/), as required by your API. You can also [configure custom settings for each request](/docs/sending-requests/create-requests/request-settings/). ## Upload test data to your team Postman enables you to share your test data with others on your Postman team. You can [upload data files to your team](/docs/sending-requests/create-requests/test-data/), and anyone on your team can use the uploaded files as form data or raw body data when sending requests in Postman. ## Organize requests with Postman Collections You can [save and organize your API requests in collections](/docs/sending-requests/create-requests/intro-to-collections/) so you can use them over and over. Use collections to collaborate with your team, generate API tests and documentation, and automate request sending. ## Generate code snippets from requests Postman can help you integrate your front-end application with your API. Choose a supported language–like Postman CLI, C#, JavaScript, and NodeJS–and [generate a code snippet from a request](/docs/sending-requests/create-requests/generate-code-snippets/). You can use the snippet in your app to make calls to your API. ## Use vault secrets You can reference vault secrets stored in your local vault or a cloud vault in your HTTP collections and requests from the **URL builder**, the **Params** tab, the **Authorization** tab, the **Headers** tab, and the **Body** tab. You can use the Collection Runner to [manually run collections](/docs/collections/running-collections/intro-to-collection-runs/) that reference vault secrets. Scheduled collection runs, monitors, the Postman CLI, and Newman don't support vault secrets. ## Postman Vault integrations Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ## Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ## Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ## Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 5. Click **Next**. 6. Select the checkboxes for the following scopes, based on the HubSpot events you want the flow to access: * `chat:write` * `channels:read` * `groups:read` * `channels:join` * `im:read` * `incoming-webhook` * `mpim:read` 7. Click **Create app**. 8. After your app is created, select the app and navigate to **Auth**. 9. Select **Show token** to reveal your app's access token. Select **Copy**, and then save it as a variable in your Postman environment named `Azure_Access-Token`. ## Create a collection from the Azure API Gateway app You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To create a collection from an imported API, do the following: 1. After setting up the connection, you can create a new collection. 2. Click **Collections**, then select **Create from Azure**. 3. In the **Create a new collection from API gateway** popup window, enter the following information: * Select an API from the gateway. * Select the stage on which the API is deployed. * Create an environment (optional). This creates a new environment on Postman for the API variables from the gateway. 4. Click **Create collection**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. --- # create-teams Create a team in Postman ======================== On a Postman free plan, teams of up to three can work together at no cost. To collaborate with more team members, features, and increased usage limits, see [Plans and Pricing](https://www.postman.com/pricing/). Create a team in Postman to collaborate with others in your organization. You can create a team [during Postman onboarding](/docs/getting-started/first-steps/sign-up-for-postman/) or create new teams after onboarding. You can choose to keep workspaces in your Postman account separate from the teams you join. You can be a member of up to ten Postman teams, regardless of the [plan type](https://www.postman.com/pricing/). If an Enterprise team within your organization implements [domain capture](/docs/administration/domain-verification-and-capture/domain-capture-overview/), you won't be able to remain on or join extra Postman teams with your captured accounts. ## Create new teams To create new teams, do the following: 1. Click ![Image 1: Down Large icon](https://assets.postman.com/postman-docs/aether-icons/direction-down-large.svg#icon) next to **Team** (if you're on a paid plan) or **Upgrade** (if you're on a free plan), then click **Create team** or **Create Free team**, respectively. 2. Provide a team name and, optionally, specify the type of work your team will be working on. 3. Click **Continue**. 4. (Optional) Invite collaborators to your team by email or by adding people from a contacts file. 5. Click **Create Team**. You can edit your URL and logo, and decide if you want to turn on team discovery in [Team Settings](/docs/administration/managing-your-team/team-settings/). On Postman's [free plan](https://www.postman.com/pricing/), teams of up to three can work together at no cost. If you want to collaborate with more team members, features, and increased usage limits, you can [upgrade](/docs/billing/billing/#changing-your-plan) to a paid plan. To do so, click **Upgrade** in the upper-right corner. If you have an account and create a Postman team through the flow mentioned above, you can choose to transfer your workspaces and the associated data to the team or keep them separate. Your workspaces and data may transfer to your team automatically in some situations. See [Join a team](/docs/collaborating-in-postman/use-teams/#join-a-team) for details. When you leave a team, your workspaces within the team and their data will remain with the team and no longer be available to you in some situations. See [Leave a team](/docs/collaborating-in-postman/use-teams/#leave-a-team) for details. For more information on setting up Postman within your organization, check out the [onboarding checklist](/docs/administration/onboarding-checklist/). --- # The Create with AI block The **Create with AI** block is a [beta feature](https://www.postman.com/legal/terms/). ![Create AI block](https://assets.postman.com/postman-docs/v10/create-with-ai-block-v10.jpg) The **Create with AI** block uses artificial intelligence (AI) models to generate text, images, and JSON data based on your plain-language prompts. For example, you could enter a prompt like "Create a profile picture for a random person" or "Write a welcome email for a new employee at Postman". You can assign another block's output to the **Create with AI** block's built-in variable, or [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) data blocks. You can then reference the variable or data block in your prompt using curly braces. To learn how, see [Setup](#setup). The number of credits a **Create with AI** block consumes any given time that it runs depends on which model it's using. To learn more, see [How Flow modules and actions consume credits](/docs/billing/flows-usage/#how-flow-modules-and-actions-consume-credits). ## Input Connect another block's output port to the **Create with AI** block's single input port to assign incoming data to a variable. Select the variable's name to edit it. Select ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks** to [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) a data block into the **Create with AI** block. You can then assign a value to the data block and reference it in your prompt with curly braces like `{{this}}`. ## Output The output port sends the data that the AI model creates. The symbol next to this output port changes depending on the type of data selected. ## Setup You can set up the **Create with AI** block to generate text, images, or JSON. Select the type of content you want from the dropdown list next to the block's title. To let the block decide the type of content you want based on your prompt, select **Smart** from the dropdown list. Click the text box to enter a prompt in plain language. Click **Run** to see how the block handles your prompt and if it needs to be reworded. To insert a variable data block into your **Create with AI** block, click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks**. For example, you could insert a **String** block, name the variable `animal`, and reference it in a prompt like this: `Create an image of {{animal}}`. The **Create with AI** block generates an image of whatever animal is assigned to the variable `animal`. You can change an inserted block to a different data block by clicking the inserted block's icon and choosing a block from the dropdown list. ### Use Mustache syntax in AI prompts The **Create with AI** block supports [Mustache](https://mustache.github.io/mustache.5.html) syntax. You can use Mustache to dynamically format prompts, iterate over arrays, conditionally display text, and more. If a referenced variable in your AI prompt contains an object, Mustache syntax in the **Create with AI** block returns the full JSON representation of the object, including field names, rather than `[object Object]`. ### Change the AI model To change the AI model and adjust its settings, do the following: 1. Click the **Create with AI** block, then click ![Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Additional Settings**. 2. Click ![Agent Mode icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-postbot-stroke.svg#icon) **AI Model**, then select a model from the list. 3. (Optional) Click **Predictability** or **Creativity** to adjust their settings for the selected AI model. You can use the slider to set them higher or lower. A higher predictability value increases the chances of results repeating under the same conditions. A higher creativity value returns results with more variety. ## Example To see the **Create with AI** block in an example flow, check out [Flow Snippets: Create with AI](https://www.postman.com/postman/flows-snippets/flow/6841fce881d05a003f60123b). ## Related blocks You can insert a number of blocks into the **Create with AI** block to process their data including the [**String**](/docs/postman-flows/reference/blocks/string/), [**Bool**](/docs/postman-flows/reference/blocks/bool/), [**Number**](/docs/postman-flows/reference/blocks/number/), [**Null**](/docs/postman-flows/reference/blocks/null/), [**Select**](/docs/postman-flows/reference/blocks/select/), [**Now**](/docs/postman-flows/reference/blocks/now/), [**Date**](/docs/postman-flows/reference/blocks/date/), [**Date \u0026 Time**](/docs/postman-flows/reference/blocks/date-and-time/), and [**Get Variable**](/docs/postman-flows/reference/blocks/get-variable/) blocks. --- # create-workspaces Create a workspace in Postman ============================ When you first sign in to Postman, an [internal workspace](/docs/collaborating-in-postman/using-workspaces/overview/) is automatically created for you. You can create new workspaces using a blank workspace or use a template suitable for the work you and your team are doing. ## Create a new workspace To create a new workspace, do the following: 1. Select **Workspaces** in the header, then click **Create Workspace**. ![Start a new workspace](https://assets.postman.com/postman-docs/v11/create-workspace-from-dropdown-v11.74.png) 2. You can select a [workspace template](#apply-a-template-to-a-workspace) like the API development template, the API testing template, and others to help you set up a new workspace. Select a workspace template to populate the workspace with helpful information and sample collections and environments, or select **Blank workspace** to create an empty workspace. Then click **Next**. ![Apply a template to a new workspace](https://assets.postman.com/postman-docs/v11/create-workspace-templates-v11.74.png) 3. Enter a **Name** for your workspace. 4. Select the team for your workspace. ![](https://assets.postman.com/postman-docs/v11/create-workspace-v11.74.png) 5. Select an **Internal**, **Partner**, or **Public** workspace type. Learn more about [workspace types](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types). ![Create a new workspace](https://assets.postman.com/postman-docs/v11/create-workspace-v11.74.png) ([Enterprise plans only](https://www.postman.com/pricing/)) If your [team is restricting creation of internal workspaces with team access](/docs/administration/managing-your-team/manage-team-workspaces/), users who don't have permission can raise a request to create an internal workspace with team access, which goes for approval to [users who have access to approve such requests](/docs/administration/roles-and-permissions/#team-roles). 6. Select who has access to your workspace: everyone in your organization, your team, or only you and the people you invite. If you choose to create a public workspace, and you don't have an admin role, you'll be prompted to add a note for the approval of this request. 7. Select **Create** and Postman will open your new workspace. You can add elements to the workspace. Select **Invite** in the Postman header to add other users to the workspace. To create a new workspace, you can also click **New** in the sidebar, then select **Workspace** and follow the same steps. ![Create a new workspace from the sidebar](https://assets.postman.com/postman-docs/v11/create-new-workspace-v11.74.png) You can also create a new workspace in the [Workspaces dashboard](https://app.getpostman.com/dashboard). Select **Create Workspace** and follow the same steps. ![Create new workspace dashboard](https://assets.postman.com/postman-docs/v11/create-new-workspace-dashboard-v11.74.png) ## Apply a template to a workspace If you didn't use a template to create a workspace, you can apply it to an existing workspace. Workspace templates are available for a variety of common use cases, including API demos, engineering onboarding, and API testing. When you apply a workspace template, it populates the workspace description with an introduction and information to help you get started. Each workspace template also includes sample collections and environments that you can use and change as needed. To use a template, [create a new workspace](#create-a-new-workspace) or open a newly created workspace. To use a template in a newly created blank workspace, do the following: 1. In the workspace overview, select **Explore workspace templates**. 2. Select a template from the list in the sidebar, then select **Apply Template**. You can also enhance your workspace with other templates. Go to **Collections** in the sidebar, then select --- # create Create an AI request block for your flow ======================================= You use [**AI Request**](/docs/postman-flows/reference/blocks/ai-request/) blocks to interact with AI models, which can help you evaluate different models, add AI to your workflows, prototype AI agents, and much more. You can add **AI Request** blocks to [flow modules](/docs/postman-flows/get-started/build-your-first-flow/) and [actions](/docs/postman-flows/build-flows/structure/actions/). ## Create a new flow module You can use an existing flow module or create a new one. If you choose to use an existing flow module, skip to [Add a new AI request block](#add-a-new-ai-request-block). To create a new flow module, do the following: 1. Choose an existing workspace or [create a new one](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). 1. In the upper left corner, click **New** \> ![Image 1: Flow icon](https://assets.postman.com/postman-docs/aether-icons/entity-flow-stroke.svg#icon) **Flow**. 1. In the sidebar, hover over your new flow module and click ![Image 2: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**, then select **Rename** from the dropdown list. 1. Rename your new flow module. 1. Press the **Return** or **Enter** key. ## Add a new AI request block To add a new **AI request** block, do the following: 1. In the canvas toolbar, click ![Image 3: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Block**. 1. Select ![Image 4: Magic icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-magic-stroke.svg#icon) **AI Request**. You can also search for the block by entering "AI Request" in the search box. 1. Move your cursor to the location on the canvas where you want to place your new block, and click. ## Set up your new AI request block To set up your new **AI request** block, do the following: 1. Click **Find or create new request** to open a list of your collections that contain AI requests. 1. Select an AI request. If you want to search for the request, enter your search term in the search box. 1. If you want to create a new AI request, click ![Image 5: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create a new request** (at the end of the list) to open the request editor. For complete instructions, see [Create a new AI request](/docs/postman-ai/ai-requests/create/). ## Run the flow module From the canvas toolbar, click ![Image 6: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. Your new **AI request** block is ready to use to [interact with an AI model](/docs/postman-ai/ai-request-blocks/interact/). --- # creating-run-button Create a **Run in Postman** button to instantly bring your Postman collections into your user's environment. The **Run in Postman** button enables users to fork collections. You can embed the button in your website or a README to enable developers to interact with your API. For example, you can click the following **Run in Postman** button to fork the Postman API collection. ![Run in Postman](https://run.pstmn.io/button.svg) You can create the **Run in Postman** button from API specification formats like OpenAPI and RAML. First, convert the file to a collection by [importing it into Postman](/docs/getting-started/importing-and-exporting/importing-data/), or by generating a collection from your API in [the API Builder](/docs/design-apis/api-builder/develop-apis/adding-api-elements/#generate-a-new-collection-from-your-api-definition) or [Spec Hub](/docs/design-apis/specifications/generate-collections/). ## Create a Run in Postman button You can create a **Run in Postman** button for any of your public collections from the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). Then you can embed the code where you'd like the button to display for your users. To create a **Run in Postman** button, the collection must only have HTTP requests. The **Run in Postman** button isn't available for other types of protocols. Your collection must be in a public workspace. If your collection isn't in a public workspace, [change the workspace visibility to public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/#convert-an-existing-workspace-to-a-public-workspace) or [move the collection](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#move-elements-to-workspaces) to a public workspace. To create a **Run in Postman** button, do the following: 1. Access the [Postman API Network](https://www.postman.com/explore/). If you're on a paid plan, you can click **API Network** in the Postman header, then select **View all public APIs**. 2. Click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create New** on the left and select ![Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run in Postman button**. 3. Search for and select a public collection you want to share. - To replace the collection, click **Choose a different collection**. 4. (Optional) Select an environment. 5. Click **Next**. 6. Choose an embed code format that's HTML or Markdown friendly: - **HTML friendly** - This embed code uses JavaScript, HTML, and CSS, so you can customize the button for a website. You can [customize](/docs/publishing-your-api/run-in-postman/customize-run-button/) the embed code to dynamically create and update environments and add environment variables to a user's workspace. - **Markdown friendly** - This embed code uses Markdown, so you can display it in a README, blog, or other Markdown document. 7. Click ![Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy Code**. ![Create a Run in Postman button modal](https://assets.postman.com/postman-docs/v11/share-collection-run-in-postman-pan-v11.62.png) 8. Embed the code where you'd like the button to display, such as your organization's public API documentation. - You can also create a **Run in Postman** button from a collection. Click **Collections** in the sidebar of a public workspace, select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions > Share** next to the collection you want to share. Then, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** and select **Run in Postman**. 9. ## Sample code snippets for the Run in Postman button The embed code in Markdown or HTML format includes your collection's ID and URL. In the examples below, `:collection_id` is a placeholder for the ID and `:collection_url` is a placeholder for the URL. If you chose to include an environment in your button, the code will also have the `environment` parameter. The following is an example of code to embed in Markdown format: ```markdown [center class="width: 128px; margin: auto;"] [img src="https://run.pstmn.io/button.svg" alt="Run In Postman" style="width: 128px; height: 32px;" role="img"\]](https://god.gw.postman.com/run-collection/:collection_id?action=collection%2Ffork&source=rip_markdown&collection-url=entityId=12959542-c8142d51-e97c-46b6-bd77-52bb66712c9a&entityType=collection&workspaceId=405e0480-49cf-463b-8052-6c0d05a8e8f3) [/center] ``` The following is an example of code to embed in HTML format: ```html
``` ## Use a Run in Postman button Click the **Run in Postman** button to open the page where you can fork the collection to your workspace. [Forking the collection](/docs/collaborating-in-postman/using-version-control/forking-elements/) into your workspace will enable you to contribute to the source collection using pull requests. You can also view the collection in a public workspace if you like and even import a copy of the collection using the links present on the screen. All collections shared with the new **Run in Postman** buttons come with [fork counts](/docs/collaborating-in-postman/using-version-control/forking-elements/#view-fork-information), that help you and your consumers understand how developers use the API. ![Fork collection for Run in Postman](https://assets.postman.com/postman-docs/fork-collection-for-run-in-postman.jpg) Live **Run in Postman** buttons are automatically updated with changes in the original collection, so your consumers always get the most recent version of your collection without publishers having to manually update the collection's link. --- # Work with API definitions in the Postman API Builder You create the structure of your API using the _API definition_. The API definition can consist of one or multiple files. If your API doesn't have a definition, you can add an example definition, import a definition, or add a definition from a connected repository. ## Supported API definition formats Postman supports the following API definition formats: * OpenAPI versions 1.0, 2.0, 3.0, and 3.1 * RAML 0.8 and 1.0 * protobuf (protocol buffer) 2.0 and 3.0 * GraphQL * WSDL 1.0 and 2.0 OpenAPI definitions can be JSON or YAML. RAML definitions must be YAML. Protobuf definitions are `.proto` files. GraphQL definitions can be JSON or GraphQL SDL. WSDL definitions must be XML. ## Add an example API definition If your API doesn't have a definition, you can add an example definition that you can edit. 1. Click **APIs** in the sidebar and select an API. 2. Next to the API, click ![Image 1: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then select **Add definition > Author from scratch**. You can also select **create** under the API. 3. Select a definition type from the **Definition type** menu, then select a format from the **Definition format** menu. 4. To start with a sample definition, click **Use a boilerplate**. 5. Click **Create Definition**. ## Import an API definition You can import a file into your API to define your API. 1. Click **APIs** in the sidebar and select an API to expand it. 2. Next to the API, click ![Image 2: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then select **Add definition > Import files**. You can also select **Import** under the API. 3. Select or drag the file you want to import. You can also import an API from a folder, a link, a code repository, or an API gateway. Learn more about [importing an API](/docs/design-apis/api-builder/importing-an-api/). ## Add an API definition from a connected repository If your API is [connected to a Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/#connecting-to-a-remote-git-repository), you can select a definition file in your repository and add it to your API. 1. Click **APIs** in the sidebar and select an API to expand it. 2. Next to the API, click ![Image 3: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then select **Add definition > Add from connected repository**. 3. Enter the file path (in the repository) of the definition file you want to add and click **Select**. ![Image 4: Selecting a definition file](https://assets.postman.com/postman-docs/v11/api-builder-select-definition-file-v11.jpg) 4. Click **Add Files**. The definition files you selected are added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the definition files and automatically adds them to your API. ## Edit an API definition file To edit an API definition, click an API to expand it, then click **Definition**. Click the API's definition file to open it for editing. You can also edit your definition from your API's overview. Under **Definition**, click **View files**. The left pane of the editor displays an outline of your API definition. When you first open the editor, the top level nodes are expanded, and you can click a node to expand or collapse it. Select an element in the outline to jump to it in the editor. You can also click ![Image 5: Schema outline icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-schemaOutline-stroke.svg#icon) **(Hide/show) schema outline** to hide or show the outline. ![Image 6: Editing an API definition](https://assets.postman.com/postman-docs/v11/api-builder-edit-definition-v11.jpg) In the API definition editor, you can click a `#ref` component and press **⌘** or **Ctrl** to jump to the reference location. ![Image 7: Jumping to a reference location](https://assets.postman.com/postman-docs/v11/api-builder-ref-jump-v11.70.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the API definition. As you edit your API definition, Postman displays a [live preview of your API's documentation](#view-live-documentation) and [identifies syntax errors](#validate-a-component-file). Your teammates can't reuse components in a draft component file. [Publish a version of a component file](#version-and-publish-a-component-file) to allow your teammates to reference its components in their specifications. To learn more, see [Troubleshoot vault secrets](#troubleshoot-vault-secrets). ## Work with multi-file API definitions Your API definition can span multiple files and folders. This is called a _multi-file API definition_. Multi-file API definitions are supported in OpenAPI 2.0 and 3.0 APIs and protobuf 2.0 and 3.0 APIs. A multi-file API definition consists of the following components: * **API Definition** - The entire definition of the API, combining all files within it. * **Files** - One or more files that specify the API definition. * **Root file** - The top-level file that hosts the operations defined by the API. See below for more information on root files. * **Folders** - You can create folders within an API definition to organize files. You can also add folders within folders. Multi-file API definitions don't support the schema sync integration. Instead, use [API version control](/docs/design-apis/api-builder/versioning-an-api/overview/) to sync with a repository. ### About root files An API definition's root file can reference other files in the API definition. If you made a tree diagram of the relationships between all files in an API definition, the root file would be the file at the top of the tree. When you [create a new API definition](/docs/design-apis/api-builder/creating-an-api/) or [import an API](/docs/design-apis/api-builder/importing-an-api/), Postman determines the root file based on the references across the files. API definitions don't support references which are external links or present within a separate API. For OpenAPI 2.0 and 3.0 API definitions, Postman detects root files based on the content and references within files while importing or creating an API definition. You can't set a file as root for OpenAPI definitions. OpenAPI definitions can have one root file. If you delete the root file, Postman will recalculate the next candidate for the root file automatically. For protobuf API definitions, while importing the API, Postman detects all files which have service definitions present in them and marks one as the root. You can set another file as root if there's more than one candidate for root file. Click ![Image 8: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a `.proto` file in the sidebar and select **Mark as root**. ### Edit a multi-file API definition To edit a multi-file API definition, select an API in the sidebar to expand it, then select **Definition**. If your definition has folders, select a folder in the sidebar to expand it and see its contents. Select a file to open it for editing. ### Add files and folders You can add new files and folders to a multi-file API definition. In the sidebar, click ![Image 9: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to **Definition**, then select **Add file** or **Add folder**. If your API is [connected to a Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/#connecting-to-a-remote-git-repository), select **Add file > Create new** to add a new file. To add a new file or subfolder to a folder, click ![Image 10: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a folder, then select **Add file** or **Add folder**. You can rearrange files and folders by dragging them in the sidebar. You can also rename or delete a file or folder by clicking ![Image 11: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. When you add a file to a single-file OpenAPI 2.0 or 3.0 definition, or to a protobuf 2.0 or 3.0 definition, it's converted to a multi-file API definition. The existing definition file becomes the root file. ### Add files from a connected repository If your API is [connected to a Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/#connecting-to-a-remote-git-repository), you can add files from your repository. 1. Click **APIs** in the sidebar and select an API. 2. Click ![Image 12: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to **Definition** and select **Add file > Add from connected repository**. 3. Enter the file path (in the repository) of the definition file you want to add and click **Select**. You can select more than one file to add from the repository. ![Image 13: Selecting a definition file](https://assets.postman.com/postman-docs/v11/api-builder-select-files-from-git-v11.jpg) 4. Click **Add Files**. The definition files you selected are added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the definition files and automatically adds them to your API. The **Add file > Add from connected repository** option isn't available for Git integrations added using Postman v10.17 or earlier. Instead, add the definition files to the schema directory in the repository. Alternately, you can [remove the Git integration](/docs/design-apis/api-builder/versioning-an-api/using-cloud-git-repo/#disconnecting-a-cloud-hosted-repository) and then [reconnect your API to the Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/#connecting-to-a-remote-git-repository). ### Delete files and folders To delete a definition file or folder, click ![Image 14: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to the item and select **Delete**. Deleting a file or folder doesn't affect other elements added to the API, such as collections. You can restore a deleted definition file using the [**Changelog**](/docs/design-apis/api-builder/managing-apis/#use-the-changelog). Click ![Image 15: History icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-history-stroke.svg#icon) **Changelog** in the right sidebar, then click **Restore** below the definition file you want to restore. If you connect your API to a Git repository, the changelog is replaced by the **Source Control** pane. Learn more about [API version control](/docs/design-apis/api-builder/versioning-an-api/overview/). If your API is [connected to a Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/#connecting-to-a-remote-git-repository), you have the option to remove or delete a file. Click ![Image 16: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a file and select **Delete**, then choose an option: * Click **Delete File** to delete the file from your API and your repository. The file will be deleted from your repository when you push changes from Postman. * Click **Remove File** to remove the file from your API in Postman. The file won't be deleted from your repository. ![Image 17: Deleting a definition file](https://assets.postman.com/postman-docs/v11/api-builder-delete-file-v11.jpg) **About definition IDs.** When you add a definition to an API, Postman assigns a definition ID to the API. You can view the definition ID by opening an API and clicking ![Image 18: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) **Info** in the right sidebar. The definition ID acts as a container for all the definition files in the API. If you delete all the definition files, the definition ID itself isn't deleted. If you then add a new definition file, the definition ID remains the same as before. --- # Document a collection in Postman Postman automatically generates basic documentation for any collection you create. The documentation includes details about all of the requests in your collection, along with sample code in various client languages. Request details include the method, authorization type, URL, headers, request and response structures, and examples. In addition, the documentation displays all key-value pairs for request parameters, headers, and bodies. To make your documentation even more valuable to users, [add descriptions](/docs/publishing-your-api/authoring-your-documentation/#adding-descriptions-to-your-documentation) to the items in your collection. Any descriptions you add are automatically included in the documentation for your collection. ## Add descriptions to a collection Add descriptions to your collections (including [collections linked to an API](/docs/publishing-your-api/documenting-your-api/)) to enhance your documentation and add more detail. You can use the Postman editor to view how your content will look as you write it, or use standard Markdown syntax to write content. With either editor, you can format text, add links, and insert images and videos in your documentation. To add a description to a collection or folder, do the following: 1. Click **Collections** in the sidebar, and then select a collection or a folder. 2. Enter a description in the **Overview** tab. To learn more about using Postman's built-in editing tools, see [Write your docs](/docs/publishing-your-api/authoring-your-documentation/). 3. Click outside of the editor to save your new content. ![Documenting a collection](https://assets.postman.com/postman-docs/v11/documentation-overview-tab-v11.jpg) To add a description to a request, do the following: 1. Click **Collections** in the sidebar, and then select a request. 2. Click the documentation icon ![Documentation icon](https://assets.postman.com/postman-docs/documentation-icon-v8-10.jpg#icon) in the right sidebar. 3. Enter a description in the right sidebar. To learn more about using Postman's built-in editing tools, see [Write your docs](/docs/publishing-your-api/authoring-your-documentation/). 4. Click outside of the editor to save your new content. ![Documenting a request](https://assets.postman.com/postman-docs/v11/documentation-pane-v11-b.jpg) You can also edit descriptions when viewing the complete documentation for a collection. Select a collection in the sidebar, then click **View complete documentation** in the **Overview** tab. From here, you can add a description to any item in the collection. ## Document gRPC and WebSocket collections Collections with gRPC or WebSocket requests use a different format than collections with HTTP requests. You can view documentation and add descriptions for gRPC or WebSocket requests. You can also add a description on the collection's **Overview** tab, but you can't view or edit documentation for the full collection. Learn more about [documenting gRPC requests](/docs/sending-requests/grpc/grpc-request-interface/#the-right-sidebar) or [documenting WebSocket requests](/docs/sending-requests/websocket/document-websocket-requests/). ## Associate environments with documentation An [environment](/docs/sending-requests/variables/managing-environments/) is a set of related [variables](/docs/sending-requests/variables/variables/) you can use in Postman requests. You can also refer to variables when [writing descriptions](/docs/publishing-your-api/authoring-your-documentation/) in a collection. In each case, the shared value of the variable is automatically populated in the documentation. Anyone using your collection can view the variables in the documentation if the associated environment is also shared with them. For public documentation, you can select an environment during the [publishing process](/docs/publishing-your-api/publishing-your-docs/). Publishing an environment makes it available to anyone [viewing public documentation](/docs/publishing-your-api/viewing-documentation/). To use an environment variable in your documentation, do the following: 1. [Create a new environment](/docs/sending-requests/variables/managing-environments/) if one doesn't already exist. 2. Make the environment active by selecting it in the [environment dropdown list](/docs/sending-requests/variables/managing-environments/#switch-between-environments). 3. If needed, [add a new variable](/docs/sending-requests/variables/managing-environments/#add-environment-variables) to the environment. 4. Add a [reference to the variable](/docs/sending-requests/variables/variables/#using-variables) to requests or descriptions in your collection. ![Referencing a variable](https://assets.postman.com/postman-docs/v11/documentation-add-variable-v11-b.jpg) If someone imports a collection using the **Run in Postman** button from your documentation, they also import the environment and any associated variables. The shared values for variables are published in your documentation, so make sure they don't contain any sensitive data. ## Next steps After documenting a collection in Postman, you can edit and format the docs and publish them. * To learn more about documenting an API in Postman, see [Add API documentation in Postman](/docs/publishing-your-api/documenting-your-api/). * To learn more about editing and formatting your documentation, see [Write documentation in Postman](/docs/publishing-your-api/authoring-your-documentation/). * To learn how users can access your documentation, see [View documentation in Postman](/docs/publishing-your-api/viewing-documentation/). By default, your documentation is private, so you must share a collection with others before they can access it. * To make your documentation publicly available, see [Publish documentation in Postman](/docs/publishing-your-api/publishing-your-docs/). ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) See how to document an API with a collection template that's a boilerplate for documentation that you can customize and reuse. To try out this template, visit [API documentation](https://www.postman.com/templates/collections/api-documentation/). --- # Add API documentation in Postman You can view, create, and manage your API's documentation either with collections or the Postman API Builder. You can add detailed API documentation to a collection with types. This enables you to add more details to request parameters, headers, and bodies in an HTTP collection. With the API Builder, you can also add detailed documentation for any OpenAPI 2.0 or 3.0 definition. You can then generate a collection from the API or add a copy of an existing collection. The API documentation includes complete API, path, and operation information, such as authentication methods, parameters, request bodies, response bodies and headers, and examples. The documentation also includes information for various data models, such as required attributes, default values, minimum and maximum values, and other constraints. ## Add API documentation with collections Postman automatically creates [documentation for a collection](/docs/publishing-your-api/document-a-collection/) you create. With [types in collections](/docs/design-apis/collections/overview/), you can build out this documentation by designing your API with the Postman Collection format. You can add more details to request parameters, headers, and bodies in the collection, such as data type and possible values. Details you add appear in your collection's documentation. To get started, [add types to parameters and headers](/docs/design-apis/collections/add-properties-to-parameters-and-headers/). You can also [add types to body data](/docs/design-apis/collections/add-properties-to-body-data/) in your requests. To view the documentation for a collection with types, do the following: 1. Click **Collections** in the sidebar, then select a collection with types. 1. Click the collection's **Overview** tab and click **View complete documentation**. ![View documentation for a collection with types](https://assets.postman.com/postman-docs/v11/type-definition-view-docs-v11-12.jpg) ## Add API documentation with the API Builder If you are [designing an API in the API Builder](/docs/design-apis/api-builder/develop-apis/defining-an-api/) based on the OpenAPI 2.0 or 3.0 specification, Postman automatically creates documentation based on your API definition. With the API Builder, you can create documentation from a [new collection](#create-new-documentation-for-an-api) or an [existing collection](#add-existing-documentation-to-an-api). You can also [edit a collection's documentation](#edit-api-documentation) and [delete a collection and its documentation](#delete-api-documentation) if you no longer need it. To view the documentation for an OpenAPI 2.0 or 3.0 API from the Postman API Builder, do the following: 1. Click **APIs** in the sidebar and select an API. 1. On the API's overview, under **Definition**, click **View schema documentation**. ![Viewing schema documentation](https://assets.postman.com/postman-docs/v10/documentation-view-schema-docs-v10-16.jpg) You can also view schema documentation while editing your OpenAPI 2.0 or 3.0 definition. Postman displays a live preview of the documentation as you work on your API. Learn more about [previewing schema documentation](/docs/design-apis/api-builder/develop-apis/defining-an-api/#preview-schema-documentation). ## Create new documentation for an API To generate a new collection for API documentation from the Postman API Builder, do the following: 1. Click **APIs** in the sidebar and select an API. 1. On the API's overview, next to **Collections**, click \[img alt="Add icon" src="https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon" width="16px"\] **Add** and select **Generate from definition**. 1. Select the checkbox if you want Postman to suggest updates for the collection when the API definition changes. This checkbox is selected by default. Learn more about [keeping a collection in sync with an API](/docs/design-apis/api-builder/develop-apis/adding-api-elements/#keep-a-collection-in-sync-with-your-api). 1. Change any settings to customize the new collection. 1. Click **Generate Collection**. The new collection displays on your API's overview and under your API in the sidebar. To view documentation for the collection, select the collection and click **View complete documentation**. You can also [generate a collection from Spec Hub](/docs/design-apis/specifications/generate-collections/). Postman automatically creates a collection with folders, requests, and response examples based on the specification. ## Add existing documentation to an API Copy an existing collection with API documentation to an API. If you copy a [collection with types](/docs/design-apis/collections/overview/), types won't be copied to the new collection linked to the API. To use an existing collection for API documentation in the Postman API Builder, do the following: 1. Click **APIs** in the sidebar and select an API. 1. On the API's overview, next to **Collections**, click \[img alt="Add icon" src="https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon" width="16px"\] **Add** and select **Copy existing collection**. 1. Select an available collection and click **Copy Collection**. The copy of the collection displays on your API's overview and under your API in the sidebar. To view documentation for the collection, select the collection and click **View complete documentation**. When you add a collection, an independent copy of the collection is added to the API. The copy in the API will no longer be in sync with the original. If you move or delete an API, any collections contained in the API are moved or deleted with it. ## Edit API documentation You can add to your API documentation collections from the API Builder. To edit a documentation collection from the Postman API Builder, do the following: 1. Click **APIs** in the sidebar and select an API. 1. On the API's overview, select a collection and click **View full documentation**. 1. Enter a description for any item. To learn more about using Postman's built-in editing tools, see [Write your docs](/docs/publishing-your-api/authoring-your-documentation/). 1. Click outside of the editor to save your new content. Schema documentation can't be edited directly. Instead, [edit your API's definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/) and then click **Save**. Postman automatically updates the API docs to reflect the latest changes to your definition. ![Editing API documentation](https://assets.postman.com/postman-docs/v10/documentation-editing-api-docs-v10-16.jpg) ## Delete API documentation The process to delete a collection's documentation requires you to delete the collection. To delete a documentation collection from the Postman API Builder, do the following: 1. Click **APIs** in the sidebar and select an API. 1. Next to the API, click \[img alt="Options icon" src="https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon" width="16px" role="img"\] **View more actions**. Then click **Delete**. ## Next steps After adding documentation to an API in Postman, you can edit and format the docs. You can also publish your API, including the documentation. * To learn more about adding descriptions to a collection, including collections linked to an API, see [Document a collection in Postman](/docs/publishing-your-api/document-a-collection/). * To learn more about editing and formatting your documentation, see [Write documentation in Postman](/docs/publishing-your-api/authoring-your-documentation/). * To learn how users can access your documentation, see [View documentation in Postman](/docs/publishing-your-api/viewing-documentation/). By default, your documentation is private, so you must share an API with others before they can access it. * To learn how to publish your API in the Postman API Builder to make it available to consumers, see [Publish a version of your API for consumers in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/). --- # edit-a-specification Edit your API specification =========================== Edit your specification to update the structure and design of your API. [Navigate your specification](#navigate-your-specification) using the outline in the sidebar and [the command palette](#navigate-using-the-command-palette) to find and jump to specific sections. You can [add new sections using snippets](#add-new-sections-using-snippets) to add pre-formatted blocks that you can fill out. You can [generate a schema from a JSON request or response body](#generate-a-schema-from-a-json-body), and add the schema directly to your specification. You can also organize your OpenAPI 2.0, 3.0, or 3.1 specification into [multiple files and folders](#add-files-and-folders). As you edit your specification, Postman offers [autocomplete suggestions](#edit-your-specification-using-autocomplete) for properties and valid values. Postman identifies [syntax errors and API governance issues](/docs/design-apis/specifications/validate-a-specification/), and shows details so you can fix them. Postman also displays a [live preview of your API's documentation](/docs/design-apis/specifications/view-live-documentation/) and [identifies syntax errors](/docs/design-apis/specifications/validate-a-component-file). Your teammates can't reuse components in a draft component file. [Publish a version of a component file](#version-and-publish-a-component-file) to allow your teammates to reference its components in their specifications. ## Postman Vault integrations Integrate your Postman Vault with Postman Flows to enable you to: * Create Meeting * Update Meeting * Get Meeting * Get Meeting By ID * Delete Meeting * Add Meeting Registrant * Get Meeting Registrant * Delete Meeting Registrant * Get Recording By Meeting ID * Search Recording * Create Folder * Move Folder * Get Folder By ID * Search Folders * Delete Folder * Download File To connect your Postman Vault to a Postman Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Zoom** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Postman Vault. 6. Connect the **Request** block's output ports to the Zoom **Connector** block's input ports, based on the selected operation. 7. Connect the Zoom **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Azure API Gateway to Postman Flows To connect your Azure API Gateway to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Azure Gateway** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Azure Gateway. 6. Connect the **Request** block's output ports to the Azure Gateway **Connector** block's input ports, based on the selected operation. 7. Connect the Azure Gateway **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Amazon API Gateway to Postman Flows To connect your Amazon API Gateway to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Amazon API Gateway** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Amazon API Gateway. 6. Connect the **Request** block's output ports to the Amazon API Gateway **Connector** block's input ports, based on the selected operation. 7. Connect the Amazon API Gateway **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Google API Client to Postman Flows To connect your Google API Client to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Google API Client** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Google API Client. 6. Connect the **Request** block's output ports to the Google API Client **Connector** block's input ports, based on the selected operation. 7. Connect the Google API Client **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Microsoft Graph to Postman Flows To connect your Microsoft Graph to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Microsoft Graph** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Microsoft Graph. 6. Connect the **Request** block's output ports to the Microsoft Graph **Connector** block's input ports, based on the selected operation. 7. Connect the Microsoft Graph **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Microsoft Teams to Postman Flows To connect your Microsoft Teams to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Microsoft Teams** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Microsoft Teams. 6. Connect the **Request** block's output ports to the Microsoft Teams **Connector** block's input ports, based on the selected operation. 7. Connect the Microsoft Teams **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector** block's input ports, based on the selected operation. 7. Connect the Slack **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ## Connect your Slack to Postman Flows To connect your Slack to Postman Flows, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click the **Template** block and click \u003cimg alt=\"Delete icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon\" width=\"16px\"\u003e **Delete**. 3. Right-click the canvas and select **Slack** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Slack. 6. Connect the **Request** block's output ports to the Slack **Connector --- # The Evaluate block ![Evaluate block](https://assets.postman.com/postman-docs/v11/evaluate-block-v11.jpg) The **Evaluate** block is a powerful tool for manipulating and evaluating data. It's ideal for filtering data, conditionally running parts of your flow, and integrating complex logic. Using [TypeScript](/docs/postman-flows/typescript/typescript-overview/) scripts or [Flows Query Language](/docs/postman-flows/flows-query-language/introduction-to-fql/) (FQL) queries, you can set up the **Evaluate** block to process data and send the result. The **Evaluate** block has pre-defined snippets to help you create FQL queries. ## Input **variable** - Accepts data from another block's output port. ## Output **Result** - Sends the result of the script or query. ## Setup The **Evaluate** block processes data it receives from its input ports and inserted [data blocks](/docs/postman-flows/reference/overview-data-blocks/). When created, the **Evaluate** block has one input port. When you connect another block to this port, the **Evaluate** block inserts a **Select** block and assigns the selected value to a variable named **value1**. To rename the variable, click it and enter a new name. You can also change the inserted **Select** block to a different data block by clicking the ![Flows select icon](https://assets.postman.com/postman-docs/aether-icons/action-flowsSelect-stroke.svg#icon) **Select** block's icon and choosing a data block from the dropdown list. You can also insert more variable data blocks into the **Evaluate** block to process their data. For example, you could insert a **String** block into your **Evaluate** block, name the variable `string1`, and reference it in your query as `string1`. Click ![Add data blocks](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks** to insert a data block into your **Evaluate** block. The **Evaluate** block has a text box where you can enter TypeScript to create scripts or FQL to create queries. Click the dropdown list at the top of the block to set the text box to use TypeScript or FQL. Then click inside the text box and enter your code. When the text box is set to use FQL, you can click **Snippets** and choose from a list of common tasks. In a flow module or action, you can't modify environment variables, including by using scripts in **Evaluate** blocks. ## Example To see the **Evaluate** block in an example flow, check out [Flow Snippets: Evaluate](https://www.postman.com/postman/flows-snippets/flow/63bc960882ae416b9e6bc11f). ## Related blocks You can use the [**Condition**](/docs/postman-flows/reference/blocks/condition/) and [**If**](/docs/postman-flows/reference/blocks/if/) blocks instead, depending on your use case. You can insert the following blocks into the **Evaluate** block to process their data including the [**String**](/docs/postman-flows/reference/blocks/string/), [**Bool**](/docs/postman-flows/reference/blocks/bool/), [**Number**](/docs/postman-flows/reference/blocks/number/), [**Null**](/docs/postman-flows/reference/blocks/null/), [**Select**](/docs/postman-flows/reference/blocks/select/), [**Now**](/docs/postman-flows/reference/blocks/now/), [**Date**](/docs/postman-flows/reference/blocks/date/), [**Date \u0026 Time**](/docs/postman-flows/reference/blocks/date-and-time/), [**List**](/docs/postman-flows/reference/blocks/list/), [**Record**](/docs/postman-flows/reference/blocks/record/), and [**Get Variable**](/docs/postman-flows/reference/blocks/get-variable/) blocks. ## Related pages For tutorials that use the **Evaluate** block, see the following: * [Calculate the years since a milestone](/docs/postman-flows/tutorials/beginner/calculate-years-since-milestone/) * [Create a count-based loop with the Repeat block](/docs/postman-flows/tutorials/beginner/create-count-based-loop/) * [Create a dashboard using Postman Flows](/docs/postman-flows/tutorials/advanced/create-a-dashboard-in-flows/) * [Create a list-based loop with the For block](/docs/postman-flows/tutorials/beginner/create-list-based-loop/) * [Send information from one system to another using Postman Flows](/docs/postman-flows/tutorials/advanced/send-information-from-one-system-to-another/) ## Troubleshoot vault secrets You can reference vault secrets stored in your Postman Vault by adding a vault secret inside double curly braces (`{{vault:secret-name}}`) and appending the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` To reference a vault secret in your local instance of Postman, use the `vault:` prefix in the vault secret name. For example, if you copied the vault secret value from the Postman Vault and saved it as a variable in your Postman environment, you can use the following syntax: ```txt {{vault:your_variable_name}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret in a Postman workspace, you can use the following syntax: ```txt {{vault:your_workspace_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman collection. For example, if you wanted to reference a vault secret in a Postman collection, you can use the following syntax: ```txt {{vault:your_collection_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman environment. For example, if you wanted to reference a vault secret in a Postman environment, you can use the following syntax: ```txt {{vault:your_environment_name/postman-api-key}} ``` You can also use the `vault:` prefix in the vault secret name to reference a vault secret in a Postman workspace. For example, if you wanted to reference a vault secret --- # Create examples of request responses to illustrate API use cases Examples show your API endpoints in action and give more details on how requests and responses work. You can add an example to a request by saving a response, or you can create an example with a custom response to illustrate a specific use case. Once you've created examples, you can use them to set up a mock server or add more detail to your API documentation. ## Understanding examples In Postman, an example is a pairing made up of a _request_ and a related _response_. Each example includes a request part (method, URL, parameters, headers, and body) and a response part (status code, body, and headers). You add examples to requests in collections, and one request can have multiple examples. Having multiple examples for one request is useful for illustrating the different ways an endpoint can respond to a request. You might have examples that respond with different status codes (such as 200 or 404) or that return different data (or no data at all). Examples are useful in several ways. Developers and testers can refer to examples to better understand how an endpoint functions in different scenarios. Examples can also be used to [set up mock servers](/docs/design-apis/mock-apis/set-up-mock-servers/), so developers and testers can start [writing code](/docs/tests-and-scripts/write-scripts/test-scripts/) against your API, even before it's complete. In addition, you can include examples in your API's [public documentation](/docs/publishing-your-api/publishing-your-docs/) to help anyone in the world who uses your API. ## Add an example An example is always associated with a [request](/docs/sending-requests/create-requests/create-requests/) in a [collection](/docs/sending-requests/create-requests/intro-to-collections/), and a request can have more than one example. To add an example to a request, send the request and then save the response as an example. You can also manually add an example to a request and define a custom response. After adding an example using either method, you can edit it at any time to make changes. > For optimal Postman performance, example responses must be smaller than 5 MB. ### Save a response as an example When saving a [response](/docs/sending-requests/response-data/responses/) in Postman, you have the option to save it as an example. 1. Select **Collections** in the sidebar. 1. Open a request and select **Send**. 1. In the response pane, select ![Image 1: Example icon](https://assets.postman.com/postman-docs/aether-icons/entity-example-stroke.svg#icon) **Save Response**. ![Image 2: Save a response as an example](https://assets.postman.com/postman-docs/v11/examples-save-response-v11-42.jpg) > For [gRPC examples](/docs/sending-requests/grpc/using-grpc-examples/) with streaming methods, you must end the stream before saving the response/message stream as an example. ### Add a custom example With a custom example, you can define how both the [request](/docs/sending-requests/create-requests/create-requests/) and the [response](/docs/sending-requests/response-data/responses/) look, including the status code and response body. 1. Select **Collections** in the sidebar. 1. Select ![Image 3: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a request and then select **Add example**. 1. Enter a name for the example. 1. Edit the request part of the example. * Add any parameters or headers as needed. * Enter the request body and select a content type. 1. Edit the response part of the example. * Enter a **Status Code** (such as `200` or `404`). * Enter the response body and select a content type. * Add any headers as needed. 1. Select **Save** to save the example. ## Try an example Examples are stored in a collection with their associated requests. You can try an example by opening the example as a request in a new tab. 1. Select **Collections** in the sidebar. 1. Select a request, and then select an example to open it. 1. Select **Try** to open the example as a request in a new tab. The request will automatically send in the new tab. ![Image 4: Trying example](https://assets.postman.com/postman-docs/v11/sending-example-response-v11.jpg) 1. Review the request and response details. ![Image 5: Open example as a request](https://assets.postman.com/postman-docs/v11/sending-example-response-duplicate-request-v11-42.jpg) > The new request isn't automatically saved. The name of the example you're trying is next to the request's name in the workbench. Select the example's name to open it in a separate tab. ![Image 6: Select example name](https://assets.postman.com/postman-docs/v11/example-response-name-v11.jpg) 1. Optionally, you can select **Save** to save the new request to a new or existing collection in your workspace. 1. Choose a location to save the new request, and then select **Save**. ![Image 7: Save request](https://assets.postman.com/postman-docs/v10/sending-example-response-save-request-v10-22.jpg) ## Edit an example You can edit an example at any time to remove sensitive tokens, change the status code, or make any other adjustments. To edit an example, do the following: 1. Select **Collections** in the sidebar. 1. Select a request, and then select an example to open it. 1. Make any changes to the example request or response. 1. Select **Save** to save the example. To edit an example after trying it, do the following: 1. Select **Collections** in the sidebar. 1. Select a request, and then select an example to open it. 1. Select **Try** to open the example as a request in a new tab. ![Image 8: Trying example](https://assets.postman.com/postman-docs/v11/sending-example-response-v11.jpg) 1. Make any changes to the new request. 1. Select **Send**. 1. In the response pane, select ![Image 9: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** \> Update example. You will receive confirmation once the example is updated. ![Image 10: Updating example](https://assets.postman.com/postman-docs/v11/updating-example-response-v11.23.jpg) > The new request isn't automatically saved. 1. Optionally, you can select **Save** to save the new request to a new or existing collection in your workspace. 1. Choose a location to save the new request, and then select **Save**. ![Image 11: Save request](https://assets.postman.com/postman-docs/v10/sending-example-response-save-request-v10-22.jpg) ## Share an example You can share examples with collaborators by going to the example you want to share in the sidebar. Select ![Image 12: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to the example you want to share, then select **Share**. ![Image 13: Share example](https://assets.postman.com/postman-docs/v11/share-request-v11.23.jpg) For more details about sharing examples, see [Share your work in Postman](/docs/collaborating-in-postman/sharing/). ## Add comments to an example 1. Select ![Image 14: Comments icon](https://assets.postman.com/postman-docs/aether-icons/action-comments-stroke.svg#icon) **Comments** in the right sidebar and enter your comment. 1. (Optional) Select the **Watch collection** checkbox to be notified when there are changes to the collection that the example is in. 1. Select **Comment** to add your comment. You can learn more about [using comments to collaborate on examples](/docs/collaborating-in-postman/comments/). ## Duplicate an example Duplicate an example to add a new example using an existing example as a base. You can then edit the copied example to change the name, status code, or any other part of the request or response. 1. Select **Collections** in the sidebar. 1. Select ![Image 15: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to an example, and then select **Duplicate**. 1. Make any changes to the example request or response. 1. Select **Save** to save the example. ## Delete an example Deleting an example removes it from the collection and from the associated API documentation. Any mock servers you have set up can no longer use the example to return a response. 1. Select **Collections** in the sidebar. 1. Select the more actions icon ![Image 16: More actions icon](https://assets.postman.com/postman-docs/icon-more-actions-v9.jpg#icon) next to an example, and then select **Delete**. 1. Select **Delete** to confirm. ## Use examples in documentation Postman automatically [generates documentation](/docs/publishing-your-api/document-a-collection/) for every collection you create. The generated documentation [includes any examples](/docs/publishing-your-api/authoring-your-documentation/#including-examples) that have been added to the collection. If you edit an example, the documentation is automatically updated with your changes. ![Image 17: Examples in documentation](https://assets.postman.com/postman-docs/v11/documentation-including-examples-v11-1.jpg) Examples give more details and clarification for your API and help your team to work together on API development. Front-end developers, back-end developers, and testers can all work in parallel, using the examples in the documentation for guidance or to set up [mock servers](/docs/design-apis/mock-apis/set-up-mock-servers/). > You can [publish your documentation](/docs/publishing-your-api/publishing-your-docs/) to make your examples publicly available to anyone in the world. ## Next steps You can use examples to set up a mock server and enhance your documentation. * To learn how to use examples to set up a mock server, visit [Set up a Postman mock server](/docs/design-apis/mock-apis/set-up-mock-servers/). * To learn how to include examples in your API documentation, visit [Document a collection in Postman](/docs/publishing-your-api/document-a-collection/). --- # Export data from Postman You can export your Postman data, including collections, environments, global variables, and data dumps, as JSON files. You can import these files back into any Postman instance, share them with others, or use them with the [Postman CLI](/docs/postman-cli/postman-cli-overview/) or [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). ## Export collections 1. Click **Collections** in the sidebar. 2. Click ![Image 1: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a collection, then select **More > Export**. 3. (Optional) Invite teammates or click **Copy Collection Link** to share the collection. 4. Select the export format (**Collection v2** or **Collection v2.1**) for the collection. 5. Click **Export JSON** to download the generated JSON file. ## Export environments 1. Click **Environments** in the sidebar. 2. Click ![Image 2: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to an environment, then **Export**. The file will download automatically. ## Export data dumps You can export a bulk data dump of all your collections and environments in Postman. You can then import the data into any Postman instance. If you are on a team, only Team Admins and Super Admins can export bulk data. To export a data dump, do the following: 1. Click your avatar in the Postman header, then click **Settings**. 2. Click the **Account** tab, then **Export Data**. 3. Click **Export Data**, then select the data types you want to export. You can export collections, environments, or both. ![Image 3: Export data dump](https://assets.postman.com/postman-docs/v10/import-export-data-dump-request-confirm-v10-16a.jpg) When the export is ready, you'll get an email with a link to download the bulk data file. The download is available for two days, after which it expires. ### Import a data dump into Postman After exporting a data dump file, you can import it into any Postman instance. You must unzip the data dump file before importing it. Unzipping the data dump file results in a folder with a unique name. Inside you'll find a subfolder for each data type you chose to export, with individual JSON files for each exported collection and environment. You'll also find an `archive.json` file that lists the IDs of all exported collections and environments. To import the data dump into Postman, do the following: 1. In a workspace, click **Import** in the sidebar. 2. Drag the unzipped data dump folder into the import window. 3. Select the environments and collections you want to import, then click **Import**. Learn more about [importing data into Postman](/docs/getting-started/importing-and-exporting/importing-data/). --- # Import packages from external registries in Postman You can [import public packages](#import-a-public-package) from external package registries into your scripts. Postman supports importing public packages from [npm](https://www.npmjs.com/) and [JSR](https://jsr.io/) registries. If you're on a Postman Professional or Enterprise plan, you can also [import private packages](#import-a-private-package) from npm that a Team Admin configured access to. You can import external packages in your internal, partner, and public workspaces. External packages are supported in HTTP, gRPC, and GraphQL requests. ## Import a public package You can search for public external packages in npm and JSR and import them directly into your HTTP, gRPC, and GraphQL requests. If you're on a Postman Enterprise plan, a Team Admin can [manage external packages](/docs/administration/managing-your-team/manage-team-workspaces/#allow-packages-from-external-package-registries) your team is allowed to use in scripts. If you're on a Postman Enterprise plan, you can view external packages your Team Admin has allowed in scripts. Select **Team > Team Settings** in the Postman header, select **Team resources** in the sidebar, then select **External packages**. To search and import a public external package, do the following: 1. Open an HTTP collection, folder, or request. You can also open a gRPC or GraphQL request. 2. Select the **Scripts** tab. 3. Select ![Image 1: Package icon](https://assets.postman.com/postman-docs/aether-icons/entity-package-stroke.svg#icon) **Packages** at the lower right of the code editor. 4. Search for a public package in npm or JSR. To filter your search results by package registry, select **npm**, **JSR**, or both. Search returns the top five results for each package registry. Learn about [supported public packages](#supported-external-packages) in Postman. 5. Select a package to import it into the code editor. You can [view external packages in your script](#view-external-packages-in-your-script), including packages Postman was unable to import. ![Find and use public packages in external registries](https://assets.postman.com/postman-docs/v11/import-external-packages-v11-46.jpg) When you select a public external package from search, a JavaScript variable is automatically declared in the code editor. Use the variable to call functions and objects in the package. By default, the variable identifier is based on the external package name. The variable's value is the `pm.require` method with the package registry, name, and latest version number as the argument in the `registry-name:package-name@version-number` format. The script will always use the defined package version when the request runs. You can omit the version number (`@version-number`) from the argument to [use the latest package version](#use-the-latest-package-version) in all of your scripts. You must use the exact version number in the argument. Postman doesn't support other ways to specify a version, such as version ranges or tags. ```js // package imported from npm const npmVariableName = pm.require('npm:package-name@version-number'); npmVariableName.functionName() // package imported from jsr const jsrVariableName = pm.require('jsr:package-name@version-number'); jsrVariableName.functionName() ``` ## Import a private package Private npm packages are supported on [Postman Professional and Enterprise plans](https://www.postman.com/pricing/). You can import private external packages from npm if a Team Admin [configured access to the private package](/docs/administration/managing-your-team/manage-team-workspaces/#configure-access-to-private-packages) from your team's scripts. You can import private npm packages directly into your HTTP, gRPC, and GraphQL requests. If you're on a Postman Enterprise plan, a Team Admin can [manage external packages](/docs/administration/managing-your-team/manage-team-workspaces/#allow-packages-from-external-package-registries) your team is allowed to use in scripts. If you're on a Postman Professional or Enterprise plan, you can view external packages your Team Admin has allowed in scripts. Select **Team > Team Settings** in the Postman header, select **Team resources** in the sidebar, then select **External packages**. To import a private external package, do the following: 1. Open an HTTP collection, folder, or request. You can also open a gRPC or GraphQL request. 2. Select the **Scripts** tab. 3. Declare a JavaScript variable in the code editor you can use to call functions and objects in the package. The variable's value must use the `pm.require` method with "npm", scope, package name, and latest version number as the argument in the `npm:@scope/package-name@version-number` format. If you specified a version number, the script will always use the defined package version when the request runs. You can omit the version number (`@version-number`) from the argument to [use the latest package version](#use-the-latest-package-version) in all of your scripts. ```js // package imported from npm const npmVariableName = pm.require('npm:@scope/package-name@version-number'); npmVariableName.functionName() ``` You can [view external packages in your script](#view-external-packages-in-your-script), including packages Postman was unable to import. ## Use the latest package version When you import an external package, you can configure the argument so the latest package version is used in all of your scripts. To do this, omit the version number (`@version-number`) from the `pm.require` method's argument. By default, scripts use the latest version number available when you first opened or ran the request. Each script in your Postman app that imports the package without a version number will use the same version. The package version is specific to your Postman app, meaning the version may differ for your collaborators. To update the package version number in your Postman app, do the following: 1. Open an HTTP collection, folder, or request. You can also open a gRPC or GraphQL request. 2. Select the **Scripts** tab. 3. Select ![Image 2: Package icon](https://assets.postman.com/postman-docs/aether-icons/entity-package-stroke.svg#icon) **Packages** at the lower right of the code editor. 4. Hover over the imported package, and select ![Image 3: Syncing icon](https://assets.postman.com/postman-docs/aether-icons/state-syncing-stroke.svg#icon) **Update to latest version**. The version number is updated in each of your scripts that import the package without specifying a version number. ## View external packages in your script To view external packages in your request's script, select ![Image 4: Package icon](https://assets.postman.com/postman-docs/aether-icons/entity-package-stroke.svg#icon) **Packages** at the lower right of the code editor. To learn more about a package, hover over the package and select ![Image 5: Open in Postman icon](https://assets.postman.com/postman-docs/aether-icons/action-openInPostman-stroke.svg#icon) **View in npm** or ![Image 6: Open in Postman icon](https://assets.postman.com/postman-docs/aether-icons/action-openInPostman-stroke.svg#icon) **View in JSR**. Use the following to troubleshoot external packages in your script: * Packages with a blue checkmark were successfully imported in your script. * Packages with a red exclamation point couldn't be imported in your script. For example, the version may not be valid or the package isn't allowed in your team. Hover over the exclamation point to view a tooltip about the issue. ## Supported external packages Postman runs scripts in a sandbox environment that's secure by default. There are strict measures in place to ensure external code that runs inside the sandbox environment doesn't get extra privileges or access. Because of this, there may be some limitations when running the contents of external packages in the sandbox environment, depending on the package's dependencies. Consider the following when importing external packages into Postman: * Postman's sandbox environment runs code uniformly, regardless of whether the code runs on the browser or Node.js. External packages that use Nodes.js built-in modules may not work as expected in Postman because the modules aren't also available in the browser. * Postman doesn't support all of JavaScript's [standard built-in objects](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects). Learn about the [JavaScript objects Postman supports](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-require/#use-global-objects). * Packages and their dependencies that exceed 50 MB aren't supported. * Packages that use the [`await` keyword outside of an async function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/await#top_level_await) aren't supported. * Packages that use both named and default exports must use specific syntax to access the default exports: ```js // access default exports const fooDefaultExport = pm.require("npm:foo").default // access named exports const { fooNamedExport } = pm.require("npm:foo") ``` ## Troubleshoot vault secrets You can reference vault secrets stored in your Postman Vault by adding the vault secret as a variable in your Postman Collection's or Environment's variables. For example, if you're using the `vault:postman-api-key` variable, you can use it in your API requests to retrieve the API key. To reference a vault secret in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. To migrate your teams to Organizations, contact your Customer Success Manager. Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- # faq Starting in May 2025, you can create _team-to-team Partner Workspaces_. This update enhances security and authentication for Postman API partnerships and enables access to a Partner Workspace from one’s own team. In addition to supporting SSO login for partners, Partner Managers can verify which partners use SSO from a new [**Partnerships**](https://go.postman.co/settings/team/partnerships/external-partners) page in **Team Settings**. Postman is automatically migrating all pre-existing Partner Workspaces to the newer team-to-team model so that you get all the latest features and security enhancements. ## FAQ about migration to team-to-team partnerships ### What happens to the legacy Partner Workspaces created before May 2025? We are migrating these workspaces automatically to the newer team-to-team model. Once your Partner Workspaces are upgraded, both Publishers and Partners in each workspace will receive an email. No action is required from you. ### Who will receive these migration emails? All impacted Partner Managers, Team Admins, and Workspace Admins will receive an email stating “Your Partner Workspaces have been migrated”. All impacted Partners will receive an email titled “Your Partner Workspace with [Publisher Name] has been upgraded”. ### When are you completing the migration? If your team is on the Professional plan, we will migrate your workspaces mid-December. All Enterprise teams will be upgraded after the holidays in January. ### I am a Partner and I can’t access my Partner Workspace. What should I do? You should have received an email with a link to your Partner Workspace. The email subject will be “Your Partner Workspace with [Publisher Name] is now upgraded”. Click **Go to workspace** in the email to navigate directly to the Partner Workspace. Alternatively, you can navigate to [**Workspaces > View All Workspaces > External Workspaces**](https://www.postman.com/workspaces?tab=shared_partner) to see your Partner Workspace. ### I host a Partner Workspace and my Partner informed me that they can't access my Partner Workspace anymore Please see the above question. ## FAQ about team-to-team partnerships ### How can I create a Partnership using Postman? Users who want to create new team-to-team Partner Workspaces should do one of the following: * If using the Postman desktop app, update to the [latest version](https://www.postman.com/downloads/). * Use the Postman web app, which always has the latest version. Partners also need to access the Partner Workspace using a web browser or the latest version of the Postman app. ### How does this feature affect my team? All new Partner Workspaces you create are team-to-team Partner Workspaces. Your existing Partner Workspaces aren't affected, and you can continue to use them and invite new Partners. Postman can help you migrate existing Partner Workspaces, but this isn't required. If you partner with developers from another Postman team, those partnerships will become more secure and seamless if you migrate your workspaces. Partner management has been relocated in Team settings from the Members page to a new [Partnerships](https://go.postman.co/settings/team/partnerships/external-partners) page. When access to a Partner Workspace is requested, Partner Managers and Admins receive one email per team, while Partners receive one email per workspace containing a direct link to navigate to their workspace. Partners can now access workspaces directly from their team without switching to a partner-specific team. ### Are there any pricing changes? There are no changes to pricing. Partner Viewers are free, and Partner Editor add-ons are charged based on the [Professional and Enterprise plans](https://www.postman.com/pricing/#partner-editor). ### Do team-to-team Partner Workspaces support both single-partner and multi-partner configurations? You can use a team-to-team Partner Workspace as a single or multi-partner workspace. Workspace Admins can go to the **Workspace Settings** page and turn on multi-partner mode, which prevents partners from seeing each other in the workspace. However, the Publisher team members can see all partners in the workspace. ### How does this feature make partner collaboration more secure? In the new [**Partnerships**](https://go.postman.co/settings/team/partnerships/external-partners) page under **Team > Team Settings**, Postman gives you visibility into SSO-enabled Partner access. SSO-enabled Partners log in to their own company’s Postman team using SSO authentication, ensuring secure collaboration. If at any point, this Partner leaves their organization and their Postman team, they lose access to the Partner Workspace. Therefore, access to the Partner Workspace is tied to their Postman team, not the individual. ## What if I need help or have questions? For help or questions, you can use the following contacts: * If you are on an Enterprise contact your Postman Customer Success Manager. * If you are on free, Basic or Professional plans, contact [Postman Support](https://support.postman.com/hc/en-us/requests/new). * If you have questions or feedback on Partner Workspaces that you would like to share with the product team, you can email [Partner Workspaces Support](mailto:partnerapi@postman.com). --- # The Flow Module block ![Flow block](https://assets.postman.com/postman-docs/v11/flow-module-block-v11-29-1.jpg) The **Flow Module** block references a [flow module](/docs/postman-flows/get-started/build-your-first-flow/) from your workspace and outputs its result. This block lets you use the logic of multiple other flow modules in your current flow or action. By accepting input data and referencing other flows, **Flow Module** blocks can work like code functions. Suppose you have two flows: flow A and flow B. Flow A checks the availability of meeting rooms in your office based on input data such as location, time, and room preference. It then outputs whether a room is available. Flow B can use a **Flow Module** block to send input data to flow A and retrieve its result (room availability), then use that result in its own logic (for example, to decide to send an API call that reserves the room). The **Flow Module** block can reference any flow in your workspace that has at least one _snapshot_. Snapshots are saved versions of a flow. To learn more, see [Version flows with snapshots](/docs/postman-flows/build-flows/configure/snapshots/). ## Inputs By default, the **Flow Module** block has one **Run** input port and one input port for each input present in the **Start** block of the modular flow. When the **Run** port receives data, it triggers the **Flow Module** block. If it's not connected, the **Flow Module** block triggers when its host flow runs. If the referenced flow has a [**Start**](/docs/postman-flows/reference/blocks/start/) block with inputs, the **Flow Module** block will also have input ports that correspond with the **Start** block's inputs. For example, if a **Flow Module** block references a flow with three inputs defined in its **Start** block, the **Flow Module** block will have three input ports with the same names and data types as the **Start** block's inputs. Data sent to the **Flow Module** block's input ports will be passed to the corresponding **Start** block inputs in the referenced flow. When the referenced flow has **Start** block inputs, the **Flow Module** block must receive data in each of its corresponding input ports to trigger the referenced flow. ## Outputs The **Flow Module** block has one output port for each input port in the referenced flow's [**Output**](/docs/postman-flows/reference/blocks/output-module/) block. Each output port sends the value received by its corresponding input port in the referenced flow's **Output** block. The **Flow Module** block also has a **Done** output port that sends a boolean true signal when the referenced flow has completed. ## Setup When you add a **Flow Module** block, it prompts you to select a flow to reference. The **Flow Module** block can only reference flows in your workspace that have one or more [snapshots](/docs/postman-flows/build-flows/configure/snapshots/). To set up a **Flow Module** block, do the following: 1. Create a flow and add a **Flow Module** block. A list of flows you can reference appears. If the list is empty, make sure the flow you want to reference has at least one snapshot. 1. Select a flow from the list. The **Flow Module** block appears with the same title as the referenced flow. The latest snapshot number appears next to the title. When a newer version of the snapshot is available, the ![Snapshots](https://assets.postman.com/postman-docs/aether-icons/descriptive-versions-stroke.svg#icon) **Snapshots** icon turns purple. ### Select a different snapshot When you add a **Flow Module** block, it automatically selects the latest snapshot of the referenced flow. To select a different snapshot, do the following: 1. In the **Flow Module** block, click ![Snapshots](https://assets.postman.com/postman-docs/aether-icons/descriptive-versions-stroke.svg#icon). 1. Select a snapshot from the dropdown list. The **Flow Module** block uses the selected snapshot of the referenced flow. ## Example To see the **Flow Module** block in action, check out [Flow Snippets: Flow Module](https://www.postman.com/postman/flows-snippets/flow/6840b15868d0c30032a35bde). ## Related blocks The [**Start**](/docs/postman-flows/reference/blocks/start/) block is automatically added to every new flow module. The [**Output**](/docs/postman-flows/reference/blocks/output-module/) block sends the result from one flow module to a Flow Module block in a different flow. --- # Flows actions overview An *action* is a flow that's deployed in the Postman cloud. Unlike [*flow modules*](/docs/postman-flows/get-started/build-your-first-flow/), which must be run manually, actions can be triggered with automatic schedules, or with requests from webhooks, third-party apps, or other APIs. Actions are useful for running automations and exposing functionality as an API or as an AI tool for MCP servers. Actions can process incoming data and return structured responses. Once deployed, a request-triggered action gets a unique cloud-hosted URL. An action's URL is useful for tasks like automating business logic, handling webhooks, integrating with external services, or powering AI-driven tools on MCP servers. ## Local and deployed actions run in the Postman cloud and don't support private APIs. Actions are available in Postman version 11.42.3 and later. To learn about creating and deploying actions, see [Deploy flows as actions in Postman Flows](/docs/postman-flows/build-flows/structure/actions/). ## Manage long-running actions Actions typically send out any data they produce as HTTP response bodies. This holds true for any action that finishes running in less than the **Timeout** duration. The data flows through the **Response** block. The maximum **Timeout** is 30 seconds. If your action requires longer to run, [contact Postman support](/docs/administration/domain-verification-and-capture/enable-domain-capture/#contact-support-to-manage-accounts) to request an increase of the maximum timeout value to 60 seconds. Once the **Timeout** interval has elapsed, the **Response** block sends out a 408 Request Timeout error. The action will continue running for up to 60 minutes, at which point it will automatically stop. If your action requires over 60 seconds to run, it won't be able to send out data from the **Response** block. Instead, design your action to be [asynchronous](#synchronous-and-asynchronous-actions). ## Deploy actions with snapshots Actions can be *deployed* in the Postman cloud. Once deployed, a request-triggered action has a unique URL. You and other users can send requests to the action's URL and receive responses from it. As with flow modules, you can create and restore different [snapshots](/docs/postman-flows/build-flows/configure/snapshots/) of an action. Snapshots are like different versions of an action. When you deploy an action to make it publicly available in the Postman cloud, you can deploy a new snapshot or an existing one. If you deploy an existing snapshot, the local version of your action doesn't automatically restore the snapshot when you deploy it. To learn about restoring snapshots and more, see [Version flows with snapshots](/docs/postman-flows/build-flows/configure/snapshots/). ## Schedule actions to run automatically You can automate actions to run at regular intervals or at specific times. Automated actions can be useful for testing and other scheduled events in your API workflow. To learn more, see [Schedule an action to run automatically](/docs/postman-flows/build-flows/structure/actions/#schedule-an-action-to-run-automatically). ## Bearer tokens in actions You can configure actions to authorize requests with a [*bearer token*](/docs/sending-requests/authorization/authorization-types/#bearer-token). Bearer tokens make actions more secure by only granting access to requests that include the token. Learn how to [enforce bearer token authorization for actions](/docs/postman-flows/build-flows/structure/actions/#enforce-bearer-token-authorization-for-actions). ## Synchronous and asynchronous actions You can design your actions to be *synchronous* (sync) or *asynchronous* (async). In a sync action, all the blocks complete their functions before the action sends a response. An async action sends a response before its blocks finish running. For example, if an AI block in your action takes several seconds to complete a task, you may choose to send the response first. Async actions are useful when integrating with webhooks from services that expect a quick response, like Slack. Here's an example of an async action: ![Async action](https://assets.postman.com/postman-docs/v11/flows-async-action-v11-40.jpg) In this action, a **Validate** block checks the request data against a schema. If the request data is valid, the action simultaneously sends a Status Code 200 response and triggers the **Create with AI** block. The **Create with AI** block may complete after the action's timeout setting elapses. By making the action async, it can send a response before completing its workflow. ## How actions parse received data Flows actions parse incoming data as a structured data object. Each field in the object maps to a list of string values. For example, when an action receives the following data: ```bash token=9XqPLt7mKaRjVh2NbzC4f5Yw&team_id=T91H6Z2LK&team_domain=acme&channel_id=C72DF1XRK9&channel_name=integration-testing&user_id=U18ABZQXPR&user_name=jane.doe&command=/flows&text=status&api_app_id=A45K9L72QM&is_enterprise_install=false&enterprise_id=E55YT9QWKV&enterprise_name=AcmeCorp&response_url=https://hooks.slack.com/commands/T91H6Z2LK/3399128457101/HgT9yW3aKpLvQ8RbFsXe5JdM&trigger_id=3399128462830.8451991626.a1bc ``` it parses the data like this: ```json { "token": ["9XqPLt7mKaRjVh2NbzC4f5Yw"], "team_id": ["T91H6Z2LK"], "team_domain": ["acme"], "channel_id": ["C72DF1XRK9"], "channel_name": ["integration-testing"], "user_id": ["U18ABZQXPR"], "user_name": ["jane.doe"], "command": ["/flows"], "text": ["status"], "api_app_id": ["A45K9L72QM"], "is_enterprise_install": ["false"], "enterprise_id": ["E55YT9QWKV"], "enterprise_name": ["AcmeCorp"], "response_url": ["https://hooks.slack.com/commands/T91H6Z2LK/3399128457101/HgT9yW3aKpLvQ8RbFsXe5JdM"], "trigger_id": ["3399128462830.8451991626.a1bcde230ab982f3d451f9bce67d041d"] } ``` --- # Fork collections and environments in Postman A _fork_ is a new instance of an element. When you modify a fork, its parent element remains unchanged. In Postman, you can fork collections and environments. Forking enables you to contribute to an element without having [Editor access](/docs/administration/roles-and-permissions/#element-based-roles) for that element. ## Create a fork To fork an element within a public workspace, you must make your profile public in Postman [Settings](https://go.postman.co/settings/me/). For more information, see [Making your profile public](/docs/getting-started/installation/postman-profile/#make-your-profile-public). When you fork a collection or an environment, you create a copy of it in a different workspace. You must sign in to Postman to create a fork. To fork an element, do the following: 1. Select the element in the sidebar. 2. Select ![Image 1: Fork icon](https://assets.postman.com/postman-docs/aether-icons/action-fork-stroke.svg#icon) **Fork** in the upper right. 3. Enter a label for your fork, and select a workspace to save it to. 4. (Optional) If you are forking a collection, you can select one or more environments to include with the fork. 5. Select **Fork Collection** or **Fork Environment**. ![Image 2: Create fork tab](https://assets.postman.com/postman-docs/v11/fork-collection-v11.png) Postman creates your fork in the selected workspace. If there are any [mocks](/docs/design-apis/mock-apis/set-up-mock-servers/) or [monitors](/docs/monitoring-your-api/intro-monitors/) associated with the parent element, they aren't linked to the forked element. You must create mocks and monitors specifically for the fork if you need them. If a collection is in a public workspace that you haven't been added to, you won't be able to send a request within that workspace. To send requests or make changes to a collection, you must fork the collection into an internal workspace that belongs to you. ## Edit a fork's name or label To change a forked element's name or label, do the following: 1. Select the fork in the sidebar. 2. In the tab labeled with the names of the parent element and the fork, select the fork's name. 3. Edit the fork's name. 4. Select anywhere outside the name or label to save your changes. ## View fork information Fork information shows details about forks and the users who have created them. You will be able to identify the users who are actively consuming and contributing to your APIs. To view a list of users who have forked a collection or environment, select the number next to ![Image 3: Fork icon](https://assets.postman.com/postman-docs/aether-icons/action-fork-stroke.svg#icon) **Fork**. ![Image 4: View the fork information count](https://assets.postman.com/postman-docs/v11/fork-information-count-v11.jpg) To access the list of forks for a collection or environment, do the following: 1. Select ![Image 5: Fork icon](https://assets.postman.com/postman-docs/aether-icons/action-fork-stroke.svg#icon) **Forks** in the right sidebar. 2. Select the fork name. ![Image 6: View the list of forks](https://assets.postman.com/postman-docs/v10/fork-information-list-v10.jpg) You can also select the user's avatar under **Forks** to view the user's public profile. ![Image 7: View the list of forks](https://assets.postman.com/postman-docs/v10/fork-information-list-v10.jpg) ## Pull updates from a parent element Forked multi-protocol collections don't support pulling updates, merging changes, or resolving conflicts. You can pull updates from a parent element into a fork without going through the [pull request process](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). 1. Hover over the fork in the sidebar. 2. Select ![Image 8: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to its name. 3. Select **Pull changes**. 4. Review the diff and select **Pull changes**. ![Image 9: Pull changes into fork](https://assets.postman.com/postman-docs/v10/pull-changes-v10.jpg) To pull updates from a parent element during the pull request process, see [Pulling updates during a pull request](/docs/collaborating-in-postman/using-version-control/reviewing-pull-requests/#pull-updates-during-a-pull-request). ## Merge changes from a fork If you have Editor access on the element, you can _merge_ a fork into the parent element without going through the [pull request process](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). For example, if you're using forks to organize the work in your workspace, you can merge changes in a fork directly back into the parent element. If you're collaborating with others, merging directly lacks the safeguards built into the pull request process. Many teams require pull requests as part of their [version control workflow](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). To merge changes from a fork without opening a pull request, do the following: 1. Hover over the fork in the sidebar. 2. Select ![Image 10: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to its name. 3. Select **Merge changes**. 4. Review the diff and select **Merge All Changes**. ![Image 11: Merge Fork](https://assets.postman.com/postman-docs/v10/merge-fork-collection-change-v10.jpg) 1. Select one of the following merge options: * **Merge changes** - Merge the changes into the parent element. This doesn't make any changes to the fork. You must have Editor access to the parent element. * **Merge changes and update source** - Merge the changes into the parent element. Any differences in the parent element are also made to the fork. You must have Editor access to both the parent and forked elements. * **Merge changes and delete source** - Merge the changes into the parent element. After the merge process is complete, Postman deletes the fork. You must have Editor access to both the parent and forked elements. ![Image 12: Merge Fork Options](https://assets.postman.com/postman-docs/merge-fork-options-v9.12.jpg) 2. Select **Merge**. To merge changes during the pull request process, see [Merge changes from a pull request](/docs/collaborating-in-postman/using-version-control/reviewing-pull-requests/#merge-changes-from-a-pull-request). ## Resolve conflicts from a fork A merge conflict happens when you try to merge changes into an updated parent element and Postman isn't able to automatically resolve the differences between the two. If there's a conflict when you try to merge a fork, you'll need to decide how you want to resolve it before continuing. Merge conflicts can involve changes in more than one workspace. To resolve a merge conflict from a fork, do the following: 1. Begin the merge process described in [Merge changes from a fork](#merge-changes-from-a-fork). 2. Select **Pull the changes** for any conflict. ![Image 13: Pull Changes](https://assets.postman.com/postman-docs/v10/conflicts-pull-changes-v10-2.jpg) For each conflict, choose the version you want to include when you merge. Select **Keep Source** to keep the change on the parent element. Select **Keep Destination** to keep the change on your fork. You can also select the version you want to keep for each conflict. ![Image 14: Pull Changes](https://assets.postman.com/postman-docs/v10/conflicts-keep-source-or-destination-v10-2.jpg) To keep all changes on your fork, select **Keep all changes to source**. To keep all changes on the parent element, select **Keep all changes to destination**. After you resolve the conflicts, select **Pull changes** to [pull the updates](#pull-updates-from-a-parent-element). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access ![Image 15: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then open a specification. 2. Click ![Image 16: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. ![Image 17: Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 1. Click ![Image 18: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 4. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 5. Click **Create collection**. ![Image 19: Create Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 20: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then open a specification. 2. Click ![Image 21: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 22: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Image 23: Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 24: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then open a specification. 2. Click ![Image 25: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component in the left sidebar that you'd like to version and publish. 5. Click **Version & Publish** in the upper right corner. ![Image 26: Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 1. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 2. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Image 27: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the Postman header, then open a specification. 2. Click ![Image 28: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of a specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 29: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Image 30: Reference a component in a specification](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 31: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team** in the Postman header, then select **Team Settings**. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create collection**. ![Image 32: Create Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. ![Image 33: Create Organization Workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Determine the Admins for each workspace from the list of workspace users. 2. Review the roles on the workspaces you moved, and align them with these best practices: * If the workspaces were previously shared with the Organization, ensure they remain shared with the Organization. * If the APIs are intended to be consumed by others, ensure those people still have access to view them. * If you require limited sharing, consider sharing APIs with specific Teams that are interested in them, leveraging the Team memberships, rather than inviting individuals. * Ensure that workspaces are viewable by the Team it was moved into, unless there is a specific reason it shouldn’t be shared with other Team members. * Make the workspace editable by the Team. * Because Teams can have both Members and Guests, set up a pattern where Team Members are the primary contributors to the work, and Guests, having only view access, are the consumers. * The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. * Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? 7. If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 34: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 35: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. To migrate your teams to Organizations, contact your Customer Success Manager. Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- # get-postman Get the Postman app | Postman Docs =============== Get the Postman app =================== **[Download the Postman app for macOS, Windows, or Linux.](https://www.postman.com/downloads/)** Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/installation/installation-and-updates/). ## Get the Postman app for macOS, Windows, or Linux. Postman is the API platform for using, building, and testing APIs. You can use the Postman desktop app to power every part of your API lifecycle: * Send requests with the Postman API client, including HTTP, GraphQL, and gRPC requests. * Design, build, and document APIs. * Build AI agents that interact with LLMs and APIs. * Test and monitor your API's functionality and performance. * Organize your work and collaborate with your team on API development. * Discover new APIs and build visual API-driven applications. Postman is available as a desktop and web app. * To download the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and click the button for your operating system. Postman is available as a native desktop app for macOS (Intel or Apple silicon), Windows (Intel 64-bit or ARM 64-bit), and Linux (64-bit). * To get started in your browser, go to the [web app](https://go.postman.co/home/). [!NOTE] Some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. If you need more help with your install, go to [Install and update Postman](/docs/getting-started/install --- # graphql-overview GraphQL in Postman ================== Postman can make requests using GraphQL, an open-source query language and runtime for APIs. ## About GraphQL APIs that support GraphQL enable clients to ask the server for only the data they need, using GraphQL's powerful query language and runtime. Unlike REST, which uses multiple endpoints to access different data sets, GraphQL streamlines querying by accessing all data through a single endpoint. GraphQL is schema-driven, providing insight into an API's functionality and reducing dependency between teams building the client and the server. A client can introspect the schema from the server to see the available data fields, and then send queries specifying which fields to retrieve or manipulate. The server returns or modifies only the data requested in the query, which prevents fetching too much or too little data. ## GraphQL requests Every GraphQL request has a URL and a query. The URL is the endpoint where the data is hosted, and the query defines what data to retrieve or manipulate. The API's schema defines available data fields. The request can also contain authentication, headers, and settings based on the requirements specified by the API. GraphQL requests can perform three types of operations: * **Query** - Retrieves data from the server. Queries specify the required data fields and can include arguments for more precise data retrieval. * **Mutation** - Manipulates data on the server, including creating, updating, or deleting records. Mutations specify the fields to be returned after the operation and use arguments to detail the manipulation. * **Subscription** - Gets real-time data updates from the server. Subscriptions enable clients to listen to specific data fields and receive updates automatically over a persistent connection. ## The Postman GraphQL client Postman's [GraphQL client](/docs/sending-requests/graphql/graphql-client-interface/) loads automatically when you create a new GraphQL request. The GraphQL client interface is specifically designed for crafting GraphQL requests, enabling you to explore an API's data fields and construct queries by selecting fields. GraphQL requests and [multi-protocol collections and folders](/docs/collections/use-collections/add-requests-to-collections/#about-multi-protocol-collections) can also contain scripts that you write to perform API tests. These can be run before a query or after a response. To learn more, see [Use scripts to add logic and tests to Postman requests](/docs/tests-and-scripts/write-scripts/intro-to-scripts/). You can also make GraphQL requests using Postman's HTTP request interface. To learn more, see [Make a GraphQL call with an HTTP request](/docs/sending-requests/graphql/graphql-http/). ## Troubleshoot vault secrets You can reference vault secrets stored in your Postman Vault by adding the vault secret inside double curly braces (`{{vault:secret-name}}`) and appending the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` To reference a vault secret in your Postman team, you can paste the Postman CLI installation, `login`, and `performance` commands into your CI/CD script. This process depends on your CI tool. The following example shows how to add the Postman CLI commands to GitHub Actions: ```yaml name: Run performance tests using the Postman CLI on: push jobs: automated-api-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install Postman CLI run: npm install -g postman-cli - name: Login to Postman CLI run: postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }} - name: Run performance test run: postman performance run ${{ vars.COLLECTION_ID }} ``` ## Postman Vault integrations Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) You can create a new collection from an imported API, and you can add the following components to your team's specifications: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. Users can't turn off secret policies. ### View live documentation Postman displays a live preview of your API's documentation as you edit your component file. To show the documentation preview, click {{vault:secret-name}} in the right sidebar. Click {{vault:secret-name}} to hide the documentation preview. ### Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click {{vault:secret-name}} in the version dropdown list. 2. Select **Create Version & Publish**. 3. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 4. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click {{vault:secret-name}} in the left sidebar. 2. Choose a published version of the component file using the version dropdown list. 3. In the left sidebar, click {{vault:secret-name}} next to a component. This copies the URL to the version of the component you select in the dropdown list. 4. Add the URL to a reference (`$ref`) in your specification. In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Organization Settings Postman's Organization Settings enable you to manage items such as your team's publisher profile, discoverability, custom domains, authentication, and active invite links. ## Organization roles * **Team Managers** are responsible for creating Teams in the Organization and can manage any Team. They're also responsible for assigning individual Team Managers to the teams they create. * **Team Members** can approve the adding of Members and the sharing of content from the Teams they manage. * **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ## Team roles Each team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the structure of your teams and memberships, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. To create a team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click {{vault:secret-name}} in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics Postman provides tools to help you manage your team's usage of credits in Postman Flows. You get a certain number of credits each month. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default. To do this: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection --- # grpc-client-overview Manage gRPC APIs using Postman ============================= Postman can make requests using _gRPC_, a schema-driven Remote Procedure Call (RPC) framework often used to enable inter-service communication. Using a gRPC request, you can view supported services and methods (with a service definition), invoke the method of your interest, send a message payload, view the response from the server, and save example responses without entering commands in the terminal or writing any code. Because it's RPC-based, gRPC facilitates client-server communication over a function call and provides easier abstraction than HTTP, support across multiple languages, and high performance. gRPC uses [protobuf (protocol buffers)](https://developers.google.com/protocol-buffers/docs/overview) as the Interface Definition Language (IDL) to define the API interface (service definition). This definition serves as a contract between the client and the server that specifies the supported services and methods. Postman's [gRPC client interface](/docs/sending-requests/grpc/grpc-request-interface/) enables you to use and test your gRPC requests. You can also [manage your service definitions](/docs/sending-requests/grpc/using-service-definition/) and [save gRPC example request-response pairs](/docs/sending-requests/grpc/using-grpc-examples/) for testing and demonstration purposes. Postman also enables you to use scripts to write API tests, debug your gRPC requests, and dynamically read or update the values of variables. For more information, see [Test and debug values in gRPC requests using JavaScript in Postman](/docs/sending-requests/grpc/scripting-in-grpc-request/). You can also [use a mock server](/docs/sending-requests/grpc/using-grpc-mock/) to simulate the behavior of a real API by returning sample data for gRPC requests to the API endpoints. ### Postman Vault integrations **[Postman Vault integrations are available with Postman Enterprise plans with the Advanced Security Administration add-on.](https://www.postman.com/pricing/)** [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) enable you to link vault secrets with secrets that are stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of external vault secrets using end-to-end encryption when you send HTTP requests. You can [manage and update](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/) your Postman Vault integrations. Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) You can create Postman Vault integrations from the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-desktop-app). ### Feature availability The following features require the Postman desktop app: * **Open Postman Vault from public workspaces** - You must use the Postman desktop app to open your Postman Vault from a [public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/). * **Create and manage Postman Vault integrations** ([Enterprise teams only](https://www.postman.com/pricing/)) * **Create and manage Postman Vault integrations** ([Enterprise teams only](https://www.postman.com/pricing/)) ### Troubleshoot vault secrets Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces --- # Configure headers for API requests in Postman Some APIs require you to send particular headers with requests to provide metadata about the operation you're performing. You can configure request headers in Postman, and save groups of headers as presets for quick access. Postman also automatically adds headers to your requests as needed depending on your request selections. ## Configure request headers You can configure headers in the **Headers** tab of your request. Enter any key-value pairs you need and Postman will send them along with your request. As you enter text, Postman prompts you with common options you can use to autocomplete your setup, such as `Content-Type`. When you're done configuring headers, select **Send** to send the request. Learn more about [creating and sending requests in Postman](/docs/sending-requests/create-requests/request-basics/). ![Header types](https://assets.postman.com/postman-docs/v11/presets-v11-27-b.jpg) ## Header presets You can save commonly used headers together in a _header preset_. In the **Headers** tab of your request, select the **Presets** dropdown list and choose **Manage Presets**. Select **Add Header Preset** to add a new preset, and enter a name for the preset. Enter key-value pairs, then select **Add**. You can select your preset in the **Presets** dropdown list. Selecting the preset will autopopulate the fields in your request headers. ![Header presets](https://assets.postman.com/postman-docs/v11/header-presets-v11-27-b.jpg) ## Autogenerated headers Postman will automatically add certain headers to your requests based on your request selections and settings. Select **hidden** at the top of your request's **Headers** tab for information about what Postman will send with your request. ![Hidden headers](https://assets.postman.com/postman-docs/v11/hidden-headers-button-v11.jpg) Hover over a header to view details about it. Postman will indicate why the header has been added. The details will also indicate how to deactivate or override a header value if you need to. ![Host header](https://assets.postman.com/postman-docs/autogenerated-host-header-v9.jpg) You can make changes to a header in the **Authorization** tab, the request **Body**, **Cookies** for the request domain, the **Settings**, and in some cases in the **Headers** tab itself. If you need to go to a different part of the app, Postman will show a link on the right-hand side. If a header has been added based on your auth setup, [select the **Authorization** tab](/docs/sending-requests/authorization/authorization/) to change it. To alter cookie headers, [change the cookie setup](/docs/sending-requests/response-data/cookies/) for the domain you're sending the request to. ![Token header](https://assets.postman.com/postman-docs/v11/headers-added-v11.jpg) To deactivate an autogenerated header in the **Headers** tab, clear its checkbox. To override an autogenerated header value, clear the checkbox next to the autogenerated entry. Then add a separate entry for the header, listing its name in the **Key** field and specifying your value in the **Value** field. If you have more than one entry for the same header, Postman indicates which one will be overridden. Postman prioritizes headers you have either explicitly added in **Headers** or indirectly with selections you made in the other parts of your request such as **Authorization**. For `Content-Length` and `Content-Type` headers, Postman will automatically calculate values when you send your request, based on the data in the **Body** tab. However, you can override both values. ## Postman Vault integrations Postman Vault integrations enable you to link vault secrets with secrets that are stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of external vault secrets using end-to-end encryption when you send HTTP requests. Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) You can create Postman Vault integrations from the Postman header, then select **Secret Scanner** in the left sidebar. ![Secret Scanner interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage behavior** from **No policy** to **Move to vault**. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### View live documentation Postman displays a live preview of your API's documentation as you edit your component file. To show the documentation preview, click **Live preview** in the right sidebar. Click **Close** to hide the documentation preview. ### Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. In **Secret Scanner**, select the **Reports** tab. 4. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## Connect Zoom to your Flows action You can connect [Zoom](https://www.zoom.com/) to a flow with the Zoom **Connector** block. Use this block to perform the following operations: * Create Meeting * Update Meeting * Get Meeting * Get Meeting By ID * Delete Meeting * Add Meeting Registrant * Get Meeting Registrant * Delete Meeting Registrant * Get Recording By Meeting ID * Search Recording To connect Zoom to a Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 1. Click **Template** block and click **Zoom** from the list of blocks. 1. Click **Select an operation...** and select the operation you want the action to perform. 1. Click **Select an account...** and follow the prompts to connect your Zoom account. 1. Connect the **Request** block's output ports to the Zoom **Connector** block's input ports, based on the selected operation. 1. Connect the Zoom **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ![Zoom Connector block](https://assets.postman.com/postman-docs/v11/zoom-connector-v11.png) ## Connect Gong to your Flows action You can Connect [Gong](https://www.gong.io/) to a flow with the Gong **Connector** block. Use this block in a Flows action to perform the following operations: * Add a New Call * Get Call by ID * Search for Call To connect Gong to a Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 1. Click **Template** block and click **Gong** from the list of blocks. 1. Click **Select an operation...** and select the operation you want the action to perform. 1. Click **Select an account...** and follow the prompts to connect your Gong account. 1. Connect blocks' input and output ports as needed. ![Gong Connector block](https://assets.postman.com/postman-docs/v11/gong-connector-v11.png) ## Connect Box with your Flows action You can connect [Box](https://developer.box.com/) to your flows with the Box **Connector** block. Use this block in a Flows action to perform the following operations: * Save File * Save File From Object * Get File By ID * List Files * Create Folder * Move Folder * Get Folder By ID * Search Folders * Delete Folder * Download File To connect Box to a Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 1. Click **Template** block and click **Box** from the list of blocks. 1. Click **Select an operation...** and select the operation you want the action to perform. 1. Click **Select an account...** and follow the prompts to connect your Box account. 1. Connect blocks' input and output ports as needed. ![Box Connector block](https://assets.postman.com/postman-docs/v11/box-connector-v11.png) ## Run a performance test using the Postman CLI With performance tests, you can simulate user traffic and observe how your API behaves under load, identifying potential issues that affect performance. You can use the [Postman CLI](/docs/postman-cli/postman-cli-overview/) to trigger [performance tests](/docs/collections/performance-testing/testing-api-performance/) for specified collections, all within your CI/CD pipeline. Your team can use your tests to automatically catch performance issues during the deployment process. Depending on whether the performance test passes or fails, you can push or roll back your changes. With the [`postman performance run` command](#run-a-performance-test-command), you can configure a performance test for a collection. Add the command into your CI/CD script to [integrate performance tests into your workflow](#run-a-performance-test-within-your-cicd-pipeline). Postman recommends replacing your collection ID and API key with variables. The Postman CLI triggers the performance test using the `postman performance run` command. The performance test runs against the specified collection according to your performance test configuration. Then the Postman CLI makes the test results available in the [performance test results](/docs/collections/performance-testing/performance-test-metrics/) in Postman. ### Run a performance test within your CI/CD pipeline To run a performance test within your CI/CD pipeline, do the following: 1. Use the command to [install the Postman CLI](/docs/postman-cli/postman-cli-installation/). You can use the following command to install the Postman CLI using npm: ```bash npm install -g postman-cli ``` 2. Use the command to [sign in to Postman](/docs/postman-cli/postman-cli-options/#sign-in-and-out) with the `--with-api-key` option to authenticate using your [Postman API key](/docs/developer/postman-api/authentication/#generate-a-postman-api-key). You can use the following command to sign in and authenticate using your Postman API key: ```bash postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }} ``` 3. Use the command to [run a performance test](#run-a-performance-test-command) for a specific collection using its ID. Configure the performance test using its supported options to specify the number of virtual users to simulate, pass or fail conditions, and more. You can use the following command to run a performance test using the default settings: ```bash postman performance run ${{ vars.COLLECTION_ID }} ``` > [!TIP] > To get a collection ID in Postman, click **Collections** in the sidebar and select a collection. Then click **Info** in the right sidebar to view or copy the collection ID. 1. Paste the Postman CLI installation, `login`, and `performance` commands into your CI/CD script. This process depends on your CI tool. The following example shows how to add the Postman CLI commands to GitHub Actions: ```yaml name: Run performance tests using the Postman CLI on: push jobs: automated-api-tests: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Install Postman CLI run: npm install -g postman-cli - name: Login to Postman CLI run: postman login --with-api-key ${{ secrets.POSTMAN_API_KEY }} - name: Run performance test run: postman performance run ${{ vars.COLLECTION_ID }} ``` ## Connect Postman with Azure API Gateway Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ### Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ### Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Amazon API Gateway Integrate your Amazon API Gateway with Postman Collections and streamline your testing workflow. ### Import APIs from Amazon API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Amazon API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Amazon API Gateway to Postman](#connect-your-amazon-api-gateway-to-postman). ### Create collections in Postman from Amazon Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Amazon API Gateway to Postman Once connected to the Amazon API Gateway, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Amazon API Gateway to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Google API Client Integrate your Google API Client with Postman Collections and streamline your testing workflow. ### Import APIs from Google API Client to Postman Before you get started with creating a collection from an imported API, connect your Google API Client to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Google API Client to Postman](#connect-your-google-api-client-to-postman). ### Create collections in Postman from Google API Client APIs Collections created using the API client app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Google API Client to Postman Once connected to the Google API Client, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Google API Client to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Microsoft Azure API Gateway Integrate your Microsoft Azure API Gateway with Postman Collections and streamline your testing workflow. ### Import APIs from Microsoft Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Microsoft Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Microsoft Azure API Gateway to Postman](#connect-your-microsoft-azure-api-gateway-to-postman). ### Create collections in Postman from Microsoft Azure API Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Microsoft Azure API Gateway to Postman Once connected to the Microsoft Azure API Gateway, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Microsoft Azure API Gateway to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Microsoft Teams Integrate your Microsoft Teams with Postman Collections and streamline your testing workflow. ### Import APIs from Microsoft Teams to Postman Before you get started with creating a collection from an imported API, connect your Microsoft Teams to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Microsoft Teams to Postman](#connect-your-microsoft-teams-to-postman). ### Create collections in Postman from Microsoft Teams APIs Collections created using the Teams app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Microsoft Teams to Postman Once connected to the Microsoft Teams app, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Microsoft Teams app to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Slack Integrate your Slack with Postman Collections and streamline your testing workflow. ### Import APIs from Slack to Postman Before you get started with creating a collection from an imported API, connect your Slack to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Slack to Postman](#connect-your-slack-to-postman). ### Create collections in Postman from Slack APIs Collections created using the Slack app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Slack to Postman Once connected to the Slack app, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Slack app to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Connect Postman with Teams Integrate your Teams with Postman Collections and streamline your testing workflow. ### Import APIs from Teams to Postman Before you get started with creating a collection from an imported API, connect your Teams to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Teams to Postman](#connect-your-teams-to-postman). ### Create collections in Postman from Teams APIs Collections created using the Teams app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Teams to Postman Once connected to the Teams app, you can automatically import any one of the available APIs, along with the environment and the associated environment variables. To connect your Teams app to Postman, do the following: 1. In Postman, select **Team** in the Postman header, then click **Organization Settings** in the left sidebar. 2. In **Organization Settings**, select **Teams**. 3. Click **Create Team**. 4. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 5. Click **Add Members**. To be added, members need to be part of the organization. 6. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 7. Populate the team with the members who are responsible for the team’s contents. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select ** --- # The If block ![The If block](https://assets.postman.com/postman-docs/v11/flows-reference-blocks-if-v11.53.2.jpg) The **If** block is a logical gate that routes data through one of two output ports based on the result of an evaluation. The **If** block can process and evaluate data using [TypeScript](/docs/postman-flows/typescript/typescript-overview/) or [Flows Query Language](/docs/postman-flows/flows-query-language/introduction-to-fql/) (FQL) expressions. ## Inputs **variable** - Connect a block to this input port to evaluate its data with TypeScript or FQL. Click ![Add data blocks](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks** to [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) a data block into your **If** block. You can change an inserted block to a different data block by selecting the inserted block's icon and choosing a block from the dropdown list. **Text box** - Enter TypeScript (the default) or FQL code to create true/false expressions here. To switch between TypeScript and FQL, select from the dropdown list at the top of the block. **Data** - Data received by this input port will be routed through either the **Then** or **Else** output port depending on whether the expression in the text box is true or false. If you don't need to pass any data through to those outputs, connect a **Bool** block to the **Data** input. (This avoids having the **If** block fail because the **Data** input has received no data.) ## Outputs When the expression in the text box is true, the block routes data received by the **Data** input through the **Then** output port. Otherwise, the data is routed through the **Else** output. The data sent through either port is only what the **Data** input receives, not the variables (if any) that you added as inputs to the evaluation expression. ## Setup 1. To receive and evaluate data from another block in your flow, connect the **variable** input port to the other block's output port. 2. To [insert](/docs/postman-flows/reference/blocks/overview/#insert-data-blocks-into-other-blocks) a block and evaluate its data, click ![Add data blocks](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add data blocks**, then select a block from the dropdown list. You can reference the inserted block's value as a variable in your true/false expression. To rename the variable, select the inserted block's name and enter a new name. 3. Enter TypeScript (the default) or FQL code to create true/false expressions here. To switch between TypeScript and FQL, select from the dropdown list at the top of the block. 4. Enter your TypeScript or FQL expression in the text box. ## Example The following example flow uses an **If** block to compare a random integer to a cutoff set at 350. The flow follows one branch if the input value exceeds the cutoff, and follows the other branch if the input is less than or equal to the cutoff. Note that for the integer to appear in the **Display** blocks connected to the `THEN` and `ELSE` branches, it was necessary to send that data to the **Data** input. Sending it to an input for the text box didn't suffice, because data in the text box isn't available to the `THEN` and `ELSE` branches. ![An If block example flow](https://assets.postman.com/postman-docs/v11/flows-blocks-reference-if-example-v11.54.2.jpg) To run this flow, clone it from [Flow Snippets: If](https://www.postman.com/postman/flows-snippets/flow/63bcba94f3155f2e86b54eb0). ## Related blocks The blocks you can insert into the **If** block to provide data for the evaluation that it runs include the [**String**](/docs/postman-flows/reference/blocks/string/), [**Bool**](/docs/postman-flows/reference/blocks/bool/), [**Number**](/docs/postman-flows/reference/blocks/number/), [**Null**](/docs/postman-flows/reference/blocks/null/), [**Select**](/docs/postman-flows/reference/blocks/select/), [**Now**](/docs/postman-flows/reference/blocks/now/), [**Date**](/docs/postman-flows/reference/blocks/date/), [**Date \u0026 Time**](/docs/postman-flows/reference/blocks/date-and-time/), [**List**](/docs/postman-flows/reference/blocks/list/), [**Record**](/docs/postman-flows/reference/blocks/record/), and [**Get Variable**](/docs/postman-flows/reference/blocks/get-variable/) blocks. ## Related pages For tutorials that use the **If** block, see the following: * [Automate repetitive tasks using Postman Flows](/docs/postman-flows/tutorials/advanced/automate-repetitive-tasks/) * [Send information from one system to another using Postman Flows](/docs/postman-flows/tutorials/advanced/send-information-from-one-system-to-another/) --- # Import an API into the Postman API Builder You can import an existing API specification into the Postman API Builder. API specifications can be imported from a local file or directory, a URL, raw text, or an API gateway. ## Import an API specification 1. In Postman, click **Import** in the sidebar. 2. Select an API specification file, enter a link to the API, or paste your raw text. 3. If you import an OpenAPI 3.0 or AsyncAPI 2.0 specification this way, you'll only have the option to [import the specification into Spec Hub](/docs/design-apis/specifications/import-a-specification/). To import an OpenAPI 3.0 or AsyncAPI 2.0 specification into the API Builder, [import the file into your API](/docs/design-apis/api-builder/develop-apis/defining-an-api/#import-an-api-definition). 4. You can choose to import the specification as a collection or as an API along with a collection. 5. Click **Import**. 6. An **Import Complete** message displays in the footer. In the message, select **Open in Postman** icon **View More Actions** to view more actions. 7. Select **Go to Collection** next to a collection or API to open the imported element. ![Import complete message](https://assets.postman.com/postman-docs/v11/import-complete-message-v11-2.jpg) ## Import a multi-file API specification Multi-file API specifications are supported in OpenAPI 2.0 and 3.0 APIs and protobuf 2.0 and 3.0 APIs. If you import a multi-file OpenAPI 3.0 specification this way, you'll only have the option to [import the specification into Spec Hub](/docs/design-apis/specifications/import-a-specification/). To import a multi-file OpenAPI 3.0 specification into the API Builder, [import the files into your API](/docs/design-apis/api-builder/develop-apis/defining-an-api/#import-an-api-definition). 1. In Postman, click **Import** in the sidebar. 2. Select **folders**, then select a local folder with your API files. 3. Select the files you want to import into Postman. Select **Postman Collection** to create a collection only. Select **(format) with a Postman Collection** to import the specification as a collection in the **Collections** tab and an API with a collection. 4. Click **Import**. 5. An **Import Complete** message displays in the footer. In the message, select **Open in Postman** icon **View More Actions** to view more actions. 6. Select **Go to Collection** next to a collection or API to open the imported element. ![Import complete message](https://assets.postman.com/postman-docs/v11/import-complete-message-v11-1.jpg) ## Import API specifications from Amazon API Gateway [Amazon API Gateway](https://aws.amazon.com/api-gateway/) enables developers to publish and manage APIs that access AWS and other web services and data sources. You can import APIs directly from AWS Gateway to Postman. This creates an integration with API Gateway. Once connected, you can view your API deployment status and history from within Postman. You can also view [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) metrics for each stage to get operational insight into your API. This integration supports importing OpenAPI 3.0 specifications for both HTTP and REST APIs. Importing a specification will create a new API in Postman and will also configure an integration with AWS API Gateway. To import an API from AWS API Gateway, click **Import** in the sidebar, then select **Other Sources > AWS API Gateway**. When importing an API from AWS API Gateway, you can choose to authenticate by creating an AWS IAM role or by using an AWS access key. Follow the steps for your chosen method: * [Authenticate with an AWS IAM role](#authenticate-with-an-aws-iam-role) * [Authenticate with an AWS access key](#authenticate-with-an-aws-access-key) ### Authenticate with an AWS IAM role To set up a connection to Amazon API Gateway using an AWS IAM role, do the following: 1. Select **IAM** under **AWS Authentication Method**. ![Connecting with AWS IAM role](https://assets.postman.com/postman-docs/v11/import-from-api-gateway-with-iam-role-v11.jpg) 1. Select the **AWS API Type** (HTTP or REST). To create an IAM role for Postman in AWS, do the following: 1. Sign in to the [AWS IAM console](https://console.aws.amazon.com/iam/home#/roles) and select **Create role**. 1. Under **Select type of trusted entity**, select **AWS account**. 1. Under **An AWS account**, select **Another AWS account** and enter Postman's **AWS Account ID**: `258201882842` 1. Under **Options**, select the **Require external ID** checkbox and enter the **External ID** from Postman. You can find the external ID in Postman's **Connect to AWS API Gateway** procedure under **Step 1: Create an IAM role**, as shown in [Authenticating with an AWS IAM role](/docs/integrations/available-integrations/aws-api-gateway/deploying-an-api-aws/#authenticate-with-an-aws-iam-role). For more information, refer to the [AWS IAM guide on using external IDs](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). 1. Click **Next: Permissions**. 1. Select an existing IAM policy or click **Create policy**. If you are creating a policy, use the following JSON code: ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "Stmt909923626743", "Effect": "Allow", "Action": [ "apigateway:GET", "apigateway:PUT", "apigateway:POST", "cloudwatch:GetMetricData" ], "Resource": [ "*" ] } ] } ``` This policy will enable exporting and deploying for HTTP API specifications. (Exporting and deploying aren't supported for REST API specifications.) You can customize the `Action` section in the IAM policy based on your needs: * `\"apigateway:GET\"` - (Required) Enables viewing API Gateway deployments for HTTP and REST APIs in Postman. * `\"apigateway:PUT\"` - Enables [exporting](/docs/integrations/available-integrations/aws-api-gateway/deploying-an-api-aws/#export-and-deploy-your-api) HTTP API specifications to the API Gateway. * `\"apigateway:POST\"` - Enables [deploying](/docs/integrations/available-integrations/aws-api-gateway/deploying-an-api-aws/#export-and-deploy-your-api) HTTP API specifications to a stage on the API Gateway. * `\"apigateway:*\"` - Assigns all GET, PUT, POST, PATCH, DELETE permissions to the IAM role. * `\"cloudwatch:GetMetricData\"` - Enables [viewing CloudWatch metrics](/docs/integrations/available-integrations/aws-api-gateway/deploying-an-api-aws/#view-cloudwatch-metrics) in Postman. 1. Click **Next: Tags**. 1. Click **Next: Review**. 1. Add a **Role name** and **Role description**, then click **Create role**. Copy the **Role ARN** from AWS and paste it in Postman under **Step 2: Enter role ARN and region**. Next, enter the **AWS Region** where the API Gateway is located and select the **API Gateway**. Then, enter an **API Name** for the imported API. When you're ready, click **Connect**. ### Authenticate with an AWS access key To set up a connection to Amazon API Gateway using an AWS access key, select **Access Key** under **AWS Authentication Method**. ![Connecting with AWS access key](https://assets.postman.com/postman-docs/v11/import-from-api-gateway-with-access-key-v11.jpg) Next, enter information about the connection: * Select the **AWS API Type** (HTTP or REST). * Enter the **Access Key ID** and **Secret Access Key** for your AWS account. (Learn how to [find your credentials in AWS](https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/getting-your-credentials.html).) * Enter the **AWS Region** where the API Gateway is located and select the **API Gateway**. * Enter an **API Name** for the imported API. When you're ready, click **Import**. After importing your API specification, you can [view API deployments in Postman](/docs/integrations/available-integrations/aws-api-gateway/deploying-an-api-aws/). ## Import API specifications from Azure API Management You can import a specification from a connected Azure API Management service to an API in Postman. Importing a specification will create a new API in Postman and will also configure an integration with Azure API Management. Learn more about [integrating with Azure API Management](/docs/integrations/available-integrations/azure-api-management/deploying-an-api-azure/). To import an API specification from Azure API Management, do the following: 1. Click **Import** in the sidebar, then select **Other Sources > Azure API Management**. 2. You'll be prompted to authorize Postman to access your Microsoft Azure account. After you grant access, you can close the browser tab and return to Postman. 3. Enter information about the Azure API Management service you want to import a specification from: * **Subscription** - The [subscription](https://docs.microsoft.com/en-us/azure/api-management/api-management-subscriptions) where the service was created. * **Resource Group** - The [resource group](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-portal) that has the service. * **Service** - The Azure API Management [service instance](https://docs.microsoft.com/en-us/azure/api-management/api-management-key-concepts) used for deploying your API. * **Azure API Version** - The Azure API [version](https://docs.microsoft.com/en-us/azure/api-management/api-management-versions) you want to import. * **Definition type** - Select the specification for the specification you want to import (OpenAPI 2.0 or OpenAPI 3.0). * **API name** - The name to use for the new API that will be created in Postman using the imported specification. 4. Click **Import**. ## Supported API specifications formats Postman directly supports importing the following formats: * [OpenAPI 3.0 and 3.1](https://github.com/postmanlabs/openapi-to-postman) * Swagger [1.2](https://github.com/postmanlabs/swagger1-to-postman) and [2.0](https://github.com/postmanlabs/swagger2-postman2-lambda) * Protobuf 2 and 3 * [GraphQL](https://github.com/postmanlabs/graphql-to-postman) * [cURL](https://github.com/postmanlabs/curl-to-postman) * RAML [0.8](https://github.com/postmanlabs/raml-to-postman) and [1.0](https://github.com/postmanlabs/raml1-to-postman) * [WSDL 1.1 and 2.0](https://github.com/postmanlabs/wsdl-to-postman) * [HTTP Archive (HAR)](https://github.com/postmanlabs/har-to-postman) * Web Application Description Language (WADL) There are also tools on GitHub to convert different API specifications into a Postman Collection that can be imported: * [runscope-to-postman](https://github.com/postmanlabs/runscope-to-postman) * [DHC-to-postman](https://github.com/postmanlabs/dhc-to-postman) --- # Install and update Postman To get the latest version of the Postman desktop app, visit the [Download Postman page](https://www.postman.com/downloads/) and select the option for your operating system. Postman is available as a native desktop app for Windows (Intel 64-bit or ARM 64-bit), macOS (Intel or Apple silicon), and Linux (Intel 64-bit or ARM 64-bit). Postman is also available as a [web app](https://go.postman.co/home/). You can use the Postman web app to carry out many of your API development and testing tasks in your web browser. Keep in mind that some features aren't supported when using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#web-limitations), so use the Postman desktop app for the full Postman experience. ## Install Postman on Windows To install Postman on Windows, do the following: 1. [Download](https://www.postman.com/downloads/) the latest Postman version. 2. Select and run the .exe file to install Postman. ![Postman Desktop App Installation](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 1. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 2. Click **Add Members**. To be added, members need to be part of the organization. 3. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 4. Populate the team with the members who are responsible for the team’s contents. 5. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 6. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 7. Click **Create**. ![Create a Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 5. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 6. Click **Create**. ![Create a Component File](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Edit a Component File](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component in the left sidebar that you'd like to version and publish. 5. Click **Version & Publish** in the upper right corner. ![Version and Publish a Component File](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 1. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 2. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of a specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Link icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Reference a Component in a Specification](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team's shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. 4. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 5. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 6. Ensure the team is prepopulated with the appropriate roles. 7. Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two settings: * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. ![Create Organization Workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 1. Select the team in the left sidebar. 2. Select the workspace in the left sidebar. 3. Select the workspace in the left sidebar. 4. Select the workspace in the left sidebar. 5. Select the workspace in the left sidebar. 6. Select the workspace in the left sidebar. 7. Select the workspace in the left sidebar. 8. Select the workspace in the left sidebar. 9. Select the workspace in the left sidebar. 10. Select the workspace in the left sidebar. 11. Select the workspace in the left sidebar. 12. Select the workspace in the left sidebar. 13. Select the workspace in the left sidebar. 14. Select the workspace in the left sidebar. 15. Select the workspace in the left sidebar. 16. Select the workspace in the left sidebar. 17. Select the workspace in the left sidebar. 18. Select the workspace in the left sidebar. 19. Select the workspace in the left sidebar. 20. Select the workspace in the left sidebar. 21. Select the workspace in the left sidebar. 22. Select the workspace in the left sidebar. 23. Select the workspace in the left sidebar. 24. Select the workspace in the left sidebar. 25. Select the workspace in the left sidebar. 26. Select the workspace in the left sidebar. 27. Select the workspace in the left sidebar. 28. Select the workspace in the left sidebar. 29. Select the workspace in the left sidebar. 30. Select the workspace in the left sidebar. 31. Select the workspace in the left sidebar. 32. Select the workspace in the left sidebar. 33. Select the workspace in the left sidebar. 34. Select the workspace in the left sidebar. 35. Select the workspace in the left sidebar. 36. Select the workspace in the left sidebar. 37. Select the workspace in the left sidebar. 38. Select the workspace in the left sidebar. 39. Select the workspace in the left sidebar. 40. Select the workspace in the left sidebar. 41. Select the workspace in the left sidebar. 42. Select the workspace in the left sidebar. 43. Select the workspace in the left sidebar. 44. Select the workspace in the left sidebar. 45. Select the workspace in the left sidebar. 46. Select the workspace in the left sidebar. 47. Select the workspace in the left sidebar. 48. Select the workspace in the left sidebar. 49. Select the workspace in the left sidebar. 50. Select the workspace in the left sidebar. 51. Select the workspace in the left sidebar. 52. Select the workspace in the left sidebar. 53. Select the workspace in the left sidebar. 54. Select the workspace in the left sidebar. 55. Select the workspace in the left sidebar. 56. Select the workspace in the left sidebar. 57. Select the workspace in the left sidebar. 58. Select the workspace in the left sidebar. 59. Select the workspace in the left sidebar. 60. Select the workspace in the left sidebar. 61. Select the workspace in the left sidebar. 62. Select the workspace in the left sidebar. 63. Select the workspace in the left sidebar. 64. Select the workspace in the left sidebar. 65. Select the workspace in the left sidebar. 66. Select the workspace in the left sidebar. 67. Select the workspace in the left sidebar. 68. Select the workspace in the left sidebar. 69. Select the workspace in the left sidebar. 70. Select the workspace in the left sidebar. 71. Select the workspace in the left sidebar. 72. Select the workspace in the left sidebar. 73. Select the workspace in the left sidebar. 74. Select the workspace in the left sidebar. 75. Select the workspace in the left sidebar. 76. Select the workspace in the left sidebar. 77. Select the workspace in the left sidebar. 78. Select the workspace in the left sidebar. 79. Select the workspace in the left sidebar. 80. Select the workspace in the left sidebar. 81. Select the workspace in the left sidebar. 82. Select the workspace in the left sidebar. 83. Select the workspace in the left sidebar. 84. Select the workspace in the left sidebar. 85. Select the workspace in the left sidebar. 86. Select the workspace in the left sidebar. 87. Select the workspace in the left sidebar. 88. Select the workspace in the left sidebar. 89. Select the workspace in the left sidebar. 90. Select the workspace in the left sidebar. 91. Select the workspace in the left sidebar. 92. Select the workspace in the left sidebar. 93. Select the workspace in the left sidebar. 94. Select the workspace in the left sidebar. 95. Select the workspace in the left sidebar. 96. Select the workspace in the left sidebar. 97. Select the workspace in the left sidebar. 98. Select the workspace in the left sidebar. 99. Select the workspace in the left sidebar. 100. Select the workspace in the left sidebar. 101. Select the workspace in the left sidebar. 102. Select the workspace in the left sidebar. 103. Select the workspace in the left sidebar. 104. Select the workspace in the left sidebar. 105. Select the workspace in the left sidebar. 106. Select the workspace in the left sidebar. 107. Select the workspace in the left sidebar. 108. Select the workspace in the left sidebar. 109. Select the workspace in the left sidebar. 110. Select the workspace in the left sidebar. 111. Select the workspace in the left sidebar. 112. Select the workspace in the left sidebar. 113. Select the workspace in the left sidebar. 114. Select the workspace in the left sidebar. 115. Select the workspace in the left sidebar. 116. Select the workspace in the left sidebar. 117. Select the workspace in the left sidebar. 118. Select the workspace in the left sidebar. 119. Select the workspace in the left sidebar. 120. Select the workspace in the left sidebar. 121. Select the workspace in the left sidebar. 122. Select the workspace in the left sidebar. 123. Select the workspace in the left sidebar. 124. Select the workspace in the left sidebar. 125. Select the workspace in the left sidebar. 126. Select the workspace in the left sidebar. 127. Select the workspace in the left sidebar. 128. Select the workspace in the left sidebar. 129. Select the workspace in the left sidebar. 130. Select the workspace in the left sidebar. 131. Select the workspace in the left sidebar. 132. Select the workspace in the left sidebar. 133. Select the workspace in the left sidebar. 134. Select the workspace in the left sidebar. 135. Select the workspace in the left sidebar. 136. Select the workspace in the left sidebar. 137. Select the workspace in the left sidebar. 138. Select the workspace in the left sidebar. 139. Select the workspace in the left sidebar. 140. Select the workspace in the left sidebar. 141. Select the workspace in the left sidebar. 142. Select the workspace in the left sidebar. 143. Select the workspace in the left sidebar. 144. Select the workspace in the left sidebar. 145. Select the workspace in the left sidebar. 146. Select the workspace in the left sidebar. 147. Select the workspace in the left sidebar. 148. Select the workspace in the left sidebar. 149. Select the workspace in the left sidebar. 150. Select the workspace in the left sidebar. 151. Select the workspace in the left sidebar. 152. Select the workspace in the left sidebar. 153. Select the workspace in the left sidebar. 154. Select the workspace in the left sidebar. 155. Select the workspace in the left sidebar. 156. Select the workspace in the left sidebar. 157. Select the workspace in the left sidebar. 158. Select the workspace in the left sidebar. 159. Select the workspace in the left sidebar. 160. Select the workspace in the left sidebar. 161. Select the workspace in the left sidebar. 162. Select the workspace in the left sidebar. 163. Select the workspace in the left sidebar. 164. Select the workspace in the left sidebar. 165. Select the workspace in the left sidebar. 166. Select the workspace in the left sidebar. 167. Select the workspace in the left sidebar. 168. Select the workspace in the left sidebar. 169. Select the workspace in the left sidebar. 170. Select the workspace in the left sidebar. 171. Select the workspace in the left sidebar. 172. Select the workspace in the left sidebar. 173. Select the workspace in the left sidebar. 174. Select the workspace in the left sidebar. 175. Select the workspace in the left sidebar. 176. Select the workspace in the left sidebar. 177. Select the workspace in the left sidebar. 178. Select the workspace in the left sidebar. 179. Select the workspace in the left sidebar. 180. Select the workspace in the left sidebar. 181. Select the workspace in the left sidebar. 182. Select the workspace in the left sidebar. 183. Select the workspace in the left sidebar. 184. Select the workspace in the left sidebar. 185. Select the workspace in the left sidebar. 186. Select the workspace in the left sidebar. 187. Select the workspace in the left sidebar. 188. Select the workspace in the left sidebar. 189. Select the workspace in the left sidebar. 190. Select the workspace in the left sidebar. 191. Select the workspace in the left sidebar. 192. Select the workspace in the left sidebar. 193. Select the workspace in the left sidebar. 194. Select the workspace in the left sidebar. 195. Select the workspace in the left sidebar. 196. Select the workspace in the left sidebar. 197. Select the workspace in the left sidebar. 198. Select the workspace in the left sidebar. 199. Select the workspace in the left sidebar. 200. Select the workspace in the left sidebar. 201. Select the workspace in the left sidebar. 202. Select the workspace in the left sidebar. 203. Select the workspace in the left sidebar. 204. Select the workspace in the left sidebar. 205. Select the workspace in the left sidebar. 206. Select the workspace in the left sidebar. 207. Select the workspace in the left sidebar. 208. Select the workspace in the left sidebar. 209. Select the workspace in the left sidebar. 210. Select the workspace in the left sidebar. 211. Select the workspace in the left sidebar. 212. Select the workspace in the left sidebar. 213. Select the workspace in the left sidebar. 214. Select the workspace in the left sidebar. 215. Select the workspace in the left sidebar. 216. Select the workspace in the left sidebar. 217. Select the workspace in the left sidebar. 218. Select the workspace in the left sidebar. 219. Select the workspace in the left sidebar. 220. Select the workspace in the left sidebar. 221. Select the workspace in the left sidebar. 222. Select the workspace in the left sidebar. 223. Select the workspace in the left sidebar. 224. Select the workspace in the left sidebar. 225. Select the workspace in the left sidebar. 226. Select the workspace in the left sidebar. 227. Select the workspace in the left sidebar. 228. Select the workspace in the left sidebar. 229. Select the workspace in the left sidebar. 230. Select the workspace in the left sidebar. 231. Select the workspace in the left sidebar. 232. Select the workspace in the left sidebar. 233. Select the workspace in the left sidebar. 234. Select the workspace in the left sidebar. 235. Select the workspace in the left sidebar. 236. Select the workspace in the left sidebar. 237. Select the workspace in the left sidebar. 238. Select the workspace in the left sidebar. 239. Select the workspace in the left sidebar. 240. Select the workspace in the left sidebar. 241. Select the workspace in the left sidebar. 242. Select the workspace in the left sidebar. 243. Select the workspace in the left sidebar. 244. Select the workspace in the left sidebar. 245. Select the workspace in the left sidebar. 246. Select the workspace in the left sidebar. 247. Select the workspace in the left sidebar. 248. Select the workspace in the left sidebar. 249. Select the workspace in the left sidebar. 250. Select the workspace in the left sidebar. 251. Select the workspace in the left sidebar. 252. Select the workspace in the left sidebar. 253. Select the workspace in the left sidebar. 254. Select the workspace in the left sidebar. 255. Select the workspace in the left sidebar. 256. Select the workspace in the left sidebar. 257. Select the workspace in the left sidebar. 258. Select the workspace in the left sidebar. 259. Select the workspace in the left sidebar. 260. Select the workspace in the left sidebar. 261. Select the workspace in the left sidebar. 262. Select the workspace in the left sidebar. 263. Select the workspace in the left sidebar. 264. Select the workspace in the left sidebar. 265. Select the workspace in the left sidebar. 266. Select the workspace in the left sidebar. 267. Select the workspace in the left sidebar. 268. Select the workspace in the left sidebar. 269. Select the workspace in the left sidebar. 270. Select the workspace in the left sidebar. 271. Select the workspace in the left sidebar. 272. Select the workspace in the left sidebar. 273. Select the workspace in the left sidebar. 274. Select the workspace in the left sidebar. 275. Select the workspace in the left sidebar. 276. Select the workspace in the left sidebar. 277. Select the workspace in the left sidebar. 278. Select the workspace in the left sidebar. 279. Select the workspace in the left sidebar. 280. Select the workspace in the left sidebar. 281. Select the workspace in the left sidebar. 282. Select the workspace in the left sidebar. 283. Select the workspace in the left sidebar. 284. Select the workspace in the left sidebar. 285. Select the workspace in the left sidebar. 286. Select the workspace in the left sidebar. 287. Select the workspace in the left sidebar. 288. Select the workspace in the left sidebar. 289. Select the workspace in the left sidebar. 290. Select the workspace in the left sidebar. 291. Select the workspace in the left sidebar. 292. Select the workspace in the left sidebar. 293. Select the workspace in the left sidebar. 294. Select the workspace in the left sidebar. 295. Select the workspace in the left sidebar. 296. Select the workspace in the left sidebar. 297. Select the workspace in the left sidebar. 298. Select the workspace in the left sidebar. 299. Select the workspace in the left sidebar. 300. Select the workspace in the left sidebar. 301. Select the workspace in the left sidebar. 302. Select the workspace in the left sidebar. 303. Select the workspace in the left sidebar. 304. Select the workspace in the left sidebar. 305. Select the workspace in the left sidebar. 306. Select the workspace in the left sidebar. 307. Select the workspace in the left sidebar. 308. Select the workspace in the left sidebar. 309. Select the workspace in the left sidebar. 310. Select the workspace in the left sidebar. 311. Select the workspace in the left sidebar. 312. Select the workspace in the left sidebar. 313. Select the workspace in the left sidebar. 314. Select the workspace in the left sidebar. 315. Select the workspace in the left sidebar. 316. Select the workspace in the left sidebar. 317. Select the workspace in the left sidebar. 318. Select the workspace in the left sidebar. 319. Select the workspace in the left sidebar. 320. Select the workspace in the left sidebar. 321. Select the workspace in the left sidebar. 322. Select the workspace in the left sidebar. 323. Select the workspace in the left sidebar. 324. Select the workspace in the left sidebar. 325. Select the workspace in the left sidebar. 326. Select the workspace in the left sidebar. 327. Select the workspace in the left sidebar. 328. Select the workspace in the left sidebar. 329. Select the workspace in the left sidebar. 330. Select the workspace in the left sidebar. 331. Select the workspace in the left sidebar. 332. Select the workspace in the left sidebar. 333. Select the workspace in the left sidebar. 334. Select the workspace in the left sidebar. 335. Select the workspace in the left sidebar. 336. Select the workspace in the left sidebar. 337. Select the workspace in the left sidebar. 338. Select the workspace in the left sidebar. 339. Select the workspace in the left sidebar. 340. Select the workspace in the left sidebar. 341. Select the workspace in the left sidebar. 342. Select the workspace in the left sidebar. 343. Select the workspace in the left sidebar. 344. Select the workspace in the left sidebar. 345. Select the workspace in the left sidebar. 346. Select the workspace in the left sidebar. 347. Select the workspace in the left sidebar. 348. Select the workspace in the left sidebar. 349. Select the workspace in the left sidebar. 350. Select the workspace in the left sidebar. 351. Select the workspace in the left sidebar. 352. Select the workspace in the left sidebar. 353. Select the workspace in the left sidebar. 354. Select the workspace in the left sidebar. 355. Select the workspace in the left sidebar. 356. Select the workspace in the left sidebar. 357. Select the workspace in the left sidebar. 358. Select the workspace in the left sidebar. 359. Select the workspace in the left sidebar. 360. Select the workspace in the left sidebar. 361. Select the workspace in the left sidebar. 362. Select the workspace in the left sidebar. 363. Select the workspace in the left sidebar. 364. Select the workspace in the left sidebar. 365. Select the workspace in the left sidebar. 366. Select the workspace in the left sidebar. 367. Select the workspace in the left sidebar. 368. Select the workspace in the left sidebar. 369. Select the workspace in the left sidebar. 370. Select the workspace in the left sidebar. 371. Select the workspace in the left sidebar. 372. Select the workspace in the left sidebar. 373. Select the workspace in the left sidebar. 374. Select the workspace in the left sidebar. 375. Select the workspace in the left sidebar. 376. Select the workspace in the left sidebar. 377. Select the workspace in the left sidebar. 378. Select the workspace in the left sidebar. 379. Select the workspace in the left sidebar. 380. Select the workspace in the left sidebar. 3 --- # interact Use Postman to interact with your generated MCP server and an AI model ==================================================================== You can use Postman to interact with your generated MCP server locally and an AI model of your choice. ## Interact with your MCP server and an AI model To interact with your MCP server and an AI model, do the following: 1. If you haven't already, [set up and start your MCP server](/docs/postman-ai/mcp-servers/set-up-start/). 2. [Create a new MCP request](/docs/postman-ai/mcp-requests/create/#create-a-new-mcp-request) and [save it to a collection](/docs/postman-ai/mcp-requests/create/#save-your-new-mcp-request). When you're prompted, choose your server's communication method: - To interact with your [standard input and output](https://modelcontextprotocol.io/docs/concepts/transports#standard-input%2Foutput-stdio) server, choose **STDIO** and enter your server's command. For example, enter: ```bash node /path/to/your-mcp-server/mcpServer.js ``` - To interact with your [streamable HTTP](https://modelcontextprotocol.io/docs/concepts/transports#streamable-http) server, choose **HTTP** and enter your server's local URL. For example, enter: ```bash http://localhost:3001/mcp ``` 3. [Use your MCP request to interact with your MCP server](/docs/postman-ai/mcp-requests/interact/). You can use your request to experiment, test, and evaluate your MCP server. 4. [Create a new AI request](/docs/postman-ai/ai-requests/create/#create-a-new-ai-request) and [save it to a collection](/docs/postman-ai/ai-requests/create/#save-your-new-ai-request). Save your new AI request to the same workspace you saved your MCP request. 5. [Add your MCP request to your AI request](/docs/postman-ai/ai-requests/add-mcp-servers/#add-the-mcp-server). When you're prompted, enter your server's command (STDIO) or URL (streamable HTTP), and search for the MCP request you created in the previous steps. 6. [Use your AI request to interact with your MCP server](/docs/postman-ai/ai-requests/interact/). You can use your request to experiment, test, and evaluate AI models. To learn more, see [Create MCP requests and add them to your collections](/docs/postman-ai/mcp-requests/overview/) and [Create AI requests and add them to your collections](/docs/postman-ai/ai-requests/overview/). --- ### Postman Vault Integrations **[Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/)** enable you to link vault secrets with secrets that are stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of external vault secrets using end-to-end encryption when you send HTTP requests. You can [manage and update](#manage-local-secret-protection) your Postman Vault integrations. **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. **Note:** This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: - To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. - To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). --- ### Organization Settings **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **Note:** The organization manager (or super admin) creates a Team and assigns a Team Manager to it. The Team Manager is the delegated owner of the Team's content and manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). **Team Members** can approve the adding of Members and the sharing of content from the Teams they manage. **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ## Team Roles Each team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the structure of your teams and memberships, do the following: 1. The **Organization Manager (or Super Admin)** creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two settings: - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. - If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. - If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. **Notes:** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. **To migrate your teams to Organizations, contact your Customer Success Manager.** Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Create Organization Teams To create an Organization Team, do the following: 1. Access **Organization Settings** in the Postman header, then select **Organization Teams** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. **Notes:** - If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. - You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) relationship. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization Workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the **Home** page, click **Teams** and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit Workspace Details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### Organization Roles **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **Organization Managers** are responsible for creating Teams in the Organization and can manage any Team. They're also responsible for assigning individual Team Managers to the teams they create. **Team Managers** can approve the adding of Members and the sharing of content from the Teams they manage. **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ## Team Roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | - Has edit access to all elements within the Team and the capability to edit the Team's Settings. - Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | - Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. - Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. - Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | - Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. - Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | **Notes:** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. **To migrate your teams to Organizations, contact your Customer Success Manager.** Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Create Organization Teams To create an Organization Team, do the following: 1. Access **Organization Settings** in the Postman header, then select **Organization Teams** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. **Notes:** - If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. - You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) relationship. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization Workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the **Home** page, click **Teams** and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit Workspace Details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### Organization Settings **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **Organization Managers** are responsible for creating Teams in the Organization and can manage any Team. They're also responsible for assigning individual Team Managers to the teams they create. **Team Managers** can approve the adding of Members and the sharing of content from the Teams they manage. **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ## Team Roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | - Has edit access to all elements within the Team and the capability to edit the Team's Settings. - Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | - Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. - Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. - Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | - Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. - Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | **Notes:** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. **To migrate your teams to Organizations, contact your Customer Success Manager.** Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Create Organization Teams To create an Organization Team, do the following: 1. Access **Organization Settings** in the Postman header, then select **Organization Teams** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. **Notes:** - If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. - You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) relationship. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization Workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the **Home** page, click **Teams** and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit Workspace Details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### Organization Settings **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **Organization Managers** are responsible for creating Teams in the Organization and can manage any Team. They're also responsible for assigning individual Team Managers to the teams they create. **Team Managers** can approve the adding of Members and the sharing of content from the Teams they manage. **Collaborators** can be brought into the team as secondary contributors or consumers. For example, collaborators can be QA teams supporting the team's activities, consumers of the team's APIs, or an entire Organization. On teams that don't require approval, Collaborators can be added automatically. On teams that require approval, an Admin must approve the addition of Collaborators to keep parts of the team private while others are shared. ## Team Roles Each team within an Organization has its own set of independent roles: | Team role | Capabilities | | -------- | ---- | | Team Manager (Team Super Admin) | - Has edit access to all elements within the Team and the capability to edit the Team's Settings. - Manages the entire Team, including the users (add/remove/invite/assign) and the resources (view/edit/manage). | | Team Member | - Can have edit access to all elements on the Team, but doesn't automatically have access to workspaces, collections, and other elements within the Team unless given a role on that element. - Can view all resources shared throughout the Team and can have Editor or Viewer access to any workspace or resource within the Team. - Automatically gets access to all workspaces that are shared to the team when the workspace is set to **Everyone in [TeamName]**. | | Collaborator | - Can have a Developer or Viewer role. Developers can directly edit the element they're assigned, while Viewers can only view or fork the element they're assigned. Additionally, workspaces that are shared with the Team in the **Workspace Access** settings aren't automatically shared with Collaborators. - Has to be granted access to workspaces either by setting the workspace to **Everyone in [OrgName]** or by being invited directly through a user or a Team or Group they belong to. | **Notes:** - Only a Team Member can create workspaces in the team. - Sharing an element with a new user triggers the process of adding that user to the Team's user list. - Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. **To migrate your teams to Organizations, contact your Customer Success Manager.** Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) --- ### Create Organization Teams To create an Organization Team, do the following: 1. Access **Organization Settings** in the Postman header, then select **Organization Teams** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. **Notes:** - If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. - You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/) relationship. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) ## Create Organization Workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the **Home** page, click **Teams** and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit Workspace Details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). --- ### Organization Settings **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by --- # intro-monitors Monitor health and performance of your APIs in Postman ==================================================== _Postman Monitors_ enable you to [continuously check the health and performance of your APIs](https://www.postman.com/api-platform/api-observability/). You can create monitors that run requests in selected collections. Requests can run API test scripts, chain together multiple requests, and more. You can also schedule how often Postman runs monitored collections. You'll be alerted to any test failures once the monitor is running, so you can identify and address issues before your API's consumers are affected. ## About Postman Monitors You can [set up monitors](/docs/monitoring-your-api/setting-up-monitor/), enabling you to run a series of requests from the Postman cloud based on a schedule. When creating a monitor, you choose a [collection](/docs/sending-requests/create-requests/intro-to-collections/) with the requests you want to run. You can learn more about [use cases for monitors](#monitor-use-cases). With [Private API Monitoring](/docs/monitoring-your-api/runners/overview/), you can use runners and the Postman CLI to monitor and test your organization's APIs from your internal network, without publicly exposing your endpoints. Once set up, monitors run in your internal network and the runner sends the results to the Postman cloud. You can also [configure monitors to run from static IPs](/docs/monitoring-your-api/using-static-IPs-to-monitor/) to monitor APIs that are behind a restricted firewall. You can [view results for monitors](/docs/monitoring-your-api/viewing-monitor-results/) to learn more about the monitors you're running. You can also [manage your team's monitor usage](/docs/monitoring-your-api/monitor-usage/), enabling you to track your team's resource usage and purchase more blocks of monitoring calls. If you experience a problem with monitors, you can [troubleshoot monitors in Postman](/docs/monitoring-your-api/troubleshooting-monitors/). ## Monitor use cases Monitors run Postman requests and scripts, enabling you to [monitor APIs](https://www.postman.com/api-platform/api-monitoring/) in a variety of ways. The following are examples of what you can check with monitors: * **Check API health and performance** - Ensure the API is up and running in production and other environments. * **Validate API response structure and data** - Ensure the API is functioning according to specifications. * **Test complex, multi-step workflows** - Ensure that critical API flows and edge cases are working as expected. * **Run tests in multiple environments and regions** - Ensure your APIs are working everywhere. (Running monitors in multiple regions requires a paid Postman plan.) * **Monitor the security of your endpoints** - Continuously test APIs for known security vulnerabilities. * **Visualize results on the monitor dashboard** - Get better visibility into API performance over time and identify trends. For more examples of monitors in action, visit the [Postman API Monitoring Examples public workspace](https://www.postman.com/postman/postman-api-monitoring-examples/overview) to find example collections for some common monitoring use cases. You can collaborate on the collections in the workspace by [creating a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork), or customize the collections for your team's use by [exporting and importing them into your internal workspace](/docs/getting-started/importing-and-exporting/exporting-data/#export-collections). ## Monitor FAQs To learn more about configuring monitors in Postman, see the [Monitor FAQs](/docs/monitoring-your-api/faqs-monitors/). --- # Intro to SSO **[SSO is available with Postman Enterprise plans.](https://www.postman.com/pricing/)** Single sign-on (SSO) services enable you to manage your team’s identity across all the SaaS products that you use. With an SSO service, a user can access multiple applications using one set of credentials (for example, an email address and password). The SSO service authenticates the user once for all the applications the user has been given rights to and eliminates further prompts when the user switches applications during the same session. An example of SSO is Google's sign-in implementation for products like Gmail, YouTube, and Google Drive. Any user who is signed in to one of Google's products is automatically signed in to their other products as well. ## What are the advantages of SSO? * Removes the need for users to remember and manage multiple passwords. * Simplifies users’ experience by enabling them to sign in at a single access point and work seamlessly across multiple applications. * Increases productivity by reducing the password-related support emails. * Reduces phishing attempts that try to trick users into giving away sensitive information. ## Prerequisites for SSO with Postman * Team’s identity provider (IdP) must support the SAML 2.0 standard. ## Supported IdPs * [Microsoft AD FS](/docs/administration/sso/microsoft-adfs/) * [Microsoft Entra ID](/docs/administration/sso/azure-ad/) * [Custom SAML](/docs/administration/sso/custom-saml/) * [Duo](/docs/administration/sso/duo/) * [Google Workspace](/docs/administration/sso/google-workspace/) * [Okta](/docs/administration/sso/okta/) * [OneLogin](/docs/administration/sso/onelogin/) * [Ping Identity](/docs/administration/sso/ping-identity/) ## SSO setup for SAML 2.0 compliant IdPs Most SAML 2.0 compliant identity providers require the same information about the service provider for setup (Postman is the service provider). These values are specific to a Postman team and are available while [configuring SSO](/docs/administration/sso/admin-sso/). While configuring your IdP, make sure to set your users' email address in SAML attributes and claims. Postman expects to receive an email address from your IdP to identify each user. If you configure SSO, Postman Password, Google OAuth 2.0, and GitHub authentication methods remain enabled for your team. You can turn off these authentication methods to allow your team to sign in using SSO only. ## Learn more To learn more about SSO and SCIM, see the following: * [Sign in to an SSO team](/docs/administration/sso/user-sso/) - How to sign in and use SSO when it’s enabled for your team. * [Configure SSO for a team](/docs/administration/sso/admin-sso/) - How Team Admins can enable and configure SSO for team users. * [SCIM (System for Cross-domain Identity Management) provisioning](/docs/administration/scim-provisioning/scim-provisioning-overview/) - How Team Admins can use SCIM to automate user provisioning and de-provisioning for a team. * [SSO and SCIM FAQs](/docs/administration/sso/sso-faqs/) - Frequently asked questions on configuring SSO and SCIM. --- # Test your API using the Collection Runner Send some or all of the API requests in a Postman Collection in the order you choose with the _Collection Runner_. The Collection Runner logs the [test results](/docs/tests-and-scripts/write-scripts/test-scripts/) for each request, and it can use [scripts](/docs/tests-and-scripts/write-scripts/intro-to-scripts/) to pass data between requests and change the request workflow. Use collection runs to automate your functional API testing. You can run collections manually, or schedule collection runs in the Postman cloud with the [Collection Runner](/docs/collections/running-collections/scheduling-collection-runs/) or [monitors](/docs/collections/running-collections/scheduling-collection-runs-monitors/). You can also integrate collection runs with your CI/CD pipeline using [the Postman CLI](/docs/postman-cli/postman-cli-overview/), Postman's command line tool. ## Configure a collection run You can manually run the requests in a [collection](/docs/collections/use-collections/create-collections/) or a [folder](/docs/collections/use-collections/manage-collections/#add-folders-to-a-collection). 1. Click **Collections** in the sidebar and select the collection or folder you want to run. > You can also run a collection or folder that's linked to an API. Learn more about [adding a collection to an API](/docs/design-apis/api-builder/develop-apis/adding-api-elements/#add-a-collection-to-your-api). 2. Click ![Image 1: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. ![Image 2: Click Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) > You can also click ![Image 3: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Runner** from the Postman footer. Drag a collection from the sidebar into the Collection Runner. Or click **start with a template** to create a new collection with example tests you can run. 3. On the **Functional** tab, click **Run manually**. > You can also [schedule runs](/docs/collections/running-collections/scheduling-collection-runs/) and [automate runs with the Postman CLI](/docs/postman-cli/postman-cli-run-collection/). 4. If you want your collection to run with an [environment](/docs/sending-requests/variables/managing-environments/), select it using the environment selector at the upper right of Postman. You can also click **Environments** in the sidebar, then select the environment you want to use. 5. Choose any configuration options: * **Iterations** - The number of times to run the collection. You can also run collections multiple times with different data sets to [build workflows](/docs/collections/running-collections/building-workflows/). * **Delay** - An interval delay before each request, in milliseconds. * **Test data file** - Upload or select an existing [data file](/docs/collections/running-collections/working-with-data-files/) for the collection run. You can select a data file that was previously uploaded, or you can select a local data file. * **Advanced settings** * **Persist responses for a session** - By default, response headers and bodies are persisted so you can [review them after running the collection](#debug-run-results). Request and response bodies are persisted only if they're less than 300 KB in size. Your browser or computer may not have enough memory available to persist responses for large collection runs. It's recommended that you use the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to store a larger amount of request and response data using your computer's disk space. Learn how to [troubleshoot a large collection run](#troubleshoot-large-collection-runs). Request and response details are persisted locally during your current Postman session and aren't saved permanently. Signing out of Postman, signing into another device with the same account, or refreshing your browser will end your session and remove the logged data. Response and request details are available for the user who started the collection run. Other team members can't view details for collection runs that you start. * **Turn off logs during run** - Turn off logging to the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/#debugging-in-the-console) during the collection run. Request and response details such as method, URL, headers, and body won't be logged to the Postman Console. Also, all [log statements](/docs/sending-requests/response-data/troubleshooting-api-requests/#using-log-statements) in scripts will be ignored. Selecting this option may improve performance of the Postman app during large collection runs. You can still view request and response details from the [run results](#debug-run-results). * **Stop run if an error occurs** - By default, the collection run stops if an exception is encountered within a script or if there's a problem sending a request. Clear this checkbox if you want the collection run to continue after an error occurs. * **Keep variable values** - Persist the variables used in the run, so that any variables updated by the run will remain changed after it completes. If you don't persist variables, changes aren't saved after the run completes. Persisting variables in the collection run will update the local value and not the shared value of variables. * **Run collection without using stored cookies** - If your requests use [cookies](/docs/sending-requests/response-data/cookies/), you can optionally deactivate them for a collection run. * **Save cookies after collection run** - Save the cookies used in this session to the [cookie manager](/docs/sending-requests/response-data/cookies/#use-the-cookie-manager). Any values changed by requests during the run will remain after it completes. 6. By default, your requests run in the sequence they're listed in the collection. If you need to change the order in which the requests run, select and drag a request to its new location in the order. You can remove an individual request from the run by clearing the checkbox next to its name. You can also press **Shift** and then click a range of requests' checkboxes to add or remove them from the collection run. > You can change the order of requests during a collection run from your request scripts using the `pm.execution.setNextRequest()` function. To learn more, see [Customize request order in a collection run](/docs/collections/running-collections/building-workflows/). 7. When you've completed your configuration, click **Run (collection name)**. ![Collection Runner configuration](https://assets.postman.com/postman-docs/v11/collection-run-configuration-v11-35.jpg) > Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of collection runs you can use each month. This limit applies to collections that you run in a workspace using the **Run manually** option, but it doesn't apply to [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/) in the Postman cloud. A collection run with multiple iterations counts as a single run. > > A message will display in the Collection Runner when you're approaching your usage limit. Learn more about [resource usage](/docs/billing/resource-usage/) in Postman. > > A Postman plan gives you a limited number of collection runs you can use each month. This limit applies to collections that you run in a workspace using the **Run manually** option, but it doesn't apply to [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/) in the Postman cloud. A collection run with multiple iterations counts as a single run. > > A message will display in the Collection Runner when you're approaching your usage limit. Learn more about [resource usage](/docs/billing/resource-usage/) in Postman. ## Debug run results When running collections manually, Postman displays the results of your request runs in real time. This includes test results, errors, and any failed test assertions. You can view the source of the collection run, selected environment, number of iterations, total duration, number of tests, number of errors, and average response time. ![Collection Runner results](https://assets.postman.com/postman-docs/v11/intro-to-collection-runs-debug-v11-76.png) To learn more about what happened during the collection run, do any of the following: ### Test results * Click anywhere in the run results page and scroll through the list with the following keys and keyboard shortcuts: | Action | **macOS** | **Windows** | |--------------|-----------------------------------------------------|-----------------| | Home | **Fn + Left Arrow** or **⌘ + Up Arrow** | **Home** | | End | **Fn + Right Arrow** or **⌘ + Up Arrow** | **End** | | Page Up | **Fn + Up Arrow** | **Page Up** | | Page Down | **Fn + Down Arrow** | **Page Down** | * Click a request to view details about the request. You can view general information about the request and the request headers and body. You can also view the response headers and body if the **Persist responses for a session** checkbox was selected when [configuring the collection run](#configure-a-collection-run). * Click the name of a request to open the request in a new tab. You can view any post-response scripts or click **Send** to send the request again. * If your requests are in a folder, click the name of the folder to open it in a new tab. * If your collection run included more than one iteration, click an iteration number to jump to the results of a specific iteration. * Hover over the response status code next to a request to show the full status code and a description. * Click the **Console Log** tab to view script-level console messages grouped by request. Badges identify each message as a log, info, warning, or error message. * If your collection run included more than one iteration, click an iteration number to jump to the results of a specific iteration. * Click **View all runs** to view a list of past runs. Learn more about [viewing run history](#view-run-history). * Click **View Summary** to view a summary of the collection run, including test results. To return to the full results, click **View Results**. ### Errors * Click the **Errors** tab to filter results by requests that encountered errors. Note that _errors_ indicate runtime issues like timeout or TLS handshake errors. _Failed_ requests occur when one or more user-specified checks (like post-request scripts) don't match expectations. * The requests in your collection run that have errors appear in the run results page with an error badge and the error message. Badges identify errors as related to **NETWORK**, **REQUEST**, or **SCRIPT** issues. ![Collection Runner errors](https://assets.postman.com/postman-docs/v11/collection-run-errors-v11-76-7.png) ### Sharing and commenting * Click **Share** in the upper right to share the results with another team member. This provides a link you can give to other team members to view the details of this run. You can also click ![Image 10: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite people** to [invite teammates to your workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). If you're in an internal workspace only you can access, you can click **Invite people** to invite teammates to your workspace and then share the results. * Click ![Image 11: Comments icon](https://assets.postman.com/postman-docs/aether-icons/action-comments-stroke.svg#icon) **Comments** in the right sidebar and enter your comment. Click **Comment** to share your comment with your team. Learn more about [adding comments](/docs/collaborating-in-postman/comments/#global-comments). ![Collection Runner summary](https://assets.postman.com/postman-docs/v11/collection-run-summary-v11-60.jpg) ## Delete a collection run To delete a collection run, click ![Image 12: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** in the upper right and click ![Image 13: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. Click **Delete** to confirm. You can run collections with scripts that import packages from your team's [Postman Package Library](/docs/tests-and-scripts/write-scripts/packages/package-library/). Learn how to [add packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#add-a-package) to the package library, and [import packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#import-a-package) into your scripts. You can also run collections that [import external packages](/docs/tests-and-scripts/write-scripts/packages/external-package-registries/) from npm or JSR package registries. ### Run the collection again After reviewing the results of the collection run, you can run the collection again. For example, you can edit the code for a failed test and run the collection again to check if the test succeeds. To run the collection again from the run results, do one of the following: * Click ![Image 14: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run Again** to run the collection again using the same settings. * Click ![Image 15: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **New Run** to configure a new run for the collection. Make changes to any settings, and then select **Run (collection name)** to run the collection again. * Click ![Image 16: Code block icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-codeBlock-stroke.svg#icon) **Automate Run** to automate runs for the collection. You can [schedule a run](/docs/collections/running-collections/scheduling-collection-runs/), [run using the Postman CLI](/docs/postman-cli/postman-cli-run-collection/#run-a-collection-locally-with-the-postman-cli), or [integrate runs with your CI/CD pipeline](/docs/postman-cli/postman-cli-run-collection/#run-a-collection-in-cicd). If you changed the selection or order of requests, or any other settings, the custom order and configuration are saved with the run results. To run the collection again later using your custom configuration, select the **Runs** tab in the collection to [view past runs](#view-past-runs). Click ![Image 17: Report icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-report-stroke.svg#icon) **View Report** next to a run to open the collection run results. From here you can click ![Image 18: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run Again** to run the collection again using the same settings. For more help troubleshooting a large collection run, [contact Postman support](https://www.postman.com/support/) with log files attached to your request. Learn how to [locate Postman logs](/docs/introduction/troubleshooting-inapp/#locating-postman-logs). ## Troubleshoot large collection runs A collection run may be large if it has many requests, its requests and responses are large in size, or the number of its iterations is high. Your browser or computer may run out of memory during large collection runs, reducing the performance of your collection runs. You may be able to use the Postman web app for large collection runs with some configuration changes. For improved performance, it's recommended that you use the Postman desktop app for large collection runs. The Postman desktop app uses your computer's disk space, making more memory available during larger collection runs. If you're using the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app) with large collection runs, you can take the following actions to make more memory available in your browser and improve the performance of your collection runs: * Deselect the **Persist responses for a session** checkbox when [configuring the collection run](#configure-a-collection-run). * Select the **Turn off logs during run** checkbox when [configuring the collection run](#configure-a-collection-run). If you're using the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) with large collection runs, you can take the following actions to make more memory available in your computer and improve the performance of your collection runs: * Deselect the **Persist responses for a session** checkbox when [configuring the collection run](#configure-a-collection-run). * Clear your local data and restart Postman. Open the Postman desktop app, click **Help** in your computer's menu bar, then click **Clear Cache and Reload**. * Free up disk space on your computer. * Select the **Turn off logs during run** checkbox when [configuring the collection run](#configure-a-collection-run). * If the collection run has many requests, break up the requests into multiple smaller collections and run them separately. * Reduce the number of iterations for the collection run when [configuring the collection run](#configure-a-collection-run). When using the Postman desktop app during a large collection run, you may be unable to persist responses if your computer runs out of memory during the collection run. Postman may delete responses persisted earlier to create space for new persisted responses. You'll be notified from the run results if memory was exhausted during the collection run. You can click **Retry Run** in the notification to run the collection again using the same settings. For more help troubleshooting a large collection run, [contact Postman support](https://www.postman.com/support/) with log files attached to your request. Learn how to [locate Postman logs](/docs/introduction/troubleshooting-inapp/#locating-postman-logs). ## Export collection runs You can share collection run results with others by exporting the results from the Collection Runner. The option to export a collection run report is available in the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) but not in the Postman web app. To export a collection run, do the following: 1. Open the collection run in the **Collection Runner**. You can also access the collection run using **History** in the sidebar if you don't have the run open. 2. Click ![Image 19: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** in the upper right and click ![Image 20: Export icon](https://assets.postman.com/postman-docs/aether-icons/action-export-stroke.svg#icon) **Export Results** to download the collection run. 3. Choose a location to save your downloaded collection run, then click **Save**. You can import the results of a collection run that was exported to a file. Click ![Image 21: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Runner** from the Postman footer and drag the exported file into the Collection Runner. ## View run history Each collection has a **Runs** tab you can use to view past functional runs, scheduled runs, and performance runs. You can also view details such as test counts and average response times. ![Past runs tab](https://assets.postman.com/postman-docs/v11/collection-run-tab-v11-57.jpg) ### View past runs The **Functional** tab has controls to select how many recent collection runs to view. You can filter the displayed runs by user, by run status, and by source (Collection Runner or Postman CLI). The following are displayed for each collection run: * A checkbox for each run and an option to select all runs. Select one or more collection runs and click **Delete** to remove them. * The start time of the collection run. * The run source, duration, all tests, passed tests, failed tests, skipped tests, and the average response time. Click any of these items to sort the table by that item. Click again to change the sort order. * Total number of comments your teammates shared about the collection run. Click ![Image 22: Comments icon](https://assets.postman.com/postman-docs/aether-icons/action-comments-stroke.svg#icon) **(number of comments)** to go to the run results and open the comments in the sidebar. Hover over an item to show the following options: * ![Image 23: Report icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-report-stroke.svg#icon) **View Report** - Click to open the full results for the collection run. Learn more about [debugging run results](#debug-run-results). * ![Image 24: Share icon](https://assets.postman.com/postman-docs/aether-icons/action-share-stroke.svg#icon) **Share** - Click to share the results with another team member. This provides a link you can give to other team members to view the details of this run. You can also click ![Image 25: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite people** to [invite teammates to your workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). If you're in an internal workspace only you can access, you can click **Invite people** to invite teammates to your workspace and then share the results. ### View scheduled runs The **Scheduled** tab shows all the scheduled runs for the current collection. The following are displayed for each scheduled run: * The upcoming run's scheduled time * The name of the scheduled run * The environment associated with the scheduled run (if any) Hover over an item to show the following controls: * **View** - Click to open a page detailing the scheduled collection run's latest results. * ![Image 26: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** - Click to [pause, resume, edit, or delete](/docs/collections/running-collections/scheduling-collection-runs/#pause-or-resume-a-scheduled-run) the schedule. ### View performance runs The **Performance** tab shows past [performance runs](/docs/collections/performance-testing/performance-test-configuration/) for the collection. You can view metrics for each run, including the number of virtual users (VUs), duration, total number of requests, requests per second, average response time, and error rate. Click a run to view a graph and full details for the performance run. Learn more about [viewing performance metrics](/docs/collections/performance-testing/performance-test-metrics/). ## Automate collection runs In addition to running collections manually, you can [schedule collections](/docs/collections/running-collections/scheduling-collection-runs/) to run automatically at specified times in the Postman cloud. You can also use collection runs with other Postman utilities to build automation into your API projects: * Use the [Postman CLI](/docs/postman-cli/postman-cli-overview/) command-line interface to run collections and build them into your development pipeline, responding to test outcomes to support your API performance. * You can also use [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/) to run collections from the command line. * Adding a [monitor](/docs/monitoring-your-api/intro-monitors/) to your collection lets you schedule collection runs and stay informed of any issues. * You can also set up a [collection webhook](/docs/collections/running-collections/collection-webhooks/) to trigger a collection run at a specific time with your own custom payload. ## Next steps Build on the Collection Runner fundamentals you've learned with the following topics: * Use scripts to build workflows with conditional sequences for running the requests in your collections. To learn more, go to [Customize request order in a collection run](/docs/collections/running-collections/building-workflows/). * Run your collections on a schedule to automatically test the functionality of your APIs. To learn more, go to [Automate collection runs on a schedule](/docs/collections/running-collections/scheduling-collection-runs/). * Use the Collection Runner to test the performance of your API with the same requests, collections, and environments you use for functional API tests. To learn more, go to [Simulate user traffic to test your API performance](/docs/collections/performance-testing/testing-api-performance/). --- # intro-to-collections Group API requests with Postman Collections =========================================== _Postman Collections_ enable you to group together your API requests and examples. You can use collections to keep your workspace organized, collaborate with teammates, and generate API documentation and API tests. You can also use collections to automate request runs as part of your API testing efforts. Select **Collections** in the sidebar to view a list of collections in your current workspace. ![Collections selected in the sidebar](https://assets.postman.com/postman-docs/v11/search-collections-v11.png) * To learn more about collections, go to [Organize and automate API requests in Postman Collections](/docs/collections/collections-overview/). * To create and work with collections, go to [Create and manage request collections in Postman](/docs/collections/use-collections/use-collections-overview/). * To learn how to use the Collection Runner, visit [Test your API functionality](/docs/collections/running-collections/running-collections-overview/). ### Table of Contents * [Introduction](#introduction) * [Getting Started](#getting-started) * [Using Collections](#using-collections) * [Troubleshooting](#troubleshooting) ### Introduction Postman's collections enable you to group together your API requests and examples. You can use collections to keep your workspace organized, collaborate with teammates, and generate API documentation and API tests. You can also use collections to automate request runs as part of your API testing efforts. ### Getting Started To get started with creating a collection from an imported API, connect your API to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your API to Postman](#connect-your-azure-api-gateway-to-postman). ### Using Collections To create a collection from an imported API, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 5. Click **Next**. 6. Select the **Type** dropdown list. 7. Select **Internal** for workspace type. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ### Troubleshooting Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, Team Admins can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When enabled, Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the Postman Vault. The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is **No policy** or **Move to vault** for the **Public**, **Partner**, and **Internal** workspace types. ### Update Secret Protection Policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ### View Secret Scan Metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ### Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the **default storage policy** to **Move to vault** to automatically move detected secrets to the Postman Vault. Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Manage Workspace Scan Policies Use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their **visibility**: * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set Default Protection Policies for New Workspaces You can customize how Local Secret Protection manages exposed secrets in your team's --- # intro-to-scripts Use scripts to add logic and tests to Postman requests ===================================================== Postman's runtime is based on [Node.js](https://nodejs.org/en/about). You can use this to write scripts that add dynamic behavior to requests and collections. You can use pre-request and post-response scripts to write API tests, build requests that can contain dynamic parameters, or pass data between requests. Scripts run asynchronously. That means you can run multiple scripts without waiting for the previous script to complete. If you want scripts to run in sequence, you can use a callback function. ## Scripts in Postman You can add JavaScript code to run during two events in a flow: * Before a request is sent to the server, as a [pre-request script](/docs/tests-and-scripts/write-scripts/pre-request-scripts/) under the **Scripts > Pre-request** tab. * After a response is received, as a [post-response script](/docs/tests-and-scripts/write-scripts/test-scripts/) under the **Scripts > Post-response** tab. * GraphQL requests run scripts before a query (under the **Scripts > Before query** tab) or after a response (under the **Scripts > After response** tab). * gRPC requests run scripts before invoke (under the **Scripts > Before invoke** tab), during a message (under the **Scripts > On message** tab) or after a response (under the **Scripts > After response** tab). Postman prompts you with suggestions as you enter text. Select one to autocomplete your code. ![Script autocomplete](https://assets.postman.com/postman-docs/v11/autocomplete-v11-v2.jpg) In addition to requests, you can add pre-request and post-response scripts to a collection or folder. ## Run order of scripts In Postman, the script run order for a single request looks like this: * A pre-request script associated with a request runs before the request is sent. * A post-response script associated with a request runs after the request is sent. ![Workflow for single request](https://assets.postman.com/postman-docs/v11/req-resp-v11.jpg) For every request in a collection, scripts run in the following order: * A pre-request script associated with a collection runs prior to every request in the collection. * A pre-request script associated with a folder runs prior to every direct child request in the folder. * A post-response script associated with a collection runs after every request in the collection. * A post-response script associated with a folder runs after every direct child request in the folder. ![Workflow for request in collection](https://assets.postman.com/postman-docs/v11/execOrder-v11.jpg) For every request in a collection, the scripts always runs according to the same hierarchy. Collection-level scripts run first, then folder-level scripts, and then request-level scripts. This run order applies to both pre-request and post-response scripts. For example, the following collection is structured with a single folder and two requests within the folder. ![Collection with nested folder and requests](https://assets.postman.com/postman-docs/v11/console-log-statement-v11-2-v4.jpg) If you created log statements in the pre-request and post-response script sections for the collection, folder, and requests, the run order is returned in the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/). ![Logs in the Console](https://assets.postman.com/postman-docs/v11/logs-in-console-v11-v3.jpg) ### How it works The [Postman Sandbox](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/) is available to you when you write your pre-request and post-response scripts. The sandbox is a JavaScript runtime environment for Postman, the [Postman CLI](/docs/postman-cli/postman-cli-overview/), and [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) You can build workflows to test different API scenarios using a collection, and that branch and loop over a set of requests. To try out this collection template, select [API scenario testing](https://www.postman.com/templates/collections/api-scenario-testing/). ## Reuse scripts You can add commonly used scripts and tests to packages in your team's Postman Package Library. This enables you to reuse internal scripts in your team's HTTP gRPC, and GraphQL requests. Learn how to [reuse scripts and tests in Postman](/docs/tests-and-scripts/write-scripts/packages/package-library/). You can also [import external packages](/docs/tests-and-scripts/write-scripts/packages/external-package-registries/) from npm and JSR package registries into your team's HTTP, gRPC, and GraphQL requests. ## Debugging scripts Debugging scripts can be written under either the **Pre-request** tab or the **Post-response** tab. You can log debugging messages in the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/). ## Test examples You can use post-response [script examples](/docs/tests-and-scripts/write-scripts/test-examples/) to write your own tests for requests, folders, and collections. Post-response scripts run when Postman receives a response from the API you sent the request to. When you add tests to a folder or collection, they run after each request inside it. ## Dynamic variables Postman uses the [Faker](https://www.npmjs.com/package/@faker-js/faker) library to generate sample data, including random names, addresses, email addresses, and more. You can use these predefined variables to return different values per request. Learn how to [use dynamic variables](/docs/tests-and-scripts/write-scripts/variables-list/). ## Postman JavaScript APIs Postman provides [JavaScript APIs](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/) that you can use in your request scripts. The `pm` object provides functionality for testing your request and response data. ## References * [Postman API documentation](/docs/design-apis/api-definition/) * [Postman API Governance](/docs/api-governance/api-governance-overview/) * [Postman API Builder](/docs/design-apis/api-builder/) * [Postman API documentation](/docs/design-apis/api-definition/openapi2) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/openapi3) * [Postman API documentation](/docs/design-apis/api-definition/open --- # Introduction to Flows Query Language You can use _Flows Query Language_ (FQL) to parse and transform JSON data to get the fields and structure you want. ## FQL compared to TypeScript The logic blocks in Postman Flows ([**If**](/docs/postman-flows/reference/blocks/if/), [**Condition**](/docs/postman-flows/reference/blocks/condition/), and [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/)) support both FQL and [TypeScript](/docs/postman-flows/typescript/typescript-overview/). While FQL is designed for querying and transforming data, TypeScript offers the robustness and flexibility of a full programming language within your Postman Flows. This makes TypeScript more suitable for complex logic and large-scale projects. Also, if you are familiar with both the JavaScript and TypeScript ecosystems, you may prefer using TypeScript over FQL. ## Extract fields from data with FQL ![FQL example](https://assets.postman.com/postman-docs/v11/fql-example-v11-60.png) You can use FQL to extract specific fields from data passed between blocks. In this example, the **Template** block holds a `customer_info` JSON object. The variable `data_field` receives the formatted data and passes it into the **Evaluate** block where it can be queried with FQL. FQL in the **Evaluate** block prints out the values of `customer_info`. This example also includes a comment that uses the FQL `/*comment*/` syntax. ## Things you can do with FQL The following pages show examples of things you can do with FQL: * [Get basic values](/docs/postman-flows/flows-query-language/get-basic-values/) * [Conditional data selection](/docs/postman-flows/flows-query-language/conditional-data-selection/) * [Return structured data](/docs/postman-flows/flows-query-language/return-structured-results/) * [Data manipulation](/docs/postman-flows/flows-query-language/data-manipulation/) ## Using Postman Agent Mode with FQL Not sure how to write an FQL statement for your flow? Use [Postman Agent Mode](/docs/agent-mode/overview/)! Tell Agent Mode what you want to do using plain language, and it will generate a FQL statement for you. In the **Evaluate** block, drag the Agent Mode icon ![Image 3: Agent mode icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-postbot-stroke.svg#icon) to the block's text box or anywhere on the canvas to open Agent Mode. Enter your query as plain text in the Agent Mode text box and press the **Return** or **Enter** key. Agent Mode will suggest a query for you based on your prompt. To learn more about how you can use Postman's AI to help you use Flows, visit [Postman Agent Mode](/docs/agent-mode/overview/). ## FQL reference For a complete reference for all FQL functions, see the [FQL function reference](/docs/postman-flows/flows-query-language/function-reference/). --- # Make HTTP calls using the SOAP protocol Postman can make HTTP calls using Simple Object Access Protocol (SOAP), a platform-independent messaging protocol specification. In this example, the SOAP endpoint validates an ISBN book number. ## Enter your SOAP endpoint 1. In Postman, select **New > HTTP** to create a new HTTP request. ![Create new request](https://assets.postman.com/postman-docs/v11/create-new-http-v11-45.jpg) 1. Enter your SOAP endpoint URL in the address field. For this example, use the `http://webservices.daehosting.com/services/isbnservice.wso` endpoint URL. 2. Select **POST** from the request method dropdown list. ## Add body data 1. In the **Body** tab, select **raw** and choose **XML** from the dropdown list. ![SOAP body type](https://assets.postman.com/postman-docs/v11/soap-body-type-v11-46.jpg) 1. Enter your XML in the text entry area. To validate the book number, enter the following XML: ```xml 0-19-852663-6 ``` Your request body must include the SOAP `Envelope`, `Header`, and `Body` tags as required by the endpoint, and any namespaces. The data must include the name of the operation and any values you need to post to the service. ## Set your request headers When you select an XML body type, Postman automatically adds a content type header of `application/xml`. But depending on your service provider, you may need `text/xml` for some SOAP requests. Check with your SOAP service to decide which header is appropriate. If you need the `text/xml` header, override the default Postman setting. To set request headers, do the following: 1. Click **Headers** in the request. If the auto-generated headers are hidden, click **hidden** to display them. 2. Clear the `Content-Type` header checkbox. 3. Add a new `Content-Type` and `text/xml` key-value pair. 4. Add the `SOAPAction` and `\"#MethodName\"` key-value pair (for example, `\"#POST\"`). ![SOAP content type](https://assets.postman.com/postman-docs/v11/soap-header-v11-46.jpg) ## Send your request Click **Send** to make your call to the SOAP service. On success, Postman displays the response in the lower tab. ![SOAP response data](https://assets.postman.com/postman-docs/v11/soap-response-data-v11-46.jpg) --- ## Postman Power Pass FAQ ### General Information - **What is the Postman Power Pass?** Your team’s activity unlocked the best Postman experience. For free, you can explore premium access to unlimited invites, most Enterprise features, and add-on products. Designed to empower seamless collaboration across the entire API development lifecycle, the Postman Power Pass lets you explore our platform’s full potential. - **How long does the Postman Power Pass last?** The Postman Power Pass provides you with premium access for an extended period, but we recommend taking full advantage of this opportunity as soon as possible. While there’s no fixed access period, we encourage you to explore all the premium features and maximize your experience while the Postman Power Pass is active. We’ll keep you informed of any changes or updates regarding your access. - **Is the Postman Power Pass completely free?** Yes, access to Enterprise features, add-on products, and unlimited invites is entirely free during the program. Once the Postman Power Pass access ends, you can upgrade to a paid plan or purchase the add-ons to continue using premium features. - **Will I be charged automatically when the Postman Power Pass expires?** No, you won’t be automatically charged. We won’t ask for your payment information to access the Postman Power Pass. You’ll receive a notification before your Postman Power Pass expires. You’ll have the choice to upgrade to a paid plan or downgrade to the access and features included with our [Free plan](https://www.postman.com/pricing/). If you don’t make a selection, we’ll automatically move you to our Free plan. - **Exclusions** - Deployment control - User-level reporting and analytics - Custom alerts - Secret Scanner dashboard - SCIM (System for Cross-domain Identity Management) (User provisioning) - Super Admin roles - Domain Capture - Partner Manager - Local Performance Testing - Virtual Users - Local Performance Testing - Test Runs - The additional privacy and availability included in the [Enterprise version of Postbot](https://learning.postman.com/docs/getting-started/basics/about-postbot/#postbot-for-enterprise). ### Billing and Payments - **Is the Postman Power Pass completely free?** Yes, access to Enterprise features, add-on products, and unlimited invites is entirely free during the program. Once the Postman Power Pass access ends, you can upgrade to a paid plan or purchase the add-ons to continue using premium features. - **Will I be charged automatically when the Postman Power Pass expires?** No, you won’t be automatically charged. We won’t ask for your payment information to access the Postman Power Pass. You’ll receive a notification before your Postman Power Pass expires. You’ll have the choice to upgrade to a paid plan or downgrade to the access and features included with our [Free plan](https://www.postman.com/pricing/). If you don’t make a selection, we’ll automatically move you to our Free plan. - **Exclusions** - Deployment control - User-level reporting and analytics - Custom alerts - Secret Scanner dashboard - SCIM (System for Cross-domain Identity Management) (User provisioning) - Super Admin roles - Domain Capture - Partner Manager - Local Performance Testing - Virtual Users - Local Performance Testing - Test Runs - The additional privacy and availability included in the [Enterprise version of Postbot](https://learning.postman.com/docs/getting-started/basics/about-postbot/#postbot-for-enterprise). ### Features and Benefits - **What features are included in the Postman Power Pass?** You have access to almost all of the features with the Enterprise plan, enabling you to unlock seamless collaboration across the API development lifecycle. - **What add-on products are included in the Postman Power Pass?** - Unlimited tests with [Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/) - Unlimited AI support with [Postbot](/docs/getting-started/basics/about-postbot/) - Unlimited [Partner Editors](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/) - Unlimited [runs on Flows](/docs/postman-flows/overview/) ### Additional Resources - **Postman Vault integrations** - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/) - [Postman Vault integrations](/docs/sending-requests --- # Create and manage vault secrets using Guided Auth [Use Guided Auth to add vault secrets](#add-authorization-as-vault-secrets-using-guided-auth) to your Postman Vault, enabling you to store authentication credentials for public APIs that set up Guided Auth. You can use vault secrets added using Guided Auth in your Postman team. Then you can [reference vault secrets added using Guided Auth](#use-vault-secrets-added-using-guided-auth) in new HTTP requests to the same public APIs. Only you can access and use values associated with your encrypted vault secrets, and vault secrets aren't synced to the Postman cloud. Guided Auth enables you to set up authentication credentials for public APIs by following steps set up by API publishers. Once you set up your authentication credentials using Guided Auth, you can store them in your Postman Vault and reuse them throughout your workspaces. Learn how to [explore public APIs](/docs/postman-api-network/explore/overview/) on the Postman API Network. If you're an API publisher, learn how to [set up Guided Auth for your public APIs in Postman](/docs/publishing-your-api/setting-up-authentication-for-public-apis/). Guided Auth supports public APIs that require bearer, basic, API key, or OAuth 2.0 authentication credentials. If an API supports token refresh, Postman automatically refreshes OAuth 2.0 tokens that were stored in your Postman Vault using Guided Auth. Vault secrets are deleted from your Postman Vault after signing out of Postman. Existing references to vault secrets are empty when you sign in to Postman. You can add your vault secrets to your Postman Vault using Guided Auth after you sign in to Postman. To add authentication credentials as vault secrets using Guided Auth, do the following: 1. Open an HTTP request, and enter the URL for a public API that has Guided Auth set up, such as `https://api.getpostman.com/`. Learn how to [explore public APIs](/docs/postman-api-network/explore/overview/) on the Postman API Network. 2. Click the **Authorization** tab, click the **Auth Type** dropdown list, then select the authentication option you'd like to use under **Recommended setup**. If the public API has only one API authentication configured, you can click **Set up new authorization** when you enter the URL. This takes you directly to the instructions for getting your credentials. ![Set up new auth using Guided Auth](https://assets.postman.com/postman-docs/v11/set-up-new-auth-v11-16.jpg) ![Add credentials using Guided Auth](https://assets.postman.com/postman-docs/v11/guided-setup-add-credentials-v11-16.jpg) 3. Generate and enter your authentication credentials: * For APIs that require authentication credentials like tokens or API keys, follow the instructions to get your credentials. Then enter them in the field under **Auth credentials**. * For APIs that support OAuth 2.0, select **Authorize** to get your credentials and automatically enter the access token in the field under **Auth credentials**. 4. Click **Store Auth in Vault**. ![Store auth in Postman Vault](https://assets.postman.com/postman-docs/v11/store-auth-in-postman-vault-v11-16.jpg) If you haven't entered your vault key since signing in to Postman, you're asked to enter it. 5. Enter the **Auth method name** for the authentication credentials. By default, the auth method name is the public API's name, such as "Postman API", but you can use a different name if you'd like. The auth method name is used to categorize the vault secret in your Postman Vault. The auth method name is also used to generate the vault secret's key. For example, if you enter "Postman API Key" as the auth method name for an API key, the vault secret's key would be `postman-api-key:value`. If you use an auth method name that already exists in your Postman Vault, the existing auth method is overwritten. 6. Click **Store**. In the **Auth Type** dropdown list of the request, the auth method name is selected under **Stored in vault**. ![Stored credentials in Auth Type list](https://assets.postman.com/postman-docs/v11/auth-credentials-stored-in-postman-vault-v11-16.jpg) To view your authentication credentials in your Postman Vault, select the created auth method name as the auth type, then click **View in vault**. You can also click ![Vault icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-vault-stroke.svg#icon) **Vault** from the Postman footer. Learn more about [opening your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). In your Postman Vault, vault secrets added using Guided Auth are stored under **Created with guided auth**, and they're categorized by the auth method name. Each vault secret's key name is automatically appended with a suffix, which you shouldn't edit: * For APIs that require authentication credentials like tokens or API keys, the suffix represents the authentication type, such as `:token`. * For APIs that support OAuth 2.0, multiple vault secrets are added to your Postman Vault, including the access token and other properties returned by the public API (like the token type). Each vault secret has a suffix that represents the value, such as `:accessToken` and `:tokenType`. ![Vault secret created with Guided Auth](https://assets.postman.com/postman-docs/v11/postman-vault-guided-auth-v11-60.jpg) The allowed domains for the vault secret are autofilled with the domains and subdomains for the public API. This is a comma-separated list of domains and subdomains you're allowed to send requests to with the vault secret. This enables you to prevent unintentional disclosure of sensitive data in your vault secret. Postman uses this information to suggest [using saved authorization](#use-vault-secrets-added-using-guided-auth) in future HTTP requests to the domain or subdomain. If allowed domains or subdomains are specified for a vault secret, you can only reference it at the request level. ## Use vault secrets added using Guided Auth You can reference vault secrets that were added using Guided Auth from the **Authorization** tab of your HTTP requests. You can also use the Collection Runner to [manually run collections](/docs/collections/running-collections/intro-to-collection-runs/) and [run performance tests](/docs/collections/performance-testing/performance-test-configuration/) that reference vault secrets added using Guided Auth. Scheduled collection runs, monitors, the Postman CLI, and Newman don't support vault secrets added using Guided Auth. You can [access vault secrets added using Guided Auth in scripts](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-vault/). Make sure you enable scripts to access your vault secrets. Otherwise, you'll receive an error in the Postman Console. If you're using Guided Auth from the Postman web app, use the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent). Postman recommends you [use the latest version](/docs/getting-started/basics/about-postman-agent/#update-the-postman-desktop-agent) of the Postman Desktop Agent to receive recent changes and improvements. Click the **Authorization** tab of an HTTP request, and click the **Auth Type** dropdown list. Under **Stored in vault**, select the auth method name that has the stored authentication credentials you want to reference. ![Guided Auth credentials](https://assets.postman.com/postman-docs/v11/guided-auth-stored-in-vault-list-v11-16.jpg) If the public API has only one API authentication configured, you can click **Use Saved Authorization** in the **URL builder**. This enables you to reference the vault secret with the authentication you generated using Guided Auth. ![Used saved Guided Auth credentials](https://assets.postman.com/postman-docs/v11/guided-auth-use-saved-auth-v11-16.jpg) Vault secrets added using Guided Auth are inside double curly braces (`{{ }}`). The prefix `vault:` is appended to the vault secret's name, and a suffix is automatically appended with the authentication type. For example, a vault secret that stores an API key named "postman-api-key" uses the following syntax: ```txt {{vault:postman-api-key:value}} ``` ![Use vault secret stored using Guided Auth](https://assets.postman.com/postman-docs/v11/use-guided-auth-vault-secrets-v11-16.jpg) To learn how to troubleshoot empty or unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). From the variables pane, you can view vault secrets that are referenced in an HTTP request and available from a Postman element. Click ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the workbench to open the variables pane. Review the vault secrets referenced in a request under **Variables in request**. Under **All variables**, you can view vault secrets that can be referenced and resolved in the Postman element that's open. For requests that reference a variable or vault secret, click **All variables** to display all vault secrets a request can access. ![View Guided Auth vault secret used in a request](https://assets.postman.com/postman-docs/v11/guided-auth-vault-secrets-used-in-a-request-v11-18.jpg) Vault secrets in your Postman Vault added using Guided Auth are masked by default when they're logged to the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/). To edit whether vault secrets are masked in the Postman Console, click ![Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings**, then turn the toggle on or off next to **Mask vault secrets**. If you're using the Postman web app with Safari as your web browser, it deletes vault secrets from your Postman Vault after seven days of inactivity. Use a different web browser if you want your vault secrets available for more than seven days without activity in the Postman web app. Learn about the [browser requirements](/docs/getting-started/installation/system-requirements/#browser-requirements) for the Postman web app. ## Edit vault secrets added using Guided Auth You can edit vault secrets stored in your Postman Vault that were added using Guided Auth. Update the auth method name, update allowed domains, make vault secrets unavailable, and delete vault secrets. You can also edit the value of vault secrets added using Guided Auth from requests that reference it or can access it. Be careful when editing vault secrets added using Guided Auth. This might cause your authentication credentials stored as vault secrets to not work as expected. Learn how to [troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). To edit vault secrets added using Guided Auth, [open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). You can take the following actions: 1. To filter the list of vault secrets by name, enter text in the **Filter secrets** box under **Created with guided auth**. 2. To sort the list of vault secrets, click a column header. You can toggle between ascending and descending order. 3. To update the key or value for the vault secret, click the relevant cell. Existing references to the vault secret are empty, meaning they won't have a value. Learn how to [add a value to an empty vault secret](/docs/sending-requests/postman-vault/manage-vault-secrets/#add-a-vault-secret-reference-to-your-postman-vault). Don't remove or change the suffix associated with each vault secret's key name. 4. To delete a vault secret, hover over a secret and click ![Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. This will remove the vault secret reference from requests that were using the auth method. 5. To update the list of allowed domains, click the empty cell or list of domains. 6. To make a vault secret unavailable without deleting it, clear the checkbox next to the secret. Any references to the secret are unresolved. To make the secret available again, select the checkbox. Changes are automatically saved to your Postman Vault. You can also edit the value of a vault secret from the variables pane or the request builder. Click ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the workbench to open the variables pane. You can edit vault secrets referenced in an HTTP request under **Variables in request** and vault secrets available from a Postman element under **All variables**. In the variables pane, delete the existing value next to a vault secret, then enter a new value. You can also hover over the reference to the vault secret in the request builder, delete the existing value, then enter a new value. --- # Create and manage vault secrets [Add vault secrets](#add-sensitive-data-as-vault-secrets) to your Postman Vault and reuse them in your local instance of Postman. Then you can [reference vault secrets](#use-vault-secrets) in your HTTP collections and requests, variables, and the Collection Runner. Only you can access and use values associated with your encrypted vault secrets, and vault secrets aren't synced to the Postman cloud. You can also [use Guided Auth to add vault secrets](/docs/sending-requests/postman-vault/manage-vault-secrets-using-guided-auth/) that have authentication credentials for public APIs, and reference them in your HTTP requests. ## Add sensitive data as vault secrets After you [save your vault key](/docs/sending-requests/postman-vault/postman-vault-key/), you can add sensitive data, such as API keys and passwords, to your Postman Vault and reuse them in your local instance of Postman. From the HTTP request builder, you can [set existing data as a vault secret](#set-data-as-a-vault-secret). You can also set a value for a [vault secret that doesn't exist](#set-a-value-for-a-vault-secret-that-doesnt-exist) in your Postman Vault, and later [add the vault secret reference to your Postman Vault](#add-a-vault-secret-reference-to-your-postman-vault). Then you can [use vault secrets](#use-vault-secrets) in your local instance of Postman. You can [set vault secrets in scripts](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-vault/). Make sure you enable scripts to access your vault secrets. Otherwise, you'll receive an error in the Postman Console. You can also [create an integration](/docs/sending-requests/postman-vault/postman-vault-integrations/) ([Enterprise teams only](https://www.postman.com/pricing/)) that connects your Postman Vault with external vaults, such as Azure Key Vault. This enables you to link vault secrets with sensitive data stored in external vaults, and reuse it in your local instance of Postman. Vault secrets are deleted from your Postman Vault after signing out of Postman. Existing references to vault secrets will be empty when you sign in to Postman. You can [add your vault secrets to your Postman Vault](#add-a-vault-secret-reference-to-your-postman-vault) after you sign in to Postman. To add secrets to your Postman Vault, do the following: 1. [Open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). 1. Enter the following values in an empty row: * **Key** - The name of the vault secret. Use the name to [reference the secret](#use-vault-secrets). * **Value** - The value used when sending requests in your local instance of Postman. It's never synced to your account or shared with your team. To show or hide a vault secret's value, hover over the secret and click ![Image 1: View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon) **View** or ![Image 2: Hide icon](https://assets.postman.com/postman-docs/aether-icons/action-hide-stroke.svg#icon) **Hide**. * **Allowed domains** - The comma-separated list of domains and subdomains you're allowed to send requests to with the vault secret. This enables you to prevent unintentional disclosure of sensitive data in your vault secret. By default, you can include vault secrets in requests to any domain and subdomain. If you specify allowed domains or subdomains for a vault secret, you can only reference it at the request level. To allow sending requests to any subdomain of an allowed domain, use `*` to represent any subdomain. For example, add `*.example.com` to allow sending requests to any subdomain of `example.com`. ![Add secrets to Postman Vault](https://assets.postman.com/postman-docs/v11/add-postman-vault-secrets-v11-1.jpg) Changes are automatically saved to your Postman Vault. ### Set data as a vault secret You can select data from the **URL builder**, **Params** tab, **Authorization** tab, or **Headers** tab and set the data as a vault secret. You can also enter a value with sensitive data in the **Authorization** tab and add it directly to your Postman Vault as a vault secret. To select data and set it as a vault secret, do the following: 1. [Open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). 1. Select the data you need. You can select data from the **URL builder**, **Params** tab, **Authorization** tab, or **Headers** tab. 1. Right-click the selected data and click **Set as variable**. 1. Click ![Image 3: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Set as new variable**. ![Set as new variable](https://assets.postman.com/postman-docs/v11/set-data-as-new-vault-secret-v11-14.jpg) 1. Enter the **Name** of the vault secret, confirm that the **Value** is correct, and select **Vault** as the scope. 1. Click **Set Variable**. To add sensitive data as a vault secret from the **Authorization** tab, do the following: 1. [Open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). 1. Click the **Authorization** tab. 1. Click the **Auth type** dropdown list, then select an authorization. 1. Enter a value in a field that holds sensitive data, such as a password or token. 1. Hover over ![Image 4: Secret warning icon](https://assets.postman.com/postman-docs/aether-icons/state-secretWarning-stroke.svg#icon) **Sensitive value**, then click **Set as Variable**. ![Set as new variable](https://assets.postman.com/postman-docs/v11/set-sensitive-value-as-vault-secret-v11-39.jpg) 1. Enter a name for the vault secret. 1. Select **Local Vault**. ### Set a value for a vault secret that doesn't exist Vault secrets that aren't added to your Postman Vault are useful for trying out a value. If the value works as expected, you can [add the vault secret to your Postman Vault](#add-a-vault-secret-reference-to-your-postman-vault). You can also create placeholder vault secrets to share with your API consumers. Your consumers can use the placeholder vault secret to add their own sensitive data to their Postman Vault. You can create a vault secret reference in an HTTP request without adding the vault secret to your Postman Vault. The value you enter for this vault secret is stored locally and is only available in the request it's set in. In the [variables pane](/docs/getting-started/basics/navigating-postman/#environment-selector-and-variables-pane) under **Variables in request**, the vault secret isn't associated with your Postman Vault. To create a vault secret reference that isn't added to your Postman Vault, [open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault), then enter a name that doesn't exist using the following syntax: `{{vault:secret-name}}`. You can enter a name in the **URL builder**, the **Params** tab, the **Authorization** tab, and the **Headers** tab. ![Set as new vault secret](https://assets.postman.com/postman-docs/v11/reference-and-create-new-vault-secret-v11-18.jpg) To set a value for a vault secret that isn't added to your Postman Vault, hover over it, click **Enter value**, then enter a value. You can also click ![Image 5: Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** to open the variables pane, click **Enter value** next to a vault secret, then enter a value under **Variables in request**. Values for vault secrets not added to your Postman Vault are stored locally in a request until you close its tab or sign out of Postman. When you open the request again, the vault secret's value will be empty. Optionally, you can [add the vault secret and its value to your Postman Vault](#add-a-vault-secret-reference-to-your-postman-vault). ### Add a vault secret reference to your Postman Vault From a Postman element, such as a request or collection, you can create a vault secret and add it to your Postman Vault. This also enables you to define a default value for a [vault secret that's not added to your Postman Vault](#set-a-value-for-a-vault-secret-that-doesnt-exist). From the element, you can add a value that's stored in your Postman Vault that only you can access and use. [Open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault), then enter a name for a vault secret that doesn't exist in your Postman Vault using the following syntax: `{{vault:secret-name}}`. Hover over the reference to the vault secret, click **Enter value**, enter the value, then click ![Image 6: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add to Vault**. ![Add secret to Postman Vault](https://assets.postman.com/postman-docs/v11/add-vault-secret-to-postman-vault-v11-18.jpg) You can also click ![Image 7: Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the [workbench](/docs/getting-started/basics/navigating-postman/#environment-selector-and-variables-pane) to open the variables pane and view the vault secrets used in your request. Click **Enter value** next to the vault secret, enter a value, then click ![Image 8: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add to Vault**. If you would like to store the value as a variable instead, remove the `vault:` prefix, then follow the instructions to [add the variable to a scope](/docs/sending-requests/variables/variables/#adding-variables-to-a-scope). ## Use vault secrets You can reference vault secrets in your HTTP collections and requests from the **URL builder**, the **Params** tab, the **Authorization** tab, the **Headers** tab, and the **Body** tab. You can use the Collection Runner to [manually run collections](/docs/collections/running-collections/intro-to-collection-runs/) and [run performance tests](/docs/collections/performance-testing/performance-test-configuration/) that reference vault secrets. Scheduled collection runs, monitors, the Postman CLI, and Newman don't support vault secrets. You can [access vault secrets in scripts](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-vault/). Make sure you enable scripts to access your vault secrets. Otherwise, you'll receive an error in the Postman Console. If you're using the Postman web app to send requests with references to vault secrets, use the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent). Postman recommends you [use the latest version](/docs/getting-started/basics/about-postman-agent/#update-the-postman-desktop-agent) of the Postman Desktop Agent to receive recent changes and improvements. You can also use the [Postman Browser Agent](/docs/getting-started/basics/about-postman-agent/#postman-browser-agent), but you may experience the CORS limitations of browsers. If you're referencing vault secrets linked from an external vault, you must use the Postman desktop app. Learn about [external vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/). Put the vault secret inside double curly braces (`{{ }}`) and append the prefix `vault:` to the vault secret's name, enabling you to reference it throughout your workspaces. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` ![Reference vault secrets in Postman](https://assets.postman.com/postman-docs/v11/use-postman-vault-secrets-v11-12.jpg) To learn how to troubleshoot empty or unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). If you specified an allowed domain for a vault secret and you're sending a request to the domain, you can select a vault secret from the **Authorization** tab. Note that you can only add a vault secret this way from the request level. Select an authorization from the **Auth type** dropdown list, click a field that holds sensitive data, then select a vault secret from the dropdown list. You can click ![Image 9: View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon) **View secret value** to show the vault secret's value in the dropdown list. ![Select vault secret](https://assets.postman.com/postman-docs/v11/select-sensitive-value-vault-secret-v11-39.jpg) From the variables pane, you can view vault secrets referenced in an HTTP request and available from a Postman element. Click ![Image 10: Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the workbench to open the variables pane. Review the vault secrets referenced in a request under **Variables in request**. If the request auth is set to [**Inherit auth from parent**](/docs/sending-requests/authorization/specifying-authorization-details/#inherit-authorization), you can view vault secrets referenced in the **Authorization** tab of the request's parent collection or folder. Under **All variables**, you can view vault secrets that can be referenced and resolved in the Postman element that's open. For requests that reference a variable or vault secret, click **All variables** to display all vault secrets a request can access. ![Vault secrets used in a request](https://assets.postman.com/postman-docs/v11/vault-secrets-used-in-a-request-v11-18.jpg) Vault secrets stored in your Postman Vault are masked by default when they're logged to the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/). To edit whether vault secrets are masked in the Postman Console, click ![Image 11: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings**, then turn the toggle on or off next to **Mask vault secrets** from the **Settings** tab. If you're using the Postman web app with Safari as your web browser, it deletes vault secrets from your local instance of Postman after seven days of inactivity. Use a different web browser if you want your vault secrets available for more than seven days without activity in the Postman web app. Learn about the [browser requirements](/docs/getting-started/installation/system-requirements/#browser-requirements) for the Postman web app. ## Edit vault secrets Edit vault secrets stored in your Postman Vault by updating them and their allowed domains, changing a vault secret's name, making vault secrets unavailable, or deleting vault secrets. You can also edit the value of vault secrets directly from requests that references it or can access it. To edit vault secrets, [open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). You can take the following actions: * To filter the list of vault secrets by name, enter text in the **Filter secrets** box. * To sort the list of vault secrets, click a column header. You can toggle between ascending and descending order. * To add a new vault secret, click **Add new secret** in the bottom row of the table. * To update the key or value for the vault secret, click the relevant cell. * To delete a vault secret, hover over a secret and click ![Image 12: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. * To update the list of allowed domains, click the empty cell or list of domains. * To make a vault secret unavailable without deleting it, clear the checkbox next to the secret. Any references to the secret will be unresolved. To make the secret available again, select the checkbox. * To [link a different secret from an external vault](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/#link-a-different-secret-from-an-external-vault), click ![Image 13: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Configure vault** next to the vault secret you want to update, then click ![Image 14: Edit icon](https://assets.postman.com/postman-docs/aether-icons/action-edit-stroke.svg#icon) **Edit**. Changes are automatically saved to your Postman Vault. You can also edit the value of a vault secret from the variables pane or the request builder. Click ![Image 15: Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the workbench to open the variables pane. You can edit vault secrets referenced in an HTTP request under **Variables in request** and vault secrets available from a Postman element under **All variables**. In the variables pane, delete the existing value next to a vault secret, then enter a new value. You can also hover over the reference to the vault secret in the request builder, delete the existing value, then enter a new value. From the variables pane, you can't edit the value of a vault secret that's linked to an external vault. --- # Manage Partner Workspaces in Postman **[Partner Workspaces are available with Postman Professional and Enterprise plans.](https://www.postman.com/pricing/)** Workspace Admins and Partner Managers manage workspace settings, users, and roles within a Partner Workspace. Partner Leads also manage users and roles of partners in Partner Workspaces. Learn how to manage users and roles in a Partner Workspace and scale your collaboration by adding and updating Partner licenses and Partner Workspaces. From May 2025, you can begin creating _team-to-team Partner Workspaces_, which ensures easier and more secure collaboration between you and your partners. Your partners can use domain capture and SSO to authenticate to your Partner Workspaces and you can track your partnerships in a new team setting called [**Partnerships**](#manage-your-partnerships). That means no switching between teams and more control over partnerships. See the [FAQ](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/faq/) about team-to-team partnerships. ## Manage users and roles You can assign team and Partner Workspace roles based on the functions team members and partners require. You can assign team roles for Partner Workspace roles at the [team level](/docs/administration/managing-your-team/team-members/manage-roles/), and you can assign Partner Workspace roles at the [workspace level](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles) and [collection level](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles). Learn more about [team and Partner Workspace roles](/docs/administration/roles-and-permissions/#partner-team-and-partner-workspace-roles). To learn more about collaborating as a team member or partner, see [Collaborate in a Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/collaborate/). ## Add Partner licenses A paid seat is consumed when a Partner is assigned at least one Editor role (at the workspace or collection level) in at least one Partner Workspace. Assigning a Partner the Workspace Viewer or Collection Viewer role doesn't consume paid seats. To purchase more Partner licenses, contact your Postman Account Manager or [contact Postman's sales team](mailto:sales@postman.com). Your team must have [available seats](/docs/billing/billing/#changing-your-plan) or [Auto-Flex enabled](/docs/billing/billing/#using-auto-flex) to [invite a partner](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/setup/#invite-collaborators-to-a-partner-workspace) as a Workspace Editor. Otherwise, the Partner will be assigned the Workspace Viewer role, giving the Partner permission to view all workspace resources. Also, your team must have available seats to assign a Partner as a Collection Editor. ## Manage workspace elements To move elements to a Partner Workspace, see [Move elements to a Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/setup/#move-elements-to-a-partner-workspace). To remove elements from a Partner Workspace, see [Remove elements from a Partner Workspace](#remove-elements-from-a-partner-workspace). ## Edit workspace details Workspace Admins and Partner Managers can edit Partner Workspace details. On the workspace's Overview tab, select the workspace name, summary, or description to edit it. You can add Markdown to the description. Select **Save** when you're done. ## Manage your partnerships API publishers [invite partners](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/setup/#invite-collaborators-to-a-partner-workspace) using their email. When accepting the invite to collaborate, the Partner selects an existing team or creates a new one. This team is then listed on the API publisher's [**Partnerships**](https://go.postman.co/settings/team/partnerships/external-partners) page. To collaborate within the Partner Workspace, the Partner authenticates using their team's login method: username and password, or SSO. From the **Partnerships** page, [Partner Managers](/docs/administration/roles-and-permissions/#partner-team-and-partner-workspace-roles) can verify which partners use or don't use \[![Image 1: Sso icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-sso-stroke.svg#icon)](#manage-your-partnerships) **SSO** to authenticate. They can also see individual partners, who access the Partner Workspace using a Postman account. In the header, select **Team > Team Settings**. Then, select **Partnerships**. ![Image 2: Partnerships](https://assets.postman.com/postman-docs/v11/partnerships-v11.67.png) Workspace Admins and Partner Managers can view and control whether their members of their team can accept Partner invites from other teams. ![Image 3: Partner invites](https://assets.postman.com/postman-docs/v11/partner-view-v11.jpg) Use the **As a publisher** tab to view and manage the partnerships you own as a publisher. You can see all the partners invited by your team to collaborate. The **As a partner** tab contains the list of the teams who have invited your team members as Partners to collaborate in their Partner Workspaces. ## View resources a Partner can access A [Partner Manager](/docs/administration/roles-and-permissions/#partner-team-and-partner-workspace-roles) can view the Partner Workspaces and collections a Partner can access. A Partner Manager can also view the Workspace role partners are assigned in each workspace, and the Collection role partners are assigned in each collection. Open your [team dashboard](https://go.postman.co/settings/team/members) and select **View resources** next to a partner. Select a Partner Workspace or collection name to open it in a new tab. ![Image 4: View Partner Workspaces and roles](https://assets.postman.com/postman-docs/v10/view-partner-workspaces-and-roles-v10-3.jpg) ## Remove elements from a Partner Workspace You must be at least an Editor on an API, collection, or environment to remove an element from a Partner Workspace. You can also be a Workspace Admin, Partner Manager, or Super Admin to remove any element from a Partner Workspace. To remove an element by moving it to another workspace, do the following: 1. Select \[![Image 5: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon)\] **View more actions** next to the element you want to move, then select **Move**. 2. Use the search bar to find the workspace you'd like to move the element to, or use \[![Image 6: Filter icon](https://assets.postman.com/postman-docs/aether-icons/action-filter-stroke.svg#icon)\] **Filter by visibility**. - You can only move elements to workspaces that you have access to. 3. Select the workspace, then select **Move** (**Collection**, **API**, **Flow**, **Environment**, or **Mock Server**). While not recommended, you can choose to delete an element entirely. To do so, select \[![Image 7: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon)\] **View more actions** next to the element you want to remove, then select **Delete**. Deleted APIs and environments aren't recoverable. You can recover collections smaller than 30 MB for up to 90 days on an Enterprise plan. To do so, select \[![Image 8: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon)\] **Trash** from the Postman footer. ## Remove partners from a Partner Workspace You can remove partners from individual Partner Workspaces. To remove a Partner from a Partner Workspace, see [Manage workspace roles](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles). You can remove partners from a team. Removing a Partner from a team removes them from all Partner Workspaces. If you remove the last Admin from the team, users assigned the Partner Manager role will be assigned the Admin role. Also, if you remove a Partner from their last Partner Workspace, they'll be removed from the team. To remove a Partner from a team, see [Remove team members](/docs/administration/managing-your-team/team-members/scale-team/#remove-team-members). **NEW** From May 2025, if a Partner leaves or is removed from their own team, they lose access to the Partner Workspace. ## Delete a Partner Workspace Workspace Admins and Partner Managers can delete Partner Workspaces. 1. On the workspace's **Overview** tab, select **Settings**. 2. [Change the type of the workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#change-workspace-visibility) to **Internal**. 3. Select **Remove all partners**, then select **Update**. 4. Select **Delete Workspace**. Postman notifies all workspace members in-app and by email when you delete a Partner Workspace. ## Postman Power Pass FAQ ### Tips Before you set up your Organization Teams, consider the following: - How many teams do you need and for which specific step in your API lifecycle? - How will you name your teams and workspaces? - Who will be in each group and on which team? Who will manage each team? - How many workspaces will each team need to begin collaborating? - If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? ### Steps To migrate your teams to Organizations, contact your Customer Success Manager. Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. - If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. - If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. - The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. - Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). - **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: - **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. - **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: - If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. - If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. - Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): - **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. - **Partner** - Only --- # Group sets of variables in Postman using environments In Postman, an _environment_ is a set of one or more [variables](/docs/sending-requests/variables/variables/) that you can reference when [sending requests](/docs/sending-requests/create-requests/create-requests/), [writing pre-request scripts](/docs/tests-and-scripts/write-scripts/pre-request-scripts/), or [writing post-response scripts](/docs/tests-and-scripts/write-scripts/test-scripts/). You can create environments for the different types of work you do in Postman. When you switch between environments, all of the variables in your requests and scripts will use the values from the current environment. This is helpful if you need to use different values in your requests depending on the context, for example, if you're sending a request to a test server or a production server. ## Create an environment Create a new environment when you want to be able to change the values of variables depending on your work context in Postman, or to share values with other team members. You can also create a new environment from the environment selector, making it the active environment. To create a new environment, do the following: 1. Select **Environments** in the sidebar and select ![Image 1: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon). You can also select the environment selector at the top right of the workbench and select ![Image 2: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon). ![Image 3: Create new environment](https://assets.postman.com/postman-docs/v10/environment-create-new-v10-20.jpg) 1. Enter a name for your new environment. ![Image 4: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 1. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 5: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 2. Click **Create**. ![Image 6: Create Organization Team](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 7: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. ![Image 8: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) 1. Click ![Image 9: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. ![Image 10: Components icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) 1. Click **Open Component Library**. ![Image 11: Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 1. Click ![Image 12: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. ![Image 13: Add Component Library](https://assets.postman.com/postman-docs/v11/component-library-add-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 14: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. ![Image 15: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) 1. Click ![Image 16: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. ![Image 17: Components icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) 1. Click **Open Component Library**. ![Image 18: Open Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 1. Click a component file in the left sidebar. * If your team is smaller and doesn't use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 2. Choose a published version of the component file using the version dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. * The policy you select is automatically applied to the selected workspaces. ## View live documentation Postman displays a live preview of your API's documentation as you edit your component file. To show the documentation preview, click ![Image 19: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Live preview** in the right sidebar. Click ![Image 20: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) **Close** to hide the documentation preview. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. > Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click ![Image 21: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. ![Image 22: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) 1. Click ![Image 23: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. ![Image 24: Components icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) 1. Click **Open Component Library**. ![Image 25: Open Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.jpg) 1. Click a component in the left sidebar that you'd like to version and publish. * Click **Version & Publish** in the upper right corner. ![Image 26: Version and publish a component file](https://assets.postman.com/postman-docs/v11/component-library-publish-v11.png) 1. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. * This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 27: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. ![Image 28: Secret Scanner](https://assets.postman.com/postman-docs/v11/secret-scanner-v11.67.png) The settings enable you to do the following: * Create [Organization Teams](/docs/administration/organization/team-settings/). * Configure your [team settings](/docs/administration/managing-your-team/team-settings/). * Manage [team members](/docs/administration/managing-your-team/team-members/overview/). * Manage [team resources](/docs/administration/managing-your-team/manage-team-workspaces/). * Manage [product access](/docs/administration/managing-your-team/manage-team-product-access/). * Manage [security](/docs/administration/managing-your-team/overview/#secure-your-postman-team). Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- # matching-algorithm When you create a mock server, Postman associates a collection (and optionally an environment) with the new mock server. When you call it using its URL (for example, `https://M1.mock.pstmn.io`), the mock service retrieves all saved examples (responses) for the associated collection before it begins the matching process. After the mock service gets the collection's examples, it iteratively pairs the incoming request with the closest matching example. Incoming requests can have configurable variables, such as `requestMethod`, `requestPath`, `requestHeaders`, `requestBody`, and `requestParams`. The `requestMethod` variable corresponds to any valid HTTP request method, and the `requestPath` refers to any valid string path (such as `/` or `/test`). You can also use optional headers, like `x-mock-response-name` or `x-mock-response-id`, to further specify the example returned, based on the example's name or UID respectively. You can use the Postman API to [get a collection](https://www.postman.com/postman/postman-public-workspace/request/ypuwpio/get-a-collection), then find your example's UID (in `-` format) in the response. ![Image 1: Mock request configurable elements](https://assets.postman.com/postman-docs/v11/mock-configurable-elements-v11.jpg) ## How it works To match an incoming request with the closest matching example, Postman uses the following algorithm: ### 1. Fetch all examples The mock service fetches all examples in the associated collection and converts them into Postman response objects using the [Postman Collection SDK](/docs/developer/collection-sdk/). If process fails, resulting in a response that isn't in the expected format, the example is removed from the matching process. The mock service also fetches the environment associated with the mock server (if there is one). Collection variables and environment variables in the examples are then populated with data. ### 2. Filter by HTTP method Any responses that aren't the same HTTP method type as the incoming request are removed from the matching process. For example, if the mock request was a POST to `https://M1.mock.pstmn.io/test`, all examples that aren't the POST method are disregarded. ### 3. Filter by custom headers The matching algorithm checks any custom headers passed in the incoming request in the following order: 1. If the `x-mock-response-code` header is provided, the algorithm filters out all examples that don't have a matching response status code. 1. If the `x-mock-response-id` header is provided, the algorithm selects the example with the matching response ID and returns the example as the response. If no example is found with a matching ID, the matching process stops and Postman returns an error. 1. If the `x-mock-response-name` header is provided, the algorithm selects the example with the matching name and returns the example as the response. * If more than one example in the mocked collection has the same name, Postman sorts the examples by ID and returns the first example in the list with a `200` response status code. * If none of the matching examples has a `200` response status code, Postman returns the first example in the sorted list. * If no example is found with a matching name, the matching process stops and Postman returns an error. ### 4. Filter by URL The matching algorithm compares the incoming request's path with each saved example's path. The algorithm then assigns a score to each example based on how close the paths match. An example starts with a score of 100. The algorithm goes through the matching process, stopping only when a match is made. The score is then adjusted based on the step that resulted in a match. If a match can't be made, the example is removed from the matching process. ### 5. Filter by parameters After matching URLs, the algorithm examines the parameters for each example (for example, `{{url}}/path?status=pass`). The matching score is further adjusted based on the number of parameter matches, partial parameter matches, and missing parameters. * **Parameter match** - A key-value pair in the example matches a key-value pair in the incoming request. * **Partial parameter match** - A key in the example matches a key in the incoming request, but the values for the keys don't match. * **Missing parameter** - A key is present in the example or the incoming request but not in both. The number of matching parameters is used to calculate the matching percentage. The percentage equals the number of parameter matches divided by the sum of all parameter matches, partial parameter matches, and missing parameters. ### 6. Check for header and body matching You can [enable header and request body matching](/docs/design-apis/mock-apis/set-up-mock-servers/#match-request-body-and-headers) in the mock server configuration. You can also enable header and body matching by passing the `x-mock-match-request-body` or `x-mock-match-request-headers` custom header with the request. These custom headers have higher precedence than header or body matching values specified in the mock server configuration. If you enable request body matching, you must add the `Content-Type` header to your examples and use the same value as your request, such as `application/json`. When header and body matching are enabled, the algorithm: 1. Filters out all examples that don't match the specified request headers. Header matching is case insensitive. 1. Filters out all examples that don't match the request body. ### 7. Select the highest matching score The matching algorithm checks the matching scores of the remaining examples and returns the example with the highest score. * If more than one example has the highest score, Postman sorts the examples by ID and returns the first example in the list with a `200` response status code. * If none of the highest-scoring examples has a `200` response status code, Postman returns the first example in the sorted list. ## Use wildcard variables All variables in an example's request that don't exist in the mock server's associated collection or environment are treated as _wildcard variables_. Wildcard variables act as capture groups for dynamic URL segments and applies to entire URL path segments. This is useful if some segments of the API's URL map to resource identifiers, like user IDs, user names, or file names. For example, you can mock an endpoint that returns a user profile by ID. The endpoint takes in the user ID from the URL and returns the user ID in the response. On calling the GET `{{url}}/users/{{userId}}` endpoint, it returns: ```json { "id": 2, "name": "Carol" } ``` ### Wildcard variables in responses Wildcards in response bodies aren't part of the matching algorithm. You can add the same variables in the example's response to use their captured values. For example, you can add a request body for the previous example: ```js { "id": {{userId}}, "name": "Carol" } ``` This passes the value captured from the wildcard segment to the same variable name into the response. ## Troubleshooting mock server responses If the mock server isn't returning the example you expect for a request, try the following: * **Add different path variables to your examples.** Two examples with the same path variables are assigned the same matching score. In this case, Postman returns one of the examples. To make sure more than one example isn't assigned the same matching score, use different path variables for each of your examples. * **Use request body matching to return a specific example.** When you [enable request body matching](/docs/design-apis/mock-apis/set-up-mock-servers/#match-request-body-and-headers), Postman returns the example that has the same body as your request. Your request uses the `Content-Type` header with a value like `application/json`, if the body is in JSON format. For Postman to return the correct example, you must use the `Content-Type` header in your example with the same value as your request. * **Use optional headers to return a specific example.** You can make sure the mock server returns a specific example by using the `x-mock-response-name` or `x-mock-response-id` header in your request. Postman returns the example with the matching name or UID. * **Make sure to use unique names for all saved examples in the mocked collection.** If more than one example in the collection has the same name, you may not get the expected response when using the `x-mock-response-name` header. Optionally, use the `x-mock-response-id` header to get the correct response. To find the ID of a saved example, select it in the sidebar, then click ![Image 2: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) **Info** in the right sidebar. * **Filter out examples by response status code.** You can use the `x-mock-response-code` header in your request to specify the response status code you want. Any examples that don't have the matching response status code are removed from the matching process. --- # Mock APIs with response examples [Mock servers](/docs/design-apis/mock-apis/set-up-mock-servers/) simulate an API server by returning predefined data, so you can develop or test an API before it's ready for production. In Postman, mock servers use [examples](/docs/sending-requests/response-data/examples/) saved in an HTTP collection to return mock data. In this tutorial, you'll learn how mock servers and examples work together and how to integrate them into your API workflow. ## Create a new collection and request To get started, you'll need to create a collection and an example response. 1. Click ![Image 1: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) in the sidebar. Select **Blank collection** and give it the "C1" name. 2. In the collection, click **Add a request** to create a request. Optionally, you can rename the request. 3. Select the **GET** method, then enter `https://postman-echo.com/get?test=123` as the request URL. 4. Click **Send**, then click ![Image 2: Save icon](https://assets.postman.com/postman-docs/aether-icons/action-save-stroke.svg#icon) **Save** to save the request in the **C1** collection. ![Image 3: Send a request](https://assets.postman.com/postman-docs/v11/mock-examples-step1-v11.png) ## Save a response as an example Save the response you received from the Postman Echo service as an example. 1. Click ![Image 4: Example icon](https://assets.postman.com/postman-docs/aether-icons/entity-example-stroke.svg#icon) **Save Response** to save the example in the request. 2. (Optional) Rename the example (for example, "E1"). The request method, URL, and status code are all saved as part of the example. Postman uses these items to decide which responses the mock server returns. ## Send a request to the mock server Next, create a mock server for the **C1** collection. 1. Click **Mock servers** in the sidebar. 2. [Create a mock server](/docs/design-apis/mock-apis/set-up-mock-servers/#create-a-mock-server) for the **C1** collection. For this tutorial, name the mock server "M1". 3. Click ![Image 5: Save icon](https://assets.postman.com/postman-docs/aether-icons/action-save-stroke.svg#icon) **Save** to save the mock server. 4. Click ![Image 6: Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy URL** to copy the "M1" mock server's URL. ![Image 7: Copy mock URL](https://assets.postman.com/postman-docs/v11/mock-examples-step5a-v11.23.jpg) 1. In the **C1** collection, create a new request. 2. Paste the mock URL as the request's URL, then click **Send**. ![Image 8: Mock server error response](https://assets.postman.com/postman-docs/v11/mock-examples-step5b-v11-42.jpg) The request returns an error because the mock server's URL doesn't have a defined path. The path appended to the end of the mock server URL must match the path in the example's request URL (`/get`). The method selected in the mock server and example must also match. Responses returned by the mock service depend on the URL and method in your saved examples. 1. To send a request to the mock server, add `/get` to the end of the mock server's URL, then click **Send**. ![Image 9: Mock server correct response](https://assets.postman.com/postman-docs/v11/mock-examples-step5c-v11-42.jpg) ### Add another example You can add another example to test how responses from the mock service depend on saved examples. 1. [Create and send a request](#send-a-request-to-the-mock-server). Select the **GET** method, then enter `https://postman-echo.com/test` as the request URL. 2. Save the request to the **C1** collection. 3. [Save the response as an example](#save-a-response-as-an-example). Rename the example to "E2". ![Image 10: Add a second example](https://assets.postman.com/postman-docs/v11/mock-examples-step6a-v11.23.jpg) 4. [Send a request to the mock server](#send-a-request-to-the-mock-server). Update the path at the end of the mock server URL to `/test` and click **Send**. The mock server returns the expected HTTP 404 Not Found status code. ![Image 11: Send another request to the mock server](https://assets.postman.com/postman-docs/v11/mock-examples-step6b-v11-42.jpg) **Your examples can vary depending on the URL endpoint, request method, or status code.** If you have multiple examples, you can choose to save each example under a unique endpoint URL, like you saw in this demonstration with `/get` and `/test`. If you've saved examples with different response status codes, you can send an authenticated request to the mock server along with the `x-mock-response-code` header specifying which integer response code your returned response needs to match. ## Use query parameters Postman's mock service uses a [matching algorithm](/docs/design-apis/mock-apis/matching-algorithm/) to select the best saved example to return in response to a request. As part of this algorithm, the mock server looks at the request's path and query parameters, and then matches the request to a saved example. If you have examples with the same request path but different query parameters, you can mock different responses for different query parameters on the same request path. The following scenario demonstrates how the matching algorithm selects the best saved example: * A mocked collection has one request named **Request1** with two examples named **Example1** and **Example2**. * In **Example1**, the `id` parameter has a `1` value. ![Image 12: Query parameters example 1](https://assets.postman.com/postman-docs/v11/mock-examples-params1-v11.23.jpg) * In **Example2**, the `id` parameter has a `5` value. ![Image 13: Query parameters example 2](https://assets.postman.com/postman-docs/v11/mock-examples-params2-v11.23.jpg) * In this scenario, **Example1** and **Example2** have the same request path (`/get`), but they each have an `id` query parameter with different values. When you send a request to the mock server URL and pass these different query parameters, Postman returns the exact response that matches both the path and the query parameters. ![Image 14: Query parameters mock response](https://assets.postman.com/postman-docs/v11/mock-examples-params3-v11-42.jpg) If no exact match is found, Postman returns the best response based on its [matching algorithm](/docs/design-apis/mock-apis/matching-algorithm/). ## Mock GraphQL queries Postman's mock service enables you to mock GraphQL queries. To mock GraphQL queries, make a request to the mock server using the request path and request body saved in the examples in the mocked collection. Make sure to set the `Content-type: application/json` header to in your examples. ![Image 15: Query parameters example](https://assets.postman.com/postman-docs/v11/mock-examples-graphql1-v11.23.jpg) --- # mqtt-client-overview MQTT overview ============= MQTT (Message Queuing Telemetry Transport) is a messaging protocol for the Internet of Things (IoT). Its usage spans from small devices for home automation and wearables, to automating large-scale industrial machineries. It's a lightweight technology where clients connected to a single broker can publish messages to different topics and subscribe to topics to receive messages from other connected clients. The messages are transferred with low-bandwidth usage, low-power consumption, and efficient distribution of information to one or many receivers, all adding to the popularity of MQTT. ## Work with MQTT APIs using Postman Postman provides you with a client interface to debug your MQTT-based APIs. If you haven't already, [download and install the Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to get started. You can do any of the following when you create a new MQTT request: * Connect to a broker. * Subscribe to topics. * Publish messages. * View messages received from the broker. After saving your MQTT request into a collection, you can do the following: * Reuse it later. * Document it. * Share it with your teammates. * Publish it to the community on the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). ![MQTT interface](https://assets.postman.com/postman-docs/v11/mqtt-hero-v11-60-1.png) ## Next steps Get started with MQTT with the following topics: * [Using the MQTT request interface](/docs/sending-requests/mqtt-client/mqtt-request-interface/) * [Creating your first MQTT request](/docs/sending-requests/mqtt-client/first-mqtt-request/) --- ### Work with MQTT APIs using Postman Postman provides you with a client interface to debug your MQTT-based APIs. If you haven't already, [download and install the Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to get started. You can do any of the following when you create a new MQTT request: * Connect to a broker. * Subscribe to topics. * Publish messages. * View messages received from the broker. After saving your MQTT request into a collection, you can do the following: * Reuse it later. * Document it. * Share it with your teammates. * Publish it to the community on the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). ![MQTT interface](https://assets.postman.com/postman-docs/v11/mqtt-hero-v11-60-1.png) ## Next steps Get started with MQTT with the following topics: * [Using the MQTT request interface](/docs/sending-requests/mqtt-client/mqtt-request-interface/) * [Creating your first MQTT request](/docs/sending-requests/mqtt-client/first-mqtt-request/) --- ### Work with MQTT APIs using Postman Postman provides you with a client interface to debug your MQTT-based APIs. If you haven't already, [download and install the Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to get started. You can do any of the following when you create a new MQTT request: * Connect to a broker. * Subscribe to topics. * Publish messages. * View messages received from the broker. After saving your MQTT request into a collection, you can do the following: * Reuse it later. * Document it. * Share it with your teammates. * Publish it to the community on the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). ![MQTT interface](https://assets.postman.com/postman-docs/v11/mqtt-hero-v11-60-1.png) --- # openapi2 You can use Postman to identify any potential security and formatting issues when defining your API. ![OpenAPI 2.0 rule violations](https://assets.postman.com/postman-docs/v11/api-definition-rule-violations-openapi2-v11.jpg) ## Warnings for OpenAPI 2 For all APIs defined in OpenAPI 2.0, the following list describes possible warning messages and potential ways to resolve them. * [Broken object level authorization](#broken-object-level-authorization) * [Scope for OAuth scheme used in security field is not defined in the securityDefinition declaration](#scope-for-oauth-scheme-used-in-security-field-is-not-defined-in-the-securitydefinition-declaration) * [Scope for OAuth scheme used is not defined in the securityDefinition declaration](#scope-for-oauth-scheme-used-is-not-defined-in-the-securitydefinition-declaration) * [Broken user authentication](#broken-user-authentication) * [Security field is not defined](#security-field-is-not-defined) * [Security field does not contain any item](#security-field-does-not-contain-any-item) * [Security field does not contain any scheme](#security-field-does-not-contain-any-scheme) * [Security definition object not defined](#security-definition-object-not-defined) * [Security definition object does not contain any scheme](#security-definition-object-does-not-contain-any-scheme) * [Scheme used in security field is not defined in the security definition object](#scheme-used-in-security-field-is-not-defined-in-the-security-definition-object) * [Security field for the operation does not contain any item](#security-field-for-the-operation-does-not-contain-any-item) * [Security field for the operation does not contain any scheme](#security-field-for-the-operation-does-not-contain-any-scheme) * [Operation does not enforce any security scheme](#operation-does-not-enforce-any-security-scheme) * [Excessive data exposure](#excessive-data-exposure) * [API accepts credentials from OAuth authentication in plain text](#api-accepts-credentials-from-oauth-authentication-in-plain-text) * [API accepts API key in plain text](#api-accepts-api-key-in-plain-text) * [API accepts basic authentication credentials in plain text](#api-accepts-basic-authentication-credentials-in-plain-text) * [Global schemes have HTTP scheme defined](#global-schemes-have-http-scheme-defined) * [Operation accepts credentials from OAuth authentication in plain text](#operation-accepts-credentials-from-oauth-authentication-in-plain-text) * [Operation accepts API key in plain text](#operation-accepts-api-key-in-plain-text) * [Operation accepts basic authentication credentials in plain text](#operation-accepts-basic-authentication-credentials-in-plain-text) * [Schemes of the operation have HTTP scheme defined](#schemes-of-the-operation-have-http-scheme-defined) * [Authorization URL uses HTTP protocol; credentials will be transferred as plain text](#authorization-url-uses-http-protocol-credentials-will-be-transferred-as-plain-text) * [Token URL uses HTTP protocol](#token-url-uses-http-protocol) * [Produces field is not defined](#produces-field-is-not-defined) * [Produces field does not contain any item](#produces-field-does-not-contain-any-item) * [Produces field for the operation does not contain any item](#produces-field-for-the-operation-does-not-contain-any-item) * [Operation does not contain produces field](#operation-does-not-contain-produces-field) * [Injection](#injection) * [Consumes field is not defined](#consumes-field-is-not-defined) * [Consumes field does not contain any item](#consumes-field-does-not-contain-any-item) * [Consumes field for the operation does not contain any item](#consumes-field-for-the-operation-does-not-contain-any-item) * [Operation does not contain consumes field](#operation-does-not-contain-consumes-field) * [Improper assets management](#improper-assets-management) * [OAuth authentication uses the deprecated implicit flow](#oauth-authentication-uses-the-deprecated-implicit-flow) * [OAuth authentication uses the deprecated password flow](#oauth-authentication-uses-the-deprecated-password-flow) * [API information](#api-information) * [The info object should have a description](#the-info-object-should-have-a-description) * [The info object should have a license](#the-info-object-should-have-a-license) * [The info object should have a license URL](#the-info-object-should-have-a-license-url) * [The info object should have a terms of service](#the-info-object-should-have-a-terms-of-service) * [API must have contact information available](#api-must-have-contact-information-available) * [API must have a contact name available](#api-must-have-a-contact-name-available) * [API must have a contact URL or email available](#api-must-have-a-contact-url-or-email-available) * [API must have a contact email available](#api-must-have-a-contact-email-available) * [API must have a contact URL available](#api-must-have-a-contact-url-available) * [Operations](#operations) * [There should be no trailing slashes on paths](#there-should-be-no-trailing-slashes-on-paths) * [All operations should have summaries](#all-operations-should-have-summaries) * [Operation summaries shouldn't end with a period](#operation-summaries-shouldnt-end-with-a-period) * [All operations should have descriptions](#all-operations-should-have-descriptions) * [All parameters should have descriptions](#all-parameters-should-have-descriptions) * [POST methods should have request bodies](#post-methods-should-have-request-bodies) * [PUT methods should have request bodies](#put-methods-should-have-request-bodies) * [PATCH methods should have request bodies](#patch-methods-should-have-request-bodies) * [All request bodies should have examples](#all-request-bodies-should-have-examples) * [Operation should return a 2xx HTTP status code](#operation-should-return-a-2xx-http-status-code) * [Operation should return a 5xx HTTP status code](#operation-should-return-a-5xx-http-status-code) * [All responses should have examples](#all-responses-should-have-examples) * [A 204 response can't have a body](#a-204-response-cant-have-a-body) * [Models](#models) * [A schema property should reference a reusable schema](#a-schema-property-should-reference-a-reusable-schema) * [All reusable schemas should have descriptions](#all-reusable-schemas-should-have-descriptions) * [All schema properties should have descriptions](#all-schema-properties-should-have-descriptions) * [Arrays must have `minItems` and `maxItems` defined](#arrays-must-have-minitems-and-maxitems-defined) ## Broken object level authorization ### Scope for OAuth scheme used in security field is not defined in the securityDefinition declaration | Issue description | Possible fix | | --- | --- | | The OAuth2 scopes used in the global security field need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. | #### Resolution ```json swagger: '2.0' #... security: - OAuth2: - read - write securityDefinitions: OAuth2: type: oauth2 flow: accessCode scopes: read: read object write: writes object authorizationUrl: https://example.com/authorize tokenUrl: https://example.com/token ``` ### Scope for OAuth scheme used is not defined in the securityDefinition declaration | Issue description | Possible fix | | --- | --- | | The OAuth2 scopes used in the security field of the operation need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. | #### Resolution ```json swagger: '2.0' #... paths: '/user': get: summary: 'Sample endpoint: Returns details about a particular user' operationId: listUser security: - OAuth2: - read - write securityDefinitions: OAuth2: type: oauth2 flow: accessCode scopes: read: read object write: writes object authorizationUrl: https://example.com/authorize tokenUrl: https://example.com/token ``` ## Broken user authentication ### Security field is not defined | Issue description | Possible fix | | --- | --- | | If the global security field isn't defined, the API doesn't require any authentication by default. Anyone can access the API operations that don't have a security field defined. | The security field needs to be defined in the schema. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic security: - basicAuth: [] ``` ### Security field does not contain any item | Issue description | Possible fix | | --- | --- | | If the security field has an empty array, no security scheme is applied to the operations by default. | The security field needs to have at least one item in the array. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic security: - basicAuth: [] ``` ### Security field does not contain any scheme | Issue description | Possible fix | | --- | --- | | An empty object in the security field deactivates the authentication. Without security fields defined for each operation, anyone can access the API operations without any authentication. | Security field array items can't have an empty object. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic security: - basicAuth: [] ``` ### Security definition object not defined | Issue description | Possible fix | | --- | --- | | The components object of the API doesn't declare any security definitions which can be used in the security field of the API or individual operations. | Security definitions need to be defined in the schema of the component. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic ``` ### Security definition object does not contain any scheme | Issue description | Possible fix | | --- | --- | | An empty object in the reusable security definition means that no authentication scheme is defined for each operation, anyone can access the API operations without any authentication. | Security definitions need to have at least one item in the object. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic ``` ### Scheme used in security field is not defined in the security definition object | Issue description | Possible fix | | --- | --- | | The authentication scheme used in global or operation security field isn't defined in the security definition object. | The scheme used in the security field needs to be defined in the security definition object. | #### Resolution ```json swagger: '2.0' #... securityDefinitions: basicAuth: type: basic security: - basicAuth: [] ``` ### Security field for the operation does not contain any item | Issue description | Possible fix | | --- | --- | | No security scheme is applied to the API operation by default. | The security field in any operation needs to have at least one item in the array. | #### Resolution ```json swagger: '2.0' #... paths: /user: get: description: 'Returns details about a particular user' security: - basicAuth: [] #... securityDefinitions: basicAuth: type: basic ``` ### Security field for the operation does not contain any scheme | Issue description | Possible fix | | --- | --- | | An empty object in the security field deactivates the authentication for the operation. Anyone can access the API operation without any authentication. | Specify at least one security requirement in the operation. | #### Resolution ```json swagger: '2.0' #... paths: /user: get: description: 'Returns details about a particular user' security: - basicAuth: [] #... securityDefinitions: basicAuth: type: basic ``` ### Operation does not enforce any security scheme | Issue description | Possible fix | | --- | --- | | If both the global security field and operation's security field aren't defined, anyone can access the API without any authentication. | Define a security field in the operation. | #### Resolution ```json swagger: '2.0' #... paths: /user: get: description: 'Sample endpoint: Returns details about a particular user' security: - basicAuth: [] #... securityDefinitions: basicAuth: type: basic ``` ## Excessive data exposure ### API accepts credentials from OAuth authentication in plain text | Issue description | Possible fix | | --- | --- | | The access tokens are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the scheme used in the schemes array is HTTPS. | #### Resolution ```json swagger: '2.0' #... host: 'example.com' schemes: - https securityDefinitions: OAuth2: type: oauth2 flow: accessCode authorizationUrl: https://my.auth.example.com/ tokenUrl: https://my.token.example.com/ security: - OAuth2: [] ``` ### API accepts API key in plain text | Issue description | Possible fix | | --- | --- | | API keys are sent as plain text over an unencrypted channel. Attackers can intercept API key by listening to the network traffic in a public Wi-Fi network. | Make sure that the scheme used in the scheme array is HTTPS. | #### Resolution ```json swagger: '2.0' #... host: 'example.com' schemes: - https securityDefinitions: apiKeyAuth: type: apiKey name: api_key in: header security: - apiKeyAuth: [] ``` ### API accepts basic authentication credentials in plain text | Issue description | Possible fix | | --- | --- | | The credentials are sent as plain text over an unencrypted network. Attackers can intercept the credentials by listening to the network traffic in a public Wi-Fi network. | Make sure that the scheme used in the scheme array is HTTPS. | #### Resolution ```json swagger: '2.0' #... host: 'example.com' schemes: - https securityDefinitions: basicAuth: type: basic security: - basicAuth: [] ``` ### Global schemes have HTTP scheme defined | Issue description | Possible fix | | --- | --- | | The server supports unencrypted HTTP connections, all requests and responses will be transmitted in the open. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the scheme used in the scheme array is HTTPS. | #### Resolution ```json swagger: '2.0' #... host: 'example.com' schemes: - https #... ``` ### Operation accepts credentials from OAuth authentication in plain text | Issue description | Possible fix | | --- | --- | | The API operation accepts the access tokens from a flow that are transported in plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the unencrypted tokens. They can then use the tokens to make other API calls. | Make sure that the scheme used in the scheme array of the operation is HTTPS.| --- # openapi3 You can use Postman to identify any potential security and formatting issues when defining your API. ![Image 1: OpenAPI 3.0 rule violations](https://assets.postman.com/postman-docs/v11/api-definition-rule-violations-openapi3-v11-b.jpg) ## Warnings for OpenAPI 3 For all APIs defined in OpenAPI 3.0 and 3.1, the following list describes possible warning messages and potential ways to resolve them. * [Broken object level authorization](#broken-object-level-authorization) * [Scope for OAuth scheme used in security field is not defined in the securityScheme declaration](#scope-for-oauth-scheme-used-in-security-field-is-not-defined-in-the-securityscheme-declaration) * [Scope for OAuth scheme used is not defined in the securityScheme declaration](#scope-for-oauth-scheme-used-is-not-defined-in-the-securityscheme-declaration) * [Broken user authentication](#broken-user-authentication) * [Security field is not defined](#security-field-is-not-defined) * [Security field does not contain any item](#security-field-does-not-contain-any-item) * [Security field does not contain any scheme](#security-field-does-not-contain-any-scheme) * [Security scheme object not defined](#security-scheme-object-not-defined) * [Security scheme object does not contain any scheme](#security-scheme-object-does-not-contain-any-scheme) * [Scheme used in security field is not defined in the security scheme object](#scheme-used-in-security-field-is-not-defined-in-the-security-scheme-object) * [HTTP authentication scheme is using an unknown scheme](#http-authentication-scheme-is-using-an-unknown-scheme) * [Security field for the operation does not contain any item](#security-field-for-the-operation-does-not-contain-any-item) * [Security field for the operation does not contain any scheme](#security-field-for-the-operation-does-not-contain-any-scheme) * [Operation does not enforce any security scheme](#operation-does-not-enforce-any-security-scheme) * [Excessive data exposure](#excessive-data-exposure) * [API accepts credentials from OAuth authentication in plain text](#api-accepts-credentials-from-oauth-authentication-in-plain-text) * [API accepts credentials from OpenID Connect authentication in plain text](#api-accepts-credentials-from-openid-connect-authentication-in-plain-text) * [API accepts credentials from OAuth 1.0 authentication in plain text](#api-accepts-credentials-from-oauth-10-authentication-in-plain-text) * [API accepts API key in plain text](#api-accepts-api-key-in-plain-text) * [API accepts auth credentials in plain text](#api-accepts-auth-credentials-in-plain-text) * [Global server URL uses HTTP protocol](#global-server-url-uses-http-protocol) * [Operation accepts credentials from OAuth authentication in plain text](#operation-accepts-credentials-from-oauth-authentication-in-plain-text) * [Operation accepts credentials from OpenID Connect authentication as plain text](#operation-accepts-credentials-from-openid-connect-authentication-as-plain-text) * [Operation accepts credentials from OAuth 1.0 authentication in plain text](#operation-accepts-credentials-from-oauth-10-authentication-in-plain-text) * [Operation accepts API key in plain text](#operation-accepts-api-key-in-plain-text) * [Operation accepts authentication credentials in plain text](#operation-accepts-authentication-credentials-in-plain-text) * [Server URL of the operation is using HTTP protocol](#server-url-of-the-operation-is-using-http-protocol) * [Authorization URL uses HTTP protocol; credentials will be transferred as plain text](#authorization-url-uses-http-protocol-credentials-will-be-transferred-as-plain-text) * [Token URL uses HTTP protocol](#token-url-uses-http-protocol) * [Refresh URL uses HTTP protocol](#refresh-url-uses-http-protocol) * [OpenID Connect URL uses HTTP protocol](#openid-connect-url-uses-http-protocol) * [Improper assets management](#improper-assets-management) * [Deprecated OAuth 1.0 scheme is used](#deprecated-oauth-10-scheme-is-used) * [OAuth authentication uses the deprecated implicit flow](#oauth-authentication-uses-the-deprecated-implicit-flow) * [OAuth authentication uses the deprecated password flow](#oauth-authentication-uses-the-deprecated-password-flow) * [API information](#api-information) * [The info object should have a description](#the-info-object-should-have-a-description) * [The info object should have a license](#the-info-object-should-have-a-license) * [The info object should have a license URL](#the-info-object-should-have-a-license-url) * [The info object should have a terms of service](#the-info-object-should-have-a-terms-of-service) * [API must have contact information available](#api-must-have-contact-information-available) * [API must have a contact name available](#api-must-have-a-contact-name-available) * [API must have a contact URL or email available](#api-must-have-a-contact-url-or-email-available) * [API must have a contact email available](#api-must-have-a-contact-email-available) * [API must have a contact URL available](#api-must-have-a-contact-url-available) * [Operations](#operations) * [There should be no trailing slashes on paths](#there-should-be-no-trailing-slashes-on-paths) * [All operations should have summaries](#all-operations-should-have-summaries) * [Operation summaries shouldn't end with a period](#operation-summaries-shouldnt-end-with-a-period) * [All operations should have descriptions](#all-operations-should-have-descriptions) * [All parameters should have descriptions](#all-parameters-should-have-descriptions) * [All parameters should have examples](#all-parameters-should-have-examples) * [POST methods should have request bodies](#post-methods-should-have-request-bodies) * [PUT methods should have request bodies](#put-methods-should-have-request-bodies) * [PATCH methods should have request bodies](#patch-methods-should-have-request-bodies) * [All request bodies should have examples](#all-request-bodies-should-have-examples) * [Operation should return a 2xx HTTP status code](#operation-should-return-a-2xx-http-status-code) * [Operation should return a 5xx HTTP status code](#operation-should-return-a-5xx-http-status-code) * [All responses should have examples](#all-responses-should-have-examples) * [A 204 response can't have a body](#a-204-response-cant-have-a-body) * [Models](#models) * [A schema property should reference a reusable schema](#a-schema-property-should-reference-a-reusable-schema) * [All reusable schemas should have descriptions](#all-reusable-schemas-should-have-descriptions) * [All schema properties should have descriptions](#all-schema-properties-should-have-descriptions) * [Arrays must have `minItems` and `maxItems` defined](#arrays-must-have-minitems-and-maxitems-defined) ## Broken object level authorization ### Scope for OAuth scheme used in security field is not defined in the securityScheme declaration | Issue description | Possible fix | | --- | --- | | The OAuth2 scopes used in the global security field need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. | #### Resolution ```json security: - OAuth2: - read - write components: securitySchemes: OAuth2: type: oauth2 flows: authorizationCode: scopes: read: read objects in your account write: write objects to your account ``` ### Scope for OAuth scheme used is not defined in the securityScheme declaration | Issue description | Possible fix | | --- | --- | | The OAuth2 scopes used in the security field of the operation need to be defined in the security schemes field. Otherwise, an attacker can introduce their scopes to fill the gap and exploit the system. | Make sure that all the OAuth2 scopes used are defined in the OAuth2 security scheme. | #### Resolution ```json paths: /user: get: summary: 'Sample endpoint: Returns details about a particular user' operationId: listUser security: - OAuth2: - read - write components: securitySchemes: OAuth2: type: oauth2 flows: authorizationCode: scopes: read: read objects in your account write: write objects to your account ``` ## Broken user authentication ### Security field is not defined | Issue description | Possible fix | | --- | --- | | If the global security field isn't defined, the API doesn't require any authentication by default. Anyone can access the API operations that don't have a security field defined. | The security field needs to be defined in the schema. | #### Resolution ```json openapi: 3.0.0 info: paths: security: - testAuth : [] ``` ### Security field does not contain any item | Issue description | Possible fix | | --- | --- | | If the security field has an empty array, no security scheme is applied to the operations by default. | The security field needs to have at least one item in the array. | #### Resolution ```json openapi: 3.0.0 info: paths: security: - testAuth : [] ``` ### Security field does not contain any scheme | Issue description | Possible fix | | --- | --- | | An empty object in the security field deactivates the authentication. Without security fields defined for each operation, anyone can access the API operations without any authentication. | Security field array items can't have an empty object. | #### Resolution ```json openapi: 3.0.0 info: paths: security: - testAuth : [] ``` ### Security scheme object not defined | Issue description | Possible fix | | --- | --- | | The components object of the API doesn't declare any security schemes which can be used in the security field of the API or individual operations. | Security schemes need to be defined in the schema of the component. | #### Resolution ```json components: securitySchemes: testAuth: type: http scheme: basic ``` ### Security scheme object does not contain any scheme | Issue description | Possible fix | | --- | --- | | An empty object in the reusable security schemes means that no authentication scheme is defined for each operation, anyone can access the API operations without any authentication. | Security schemes need to have at least one item in the object. | #### Resolution ```json components: securitySchemes: BasicAuth: type: http scheme: basic ``` ### Scheme used in security field is not defined in the security scheme object | Issue description | Possible fix | | --- | --- | | The authentication scheme used in global or operation security field isn't defined in the security scheme object. | The scheme used in the security field needs to be defined in the security scheme object. | #### Resolution ```json components: securitySchemes: BasicAuth: type: http scheme: basic #... security: - BasicAuth: [] ``` ## Excessive data exposure ### API accepts credentials from OAuth authentication in plain text | Issue description | Possible fix | | --- | --- | | The access tokens are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json servers: - url: https://my.api.example.com/ description: API server # ... components: securitySchemes: OAuth2: type: oauth2 # ... security: - OAuth2: - write - read ``` ### API accepts credentials from OpenID Connect authentication in plain text | Issue description | Possible fix | | --- | --- | | The credentials are sent as plain text over an unencrypted network. Attackers can intercept the access tokens by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json components: securitySchemes: OpenIdScheme: type: openIdConnect openIdConnectUrl: https://example.com/connect paths: '/pets': post: operationId: addPet servers: - url: https://example.com/ description: API server security: - OpenIdScheme: [] ``` ### API accepts credentials from OAuth 1.0 authentication in plain text | Issue description | Possible fix | | --- | --- | | The authentication tokens are sent as plain text over an unencrypted channel. Attackers can intercept the token by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json servers: - url: https://my.api.example.com/ description: API server #... components: securitySchemes: OAuth1: type: http scheme: oauth #... security: - OAuth1: [] ``` ### API accepts API key in plain text | Issue description | Possible fix | | --- | --- | | API keys are sent as plain text over an unencrypted channel. Attackers can intercept API key by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json servers: - url: https://example.com/ description: Example server components: securitySchemes: BasicAuth: type: http scheme: basic security: - BasicAuth: [] ``` ### API accepts auth credentials in plain text | Issue description | Possible fix | | --- | --- | | The credentials are sent as plain text over an unencrypted network. Attackers can intercept the credentials by listening to the network traffic in a public Wi-Fi network. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json servers: - url: https://example.com/ description: Example server # ... components: securitySchemes: AuthKeyAuth: type: apiKey name: api-key in: header #... security: - AuthKeyAuth: [] ``` ### API accepts authentication credentials in plain text | Issue description | Possible fix | | --- | --- | | The API operation accepts the credentials that are transported in plain text over an unencrypted channel. Attackers can intercept API calls and retrieve the authentication credentials to make other API calls. | Make sure that the server URL of the operation is a valid URL and uses HTTPS protocol. | #### Resolution ```json components: securitySchemes: BasicAuth: type: http scheme: basic paths: '/pets': post: operationId: addPet servers: - url: https://example.com/ description: Example server security: - BasicAuth: [] ``` ### Server URL of the operation is using HTTP protocol | Issue description | Possible fix | | --- | --- | | The API operation supports unencrypted HTTP connections, all requests and responses will be transmitted in the open. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the server URL is a valid URL and uses HTTPS protocol. | #### Resolution ```json get: operationId: getPetsById servers: - url: https://my.api.example.com/ ``` ### Authorization URL uses HTTP protocol; credentials will be transferred as plain text | Issue description | Possible fix | | --- | --- | | OAuth authorization credentials are transported over an unencrypted channel. Anyone listening to the network traffic while the calls are being made can intercept them. | Make sure that the authorization URL is a valid URL and follows HTTPS protocol. | #### Resolution ```json components: securitySchemes: OauthScheme: type: oauth2 flows: authorizationCode: authorizationUrl: https://my.auth.example.com/ ``` ### Token URL uses HTTP protocol | Issue description | Possible fix | | --- | --- | | OAuth authentication tokens are transported over an unencrypted channel. Anyone listening to the network traffic while the token is being sent can intercept it. | Make sure that the token URL is a valid URL and follows HTTPS protocol. | #### Resolution ```json components: securitySchemes: OauthScheme: type: oauth2 flows: authorizationCode: tokenUrl: https://my.token.example.com/ ``` ### Refresh URL uses HTTP protocol | Issue description | Possible fix | | --- | --- | | OAuth authentication refresh tokens are transported over an unencrypted channel. Anyone listening to the network traffic while the token is being sent can intercept it. | Make sure that the refresh URL is a valid URL and follows HTTPS protocol. | #### Resolution ```json components: securitySchemes: OauthFlow: type: oauth2 flows: authorizationCode authorizationUrl: https://my.auth.example.com/ tokenUrl: https://my.token.example.com/ refreshUrl: https://my.refresh.example.com/ scopes: write: modify data read: read data ``` ## Improper assets management ### Deprecated OAuth 1.0 scheme is used | Issue description | Possible fix | | --- | --- | | Security scheme uses OAuth 1.0 authentication which has been deprecated and replaced by OAuth 2.0. | Make sure that the security scheme isn't using the deprecated OAuth 1.0 authentication. | #### Resolution ```json components: securitySchemes: OauthFlow: type: oauth2 flows: authorizationCode: authorizationUrl: https://my.auth.example.com/ tokenUrl: https://my.token.example.com/ scopes: write: modify data read: read data ``` ### OAuth authentication uses the deprecated implicit flow | Issue description | Possible fix | | --- | --- | | In OAuth implicit flow, authorization server issues access tokens in the authorization request's response. Attackers can intercept API calls and retrieve the access tokens to make other API calls. | It's recommended to use authorizationCode flow. Make sure that the OAuth authentication scheme isn't using the implicit flow. | #### Resolution ```json components: securitySchemes: OauthFlow: type: oauth2 flows: authorizationCode: authorizationUrl: https://my.auth.example.com/ tokenUrl: https://my.token.example.com/ scopes: write: modify data read: read data ``` ### OAuth authentication uses the deprecated password flow | Issue description | Possible fix | | --- | --- | | OAuth password grant flow uses the user's credentials to retrieve the access token. Attackers can intercept API calls and retrieve the access tokens to make other API calls. | It's recommended to use authorizationCode flow. Make sure that the OAuth authentication scheme isn't using the password grant flow. | #### Resolution ```json components: securitySchemes: OauthFlow: type: oauth2 flows: authorizationCode: authorizationUrl: https://my.auth.example.com/ tokenUrl: https://my.token.example.com/ scopes: write: modify data read: read data ``` ## API information This rule category deals with the OpenAPI info object, which has metadata about the API. ### The info object should have a description | Issue description | Possible fix | | --- | --- | | Your API definition's [info object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#info-object) doesn't have a description. Although a description isn't required, including one enables you to provide your API's consumers with information about what the API does and how to use it. This can be anything from a short description to a long explanation of possible uses cases. For your organization, defining the API's description during the design phase can help set the boundaries of the API. | Add a description to your API definition's info object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' description: An API description ``` ### The info object should have a license | Issue description | Possible fix | | --- | --- | | Your API definition's [info object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#info-object) doesn't have a [license object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#license-object), which helps your API's consumers know how the API can be copied and used. | Add a license object to your API definition's info object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' license: name: Apache 2.0 url: https://opensource.org/licenses/Apache-2.0 ``` ### The info object should have a license URL | Issue description | Possible fix | | --- | --- | | Your API definition's [license object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#license-object) doesn't have a license URL, which provides a link to a web page that describes the license. Although a license URL isn't required, a license name alone may not be not enough information for your API's consumers, especially when you use a custom license. | Add a URL to your API definition's license object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' license: name: Apache 2.0 url: https://opensource.org/licenses/Apache-2.0 ``` ### The info object should have a terms of service | Issue description | Possible fix | | --- | --- | | Your API definition's [info object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#info-object) doesn't have the URL of the API's Terms of Service. A terms of service is often mandatory for public APIs. It's also recommended that private APIs provide a link to a Terms and Conditions web page. | Add the URL of the API's Terms of Service to your API definition's info object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' termsOfService: https://example.com/tos ``` ### API must have contact information available | Issue description | Possible fix | | --- | --- | | Your API definition's [info object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#info-object) doesn't have a [contact object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#contact-object), which has contact information like a name, email address, or URL. Contact information defines a designated owner for each of your organization's APIs. The contact data may be used directly by your API's consumers, or through an API portal or catalog. | Add a contact object to your API definition's info object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: email: support@example.com url: https://example.com/support ``` ### API must have a contact name available | Issue description | Possible fix | | --- | --- | | Your API definition's [contact object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#contact-object) doesn't have a contact name. Although a contact name isn't required, it helps your API's consumers understand who owns the API. It also makes your organization consider the API's ownership. | Add a name to your API definition's contact object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: name: A contact name ``` ### API must have a contact URL or email available | Issue description | Possible fix | | --- | --- | | Your API definition's [contact object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#contact-object) doesn't have a contact URL or email address. Although a contact URL or email aren't required, including one or both gives your API's consumers a way to contact your organization or the API owner. | Add a contact URL, an email address, or both to your API definition's contact object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: email: contact@example.com ``` ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: url: https://example.com/support ``` ### API must have a contact email available | Issue description | Possible fix | | --- | --- | | Your API definition's [contact object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#contact-object) doesn't have an email address. Although a contact email isn't required, including one gives your API's consumers a way to contact your organization or the API owner. | Add an email address to your API definition's contact object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: email: support@example.com ``` ### API must have a contact URL available | Issue description | Possible fix | | --- | --- | | Your API definition's [contact object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#contact-object) doesn't have a contact URL. Although a contact URL isn't required, including one gives your API's consumers a way to contact your organization or the API owner. | Add a URL to your API definition's contact object. | #### Resolution ```json openapi: '3.0.3' info: title: An API name version: '1.0' contact: url: https://example.com/support ``` ## Operations This rule category deals with operations on an API path. ### There should be no trailing slashes on paths | Issue description | Possible fix | | --- | --- | | One or more [path item objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#path-item-object) in your API definition's [paths object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#paths-object) have a trailing slash at the end of the path. Some tools treat a path that ends with a trailing slash (`/path/`) differently from the way that they treat paths without a trailing slash (`/path`), which can lead to problems that require long hours of debugging. | Remove any trailing slashes from paths in your API definition's paths object. | #### Resolution ```json openapi: '3.0.3' # ... paths: '/resources': ``` ### All operations should have summaries | Issue description | Possible fix | | --- | --- | | One or more [operation objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object) in your API definition don't have a summary. A summary of what the operation does provides your API's consumers with important context that the HTTP method and path don't provide on their own. Many organizations use the API operation description that they create during the define phase of the API development process as the summary. | Add a summary for each operation object. | #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: get: summary: A GET operation summary ``` ### Operation summaries shouldn't end with a period | Issue description | Possible fix | | --- | --- | | One or more [operation objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object) in your API definition have a summary that ends with a period (`.`). API documentation tools use the summary as a title, so it shouldn't end with a period. | Remove the final period from all summaries at the operations object level in your API definition. | #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: get: summary: A GET operation summary ``` ### All operations should have descriptions | Issue description | Possible fix | | --- | --- | | One or more [operation objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object) in your API definition don't have a description. When the resource path, HTTP method, and summary don't provide enough context for your API's consumers, a description can provide them with useful information about the API operation and its behavior. | Add a description for each operation object. | #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: get: description: A GET operation description ``` ### All parameters should have descriptions | Issue description | Possible fix | | --- | --- | | One or more [parameter objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameter-object) in an [operations object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object) in your API definition don't have a `description` field. When the API name and context don't provide enough information for your API's consumers, a description can provide them with useful information about the parameter. | Add a `description` field for each parameter object. | #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: get: parameters: - name: status description: Filters resources on their status in: query schema: type: string ``` ### All parameters should have examples | Issue description | Possible fix | | --- | --- | | One or more [parameter objects](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#parameter-object) in an [operations object](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#operation-object) in your API definition don't have an `example` or `examples` field. It's important to provide undocumented examples (using the `example` property) or documented examples (using the `examples` property) to help your API's consumers understand what data to provide. It may also help them to generate [mock servers](/docs/design-apis/mock-apis/set-up-mock-servers/) or a [collection](/docs/getting-started/first-steps/creating-the-first-collection/). | Add an `example` or `examples` field to provide your API's consumers with an example of the parameter's potential value. | #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: get: parameters: - name: status description: Filters resources on their status in: query example: done schema: type: string ``` ```json openapi: '3.0.3' # ... paths: /resources: get: parameters: - name: status description: Filters resources on their status in: query examples: anExample: summary: An example description: A description of an example value: aProperty: example value ``` ### POST methods should have request bodies | Issue description | Possible fix | | --- | --- | * [POST methods should have request bodies](#post-methods-should-have-request-bodies) #### Resolution ```json openapi: '3.0.3' # ... paths: /resources: post: requestBody: content: 'application/json': schema: type: object ``` --- # overview-logic-blocks Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman-flows/reference/blocks/evaluate/) * [**Delay**](/docs/postman-flows/reference/blocks/delay/) * [**Or**](/docs/postman-flows/reference/blocks/or/) Last modified: 2025/12/08 Logic blocks overview ===================== _Last modified: 2025/12/08_ * [**Condition**](/docs/postman-flows/reference/blocks/condition/) * [**If**](/docs/postman-flows/reference/blocks/if/) * [**Validate**](/docs/postman-flows/reference/blocks/validate/) * [**Evaluate**](/docs/postman --- # Source: https://learning.postman.com/docs/postman-ai/mcp-requests/overview/ # Source: https://learning.postman.com/docs/postman-ai/ai-request-blocks/overview/ # Source: https://learning.postman.com/docs/postman-ai/ai-requests/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/prepare/curate/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-flows/build-flows/structure/loops/overview/ # Source: https://learning.postman.com/docs/postman-flows/reference/blocks/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/prepare/curate/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/publish/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-flows/reference/blocks/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-ai/mcp-servers/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/design-apis/mock-apis/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/private-api-network/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/versioning-an-api/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/overview/ # Source: https://learning.postman.com/docs/getting-started/account/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-ai/mcp-requests/overview/ # Source: https://learning.postman.com/docs/postman-ai/ai-request-blocks/overview/ # Source: https://learning.postman.com/docs/postman-ai/ai-requests/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/prepare/curate/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-flows/build-flows/structure/loops/overview/ # Source: https://learning.postman.com/docs/postman-flows/reference/blocks/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/prepare/curate/overview/ # Source: https://learning.postman.com/docs/postman-api-network/showcase/publish/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-flows/reference/blocks/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ # Source: https://learning.postman.com/docs/postman-ai/mcp-servers/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/design-apis/mock-apis/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/design-apis/specifications/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/private-api-network/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/versioning-an-api/overview/ # Source: https://learning.postman.com/docs/design-apis/api-builder/overview/ # Source: https://learning.postman.com/docs/getting-started/account/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/ # Source: https://learning.postman.com/docs/collaborating-in-postman/using-workspaces/overview/ # Source: https://learning.postman.com/docs/postman-flows/overview/ Build API-first apps with Postman Flows—a visual, low-code editor | Postman Docs

Build API-first apps with Postman Flows—a visual, low-code editor

You can use the Postman Flows low-code editor to prototype, build, and deploy API-first apps in a collaborative environment. Create flow modules that automate tasks, connect systems, and showcase your APIs to others on your team or the entire world with the Postman API Network. You can also create and deploy special flows called actions that function as API endpoints on the Postman Cloud and can connect to third-party services.

Flows are composable. You can reuse flow modules within other flow modules and actions. This helps you keep your flows organized and efficient, even when you’re using flows to automate complex tasks or processes.

Postman Flows illustration

Starting in Postman version 11.42.3, Postman users on all plans can create, run, edit, and view flow modules and actions in Postman Flows. All plans can run actions locally. The Flows add-on is required to deploy actions in the cloud.

Postman Flows is available as an add-on for users on the Free, Basic and Professional plans. When purchased as an add-on, users have unlimited runs in Postman Flows. Users without a paid Flows seat will be able to run flows a limited number of times each month. Learn more about managing Flows usage.

Get started with Flows

With Postman Flows, you assemble building blocks on an infinite, drag-and-drop canvas. These building blocks may contain data, such as text or a date, or perform a task, such as solving a mathematical problem or sending an API request.

Use the editor and canvas to arrange your blocks to complete nearly any workflow you can imagine. Or you can use the Postman Flows Template Gallery to explore ready-to-use flows. If that sounds like a lot, you can start by building a “Hello, world” flow.

To learn more, see Get started with your Postman Flows API journey.

Build flows

You build flows with blocks and connections. You use blocks to store information or perform a task, and connections to pass information or trigger an action. When you connect two blocks, you connect one block’s input to another block’s output. Inputs are on the block’s left side and outputs are on its right side.

To learn more, see Build flows with Postman’s visual, low-code editor.

Deploy actions

You can build special flows called actions and deploy them to the Postman Cloud. Deployed actions function as API endpoints with public URLs, where external systems can trigger them. Deployed actions can receive requests, process and apply logic to the incoming data, and send responses. Use actions to automate business logic, handle webhooks, connect with third-party services, and create AI-powered tools.

Work with data in flows

In some cases, you may want to use advanced logic to work with data. With Postman Flows, you can use TypeScript or Flows Query Language (FQL) to query and transform data and add conditional logic.

TypeScript (a superset of JavaScript) is a complete programming language you can use to program logic and transform data in Postman Flows. FQL is a query programming language built by Postman for Postman Flows. If you need to query and transform your data, FQL is a great option. If you need to work with more complex logic, TypeScript is a better option.

To learn more, see Introduction to Flows Query Language and Use TypeScript in Postman Flows.

Learn Flows with tutorials

Tutorials are a great way to familiarize yourself with the Flows editor and canvas, and prepare to build your own API-first projects. You can get started with beginning use cases and go further with advanced tutorials. If you prefer to watch videos, you can explore the Flows video tutorials.

To learn more, see Learn how to use Postman Flows with tutorials.

Build flows with AI

With Postman Agent mode, you can use natural language to build or add to your flows. Agent Mode also has skills you can select to accomplish specific tasks.

Postman Community. Icon.

Got some feedback on Postman Flows?

Got some feedback on Postman Flows?

Last modified: 2025/11/24

Postmanaut illustration for Postman Flows section.

Additional resources

Explore ready-to-use Collection Templates, build API-first workflows with Postman Flows, and more!

Collection Templates

Integration testing
REST API basics
API documentation
Authorization methods

Flows Templates

Add HubSpot contacts to Mailchimp lists
Create Airtable records from new deals in HubSpot
Create or update HubSpot contacts from customers on Stripe
Search Zendesk for tickets with Tag using Create with AI

AI Agent Templates

GitHub Issue Prioritization Agent
YouTube Community Moderation Agent
Customer Ticket Triage Agent
Incident Management Agent
--- # Add internal scripts to the Package Library in Postman With the Postman Package Library, you can maintain scripts and tests in a central location and share them with your team. Add commonly used scripts and tests to packages in your team's package library, and reuse them in your internal workspaces. The package library supports HTTP, gRPC, and GraphQL requests. ## About the package library Use the package library to store commonly used scripts and tests as packages in your Postman team. Your teammates can access and import packages from the package library, enabling you to share scripts and tests directly in Postman. The package library supports JavaScript code. The number of packages your team can store in the package library depends on your [Postman plan](https://www.postman.com/pricing/). Learn more about [resource usage](/docs/billing/resource-usage/#packages) in Postman. Import packages into the **Scripts** tab in your team's HTTP, gRPC, or GraphQL requests. Since a script can be associated with a request, a folder, or a collection, Postman follows a consistent [run order](/docs/tests-and-scripts/write-scripts/intro-to-scripts/#run-order-of-scripts) for scripts. The contents of packages will run when you run any of the following: - Requests whose scripts import packages - The Collection Runner, for runs of HTTP collections, both [manual](/docs/collections/running-collections/intro-to-collection-runs/) and [scheduled](/docs/collections/running-collections/scheduling-collection-runs/) - [Monitors](/docs/monitoring-your-api/setting-up-monitor/) - [Postman Flows](/docs/postman-flows/build-flows/configure/requests-and-variables/), and - Postman CLI [collection runs](/docs/postman-cli/postman-cli-run-collection/) and [monitors](/docs/postman-cli/postman-cli-run-monitor/). The contents of packages won't run from [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). You must be on a [Professional or Enterprise team](https://www.postman.com/pricing/) to use the Postman CLI to run a collection that imports packages from your team's package library. ## Add a package You can create a package from scratch in the package library. You can also add existing code to a new package or an existing package. You can only open the package library from internal workspaces. To use a package, [write code in a package](#write-code-in-a-package), then [import the package](#import-a-package) into your scripts. You are the owner of the packages you create. Packages remain in your team's package library when a package's owner leaves the team or is removed from the team. ### Add a new package To add a new package, do the following: 1. Open an HTTP collection, folder, or request. You can also open a gRPC or GraphQL request. 2. Select the **Scripts** tab. 3. Select **New Package**. 4. Enter the following: - **Name** - The name of the package. This is used in the import statement that adds the package to your scripts. - **Summary** - The summary of the package so your teammates understand what it does. - **Code** - Enter code in the package. Learn how to [write code in a package](#write-code-in-a-package). 5. Select **Create**. ![Create a new package](https://assets.postman.com/postman-docs/v11/package-library-create-package-v11.png) Postman adds a new package file to your team's package library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click **Docs** in the sidebar, and open a specification. 2. Click **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click **New**. 5. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 6. Click **Create**. ![Create a component file](https://assets.postman.com/postman-docs/v11/package-library-create-new-v11.png) Postman adds a new component file to your team's package library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specifications. 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. If you've integrated Postman with Slack or Teams workspaces, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. ![](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. 1. Click **Docs** in the sidebar, and open a specification. 2. Click **Components** in the lower right of a specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization teams Manage Organization Teams with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. To manage your Organization Teams, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization workspaces Manage Organization Workspaces with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. 4. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 5. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 6. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Sync workspaces between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization workspaces Manage Organization Workspaces with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. 4. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 5. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 6. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Sync workspaces between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization workspaces Manage Organization Workspaces with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. 4. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 5. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 6. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Sync workspaces between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization workspaces Manage Organization Workspaces with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. 4. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 5. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 6. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Sync workspaces between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Manage Organization workspaces Manage Organization Workspaces with internal workspaces. You can find a team within your organization or join by other means enabled by your organization. To determine the structure of your teams and memberships: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team's contents. 4. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 5. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 6. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Sync workspaces between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You --- # Send parameters and body data with API requests in Postman The Postman API client enables you to send data along with your HTTP requests. You can add query and path parameters to a request and specify their values. You can also add body data to a request in various formats, including form data, URL-encoded, raw, and binary. ## Send request parameters You can specify path and query parameters for a request using the URL box or the **Params** tab. * Query parameters are appended to the end of the request URL, following `?` and listed in key-value pairs, separated by `&` as follows: `?id=1&type=new` * Path parameters form part of the request URL, and are referenced using placeholders preceded by `:` as in the following example: `/customer/:id` To specify a query parameter, add it directly to the URL or select the **Params** tab and enter the name and value. When you enter your query parameters in either the URL or the **Params** tab, these values will update everywhere they're used in Postman. Parameters aren't automatically URL-encoded. Right-click selected text, and choose **EncodeURIComponent** to manually encode a parameter value. To specify a path parameter, enter the parameter name into the URL box, after a colon, for example `:id`. When you enter a path parameter, Postman will populate it in the **Params** tab, where you can also edit it. You can add descriptions to your parameters and they'll appear for anyone sharing the request (for example in your workspace) or viewing your API documentation. When you're done entering parameters, select **Send** to send the request. Learn more about [creating and sending requests in Postman](/docs/sending-requests/create-requests/request-basics/). ![Path parameter](https://assets.postman.com/postman-docs/v11/path-param-v11-27-b.jpg) You can use the **Bulk Edit** option if you prefer to enter your parameters in plain text instead of using the request builder. ## Send body data with requests You need to send body data with requests whenever you want to add or update structured data. For example, if you're sending a request to add a new customer to a database, you might include the customer details in JSON. Typically you use body data with `PUT`, `POST`, and `PATCH` requests. The **Body** tab enables you to specify the data you need to send with a request. You can send different types of body data to suit your API. If you're sending body data, make sure you have the correct [headers](/docs/sending-requests/create-requests/headers/) selected to indicate the content type your API may need to process the received data. * For `form-data` and `urlencoded` body types, Postman will automatically attach the correct `Content-Type` header. * If you use raw mode for your body data, Postman will set a header based on the type you select (such as text or json). * If you manually select a `Content-Type` header, that value will take precedence over what Postman sets. * Postman doesn't set any header type for the binary body type. By default, Postman will select **None** for body data. Leave it selected if you don't need to send a body with your request. Otherwise, choose the data type you need for your request body: [form data](#form-data), [URL-encoded](#url-encoded), [raw](#raw-data), [binary](#binary-data), or [GraphQL](#graphql). When you're done entering body data, select **Send** to send the request. Learn more about [creating and sending requests in Postman](/docs/sending-requests/create-requests/request-basics/). ### Form data Website forms often send data to APIs as `multipart/form-data`. You can replicate this in Postman using the `form-data` option in the **Body** tab of your request. Form data enables you to send key-value pairs and specify the content type. You can also attach a file using form data and send it with your request. Select **File** in the dropdown list next to a key name, then select the file you want to send. You can select a file from your local system, and Postman saves the file path in the request. The saved file path is relative to your local [working directory](/docs/getting-started/installation/settings/#working-directory). You can also upload a file with test data to your Postman team. This is useful if you want to share the request with others on your team or use the request in a monitor or scheduled collection run. Learn more about [uploading files for shared requests and cloud runs](/docs/sending-requests/create-requests/test-data/). ![Add form data](https://assets.postman.com/postman-docs/v11/request-form-data-v11-2.jpg) ### URL-encoded URL-encoded data uses the same encoding as URL parameters. If your API requires url-encoded data, select `x-www-form-urlencoded` in the **Body** tab of your request. Enter your key-value pairs to send with the request and Postman will encode them before sending. There is sometimes confusion between form data and URL-encoded. If you are unsure which one you need, check with your API provider. ### Raw data You can use raw body data to send anything you can enter as text. In the **Body** tab of your request, select the **raw** option and use the dropdown list to indicate the format of your data (`Text`, `JavaScript`, `JSON`, `HTML`, or `XML`). Postman will enable syntax-highlighting and appending the relevant headers to your request. ![Body JSON](https://assets.postman.com/postman-docs/v11/body-raw-data-v11-2.jpg) You can [set a content type header manually](/docs/sending-requests/create-requests/headers/) if you need to override the one Postman sends automatically. You can use [variables](/docs/sending-requests/variables/variables/) in your body data, and Postman populates their values when sending your request. You can use [vault secrets](/docs/sending-requests/postman-vault/postman-vault-secrets/) in your body data with the `{{vault:secret-name}}` syntax. In your body data, you can also use [variables without a scope](/docs/sending-requests/variables/variables/#setting-values-for-variables-without-a-scope) and [vault secrets without adding them to your Postman Vault](/docs/sending-requests/postman-vault/manage-vault-secrets/#set-a-value-for-a-vault-secret-that-doesnt-exist). These enable you to try out a value to make sure it works as expected. If you'd like, you can [add the variable to a scope](/docs/sending-requests/variables/variables/#adding-variables-to-a-scope) or [add the vault secret to your Postman Vault](/docs/sending-requests/postman-vault/manage-vault-secrets/#add-a-vault-secret-reference-to-your-postman-vault). For JSON raw body data, you can add comments, and they will be stripped out when the request is sent. Single-line comments delimited with `//` and multi-line comments delimited with `/* */` will be removed in the request. To beautify your XML or JSON, select the text in the editor and then select **⌘+Option+B** or **Ctrl+Alt+B**. ### Binary data You can use binary data to send information you can't enter manually in the Postman editor with your request body, such as image, audio, and video files. (You can also send text files.) In the **Body** tab of your request, select the **binary** option, then select the file you want to send with the request. You can select a file from your local system, and Postman saves the file path in the request. The saved file path is relative to your local [working directory](/docs/getting-started/installation/settings/#working-directory). You can also upload a file with test data to your Postman team. This is useful if you want to share the request with others on your team or use the request in a monitor or scheduled collection run. Learn more about [uploading files for shared requests and cloud runs](/docs/sending-requests/create-requests/test-data/). ![Add binary data](https://assets.postman.com/postman-docs/v11/request-binary-data-v11-2.jpg) ### GraphQL You can send GraphQL queries with your Postman requests by selecting the __GraphQL__ option in the __Body__ tab of your request. Enter your code in the __Query__ pane and any variables in the __GraphQL Variables__ pane. Check out [GraphQL in Postman](/docs/sending-requests/graphql/graphql-overview/) for more information on GraphQL, including how to enable __Autocomplete__ powered by Postman API schemas. ## Use vault secrets You can reference vault secrets stored in your local vault or a cloud vault by adding a vault secret reference in an HTTP request or a collection. This also enables you to define a default value for a [vault secret you tried out in a request](#try-vault-secrets-in-a-request). To reference a vault secret in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To view the local secret protection interface, do the following: 1. In the Postman header, select **Team > Team Settings**. 2. Click **Secret Scanner** in the left sidebar. 3. In **Secret Scanner**, select the **Local Protection** tab. 4. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To view the local secret protection interface, do the following: 1. In the Postman header, select **Team > Team Settings**. 2. Click **Secret Scanner** in the left sidebar. 3. In **Secret Scanner**, select the **Reports** tab. 4. Click **Postman API Builder**. 5. In **Secret Scanner**, select the **Reports** tab. 6. Click **Postman API Builder**. 7. Click a component file in the left sidebar. 8. Choose a published version of the component file using the version dropdown list. 9. In the left sidebar, click **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 10. Add the URL to a reference (`$ref`) in your specification. To view the local secret protection interface, do the following: 1. In the Postman header, select **Team > Team Settings**. 2. Click **Secret Scanner** in the left sidebar. 3. In **Secret Scanner**, select the **Reports** tab. 4. Click **Postman API Builder**. 5. In **Secret Scanner**, select the **Reports** tab. 6. Click **Postman API Builder**. 7. Click a component file in the left sidebar that you'd like to version and publish. 8. Click **Version & Publish** in the upper right corner. 9. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 10. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AysncAPI 2.0 specification. To view the local secret protection interface, do the following: 1. In the Postman header, select **Team > Team Settings**. 2. Click **Secret Scanner** in the left sidebar. 3. In **Secret Scanner**, select the **Reports** tab. 4. Click **Postman API Builder**. 5. In **Secret Scanner**, select the **Reports** tab. 6. Click **Postman API Builder**. 7. Click a component file in the left sidebar that you'd like to version and publish. 8. Click **Version & Publish** in the upper right corner. 9. Enter a version number. The version number must be unique to the component file. The version number can only contain alphanumeric characters, periods, underscores, dashes, plus signs, and no spaces. 10. Click **Create Version & Publish**. Once the component is published, your teammates can [reference the file's components](#reference-a-component-in-a-specification) in their specifications. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in --- # Configure and run performance tests in Postman Use the _Collection Runner_ to test the performance of your API with the same requests and collections you use for [functional API tests](/docs/collections/running-collections/intro-to-collection-runs/). When you run a performance test, Postman uses the requests in the selected collection to simulate the activity of your API users. In the Collection Runner, you can set the duration of the test and the number of _virtual users_. Each virtual user runs the requests in the specified order in a repeating loop. All of the virtual users operate in parallel to simulate real-world load on your API. You can choose whether the number of virtual users is fixed for the duration of the test or ramps up and down during the test. ## Configure a performance test > **Use the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to configure and run performance tests.** You can't use the Postman web app for performance testing. During a performance test, all requests are sent from the host computer where you are running the Postman desktop app. Before you configure a performance test, [create a collection](/docs/collections/use-collections/create-collections/) or [add a folder](/docs/collections/use-collections/manage-collections/#add-folders-to-a-collection) with the requests you want to use to simulate user activity. Each virtual user runs the selected requests in the specified order and repeats the sequence throughout the test. Multiple virtual users all operate in parallel to simulate real-world usage of your API. To configure a performance test in the Postman desktop app, do the following: 1. Click **Collections** in the sidebar and select the collection or folder you want to use for performance testing. 2. On the **Overview** tab, click \[![Image 1: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon)\] **Run**. 3. ![Image 2: Click Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) You can also click \[![Image 3: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon)\] **Runner** from the Postman footer and drag a collection from **Collections** or **History** in the sidebar. 4. Select the **Performance** tab. 5. (Optional) Change the order in which the requests are run by dragging a request to a new location. To skip a request, clear the checkbox next to its name. 6. Select a **Load profile**. * **Fixed** - The maximum number of virtual users is used throughout the test. * **Ramp up** - Enter an **Initial load** and drag the handles to adjust the length of the ramp up period. During the ramp up period, the number of virtual users increases from the initial load to the maximum. * **Spike** - Enter a **Base load** and drag the handles to adjust the duration of the spike. During the spike, the number of virtual users increases from the base load to the maximum, then decreases back to the base load. * **Peak** - Enter a **Base load** and drag the handles to adjust the duration of the peak. During the peak, the number of virtual users increases from the base load to the maximum, holds steady, then decreases back to the base load. 7. Enter the number of **Virtual users**. While the test is running, each virtual user runs the selected requests in the specified order in a repeating loop. A higher number of virtual users puts increased load on your API. 8. Enter the **Test duration** in minutes. 9. (Optional) Select a **Data file** with custom values to use for each virtual user. The file must be in CSV or JSON format. Learn more about [using a data file to simulate virtual users](/docs/collections/performance-testing/performance-test-data-files/). 10. (Optional) Click **Pass test if** to set a metric, condition, and value that determines whether the test passes or fails. * **Metric** - Select the performance metric: * **Avg. Response Time** - The response time of all requests averaged together, in milliseconds. * **p90** - The 90th percentile of response times, in milliseconds. * **p95** - The 95th percentile of response times, in milliseconds. * **p99** - The 99th percentile of response times, in milliseconds. * **Error %** - The percentage of requests that result in an error. Errors indicate runtime issues such as timeouts, connection or TLS failures, or uncaught exceptions in user scripts. * **Requests per second** - The number of requests sent each second during the performance test. * **Condition** - Select the condition that must be met for the test to pass. * **Value** - Enter a number that must be met for the test to pass. Later performance runs with the same collection will have the metric, condition, and value autofilled from the previous run. 11. When you're ready to begin the performance test, click **Run**. * You can view real-time performance metrics while the test is running. Learn more about [viewing performance test metrics](/docs/collections/performance-testing/performance-test-metrics/). * After the test completes, you can view details for any [errors](/docs/collections/performance-testing/performance-test-errors/) or [test assertion failures](/docs/collections/performance-testing/performance-test-failures/) that occurred during the performance test. ![Image 4: Configuring a performance test](https://assets.postman.com/postman-docs/v11/performance-test-configure-v11-40.jpg) Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of performance runs you can use each month. A message will display in the Collection Runner when you're approaching your usage limit. Learn more about [resource usage](/docs/billing/resource-usage/#performance-test-limit) in Postman. ## Virtual users and system resources The number of virtual users a performance test can simulate depends on available system resources and the collection used for the test. Using pre-request or post-response scripts will reduce the number of virtual users that can be simulated. Attempting to simulate a higher number of virtual users than your system resources can support may cause inaccurate metrics and reduced throughput (requests per second). Try running a small test with 10 to 20 virtual users and observing system resource usage. During a performance test, an in-app notification may warn you that your system resources are approaching their threshold. If your system resources exceed their threshold, you'll receive an in-app notification with this warning and the performance test stops running. If you have a problem with the performance testing feature, contact the [Postman support team](https://support.postman.com/hc/en-us). Make sure to attach your [Postman logs](https://support.postman.com/hc/en-us/articles/360025298633-How-to-get-logs-from-the-Postman-Desktop-app) in your support request. ## Rename a performance run You can change the name of a performance run while it's in progress, or you can rename a past run. Rename a performance run to help you identify runs later, for example, when [comparing performance runs](/docs/collections/performance-testing/performance-test-metrics/#compare-two-performance-runs). To rename a performance run, [start a new run](#configure-a-performance-test) or [open a past run](#view-past-performance-runs). Click the name of the performance run and enter a new name. ![Image 5: Rename a performance run](https://assets.postman.com/postman-docs/v10/performance-test-rename-v10-24.jpg) ## View past performance runs You can view a list of past performance runs for a collection. Open the collection, select the **Runs** tab, and then select the **Performance** tab. You can view metrics for each run, including the number of virtual users (VUs), duration, total number of requests, requests per second, average response time, and error rate. Click the run to [view a graph and full details](/docs/collections/performance-testing/performance-test-metrics/) for the performance run. --- # pm-visualizer Script Postman visualizations ============================= You can use the `pm.visualizer` object and the `pm.getData` method to visually represent your API's request responses with the [Postman Visualizer](/docs/sending-requests/response-data/visualizer/). ## pm.visualizer Use the `pm.visualizer.set` method to specify a template you want to use to display response data in the Postman Visualizer: ```js pm.visualizer.set(layout:String, data:Object, options:Object):Function ``` This method uses the following properties: * `layout` - (Required) A [Handlebars](https://handlebarsjs.com/) HTML template string. * `data` - A JSON object that binds to the template. You can access it inside the template string. * `options` - An [Options object](https://handlebarsjs.com/api-reference/compilation.html) for `Handlebars.compile()`. Example: ```js var template = `

{{res.info}}

`; pm.visualizer.set(template, { res: pm.response.json() }); ``` ## pm.getData Use the `pm.getData` method to get response data inside a Postman Visualizer template string. ```js pm.getData(callback):Function ``` The `callback` function accepts the following parameters: * `error` - Any error detail. * `data` - Data passed to the template by the `pm.visualizer.set` method. Example: ```js pm.getData(function (error, data) { var value = data.res.info; }); ``` --- # postman-cli-overview Explore Postman's command-line companion ---------------------------------------- The Postman CLI is a secure command-line companion for Postman. It's signed and supported by Postman, like the Postman app. The Postman CLI supports the following features: * [Sign in and sign out of Postman](/docs/postman-cli/postman-cli-options/#sign-in-and-out) from the command line. * [Validate, synchronize, and push local collections and environments](/docs/postman-cli/postman-cli-options/#sync-local-elements-with-workspaces) to Postman workspaces in the cloud. * [Run a collection](/docs/postman-cli/postman-cli-run-collection/) with its collection ID or path, and send the run results to the Postman cloud by default. * [Run a monitor](/docs/postman-cli/postman-cli-run-monitor/) in the Postman cloud with its monitor ID. * [Start a runner](/docs/postman-cli/postman-cli-run-monitor/) in your internal network to monitor APIs with private endpoints. * Generate a local collection run report with [built-in reporters](/docs/postman-cli/postman-cli-reporters/). * [Check API definitions](/docs/postman-cli/postman-cli-options/#governance-and-security) against configured API governance and API security rules. The Postman CLI requires a valid Postman API key. For more information, see [Generate and use Postman API keys](/docs/developer/postman-api/authentication/). ## Comparing the Postman CLI and Newman The table below shows a high-level comparison of the Postman CLI and [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). | Postman CLI | Newman | |---|---| | Created by Postman | Created by Postman | | Maintained and supported by Postman | Open source; supported by community contributions | | Supports collection runs | Supports collection runs | | Automatically sends collection run results to Postman by default | Supports ingesting run results to Postman using a reporter | | Package is signed by Postman | Package isn't signed by Postman | | Distributed as a downloadable package | Distributed on npm | | Downloadable programmatically | Downloadable programmatically | | Not available as a library | Available as a library | | Supports sign in and sign out | Doesn't support sign in and sign out | | Checks API specifications against your configured API governance and API security rules | Doesn't check API specifications against your configured API governance and API security rules | ## Decide which command-line companion to use You can use the Postman CLI or Newman to run and test collections from the command line. One may be a better fit, depending on your use case or preferences. For example, assume you already manage your own security for open-source software, and you want to run collections from a script. Also assume you want visibility into any software you build into your CI/CD pipeline. Newman would be a good fit for this use case because Newman's repository is public and Newman isn't signed or secured by Postman. Here's another example. Assume you don't already support or secure any open-source software, and you want the software you use to be signed and secured by its developer. The Postman CLI would be a good fit for this use case because the Postman CLI is signed and secured by Postman. Learn how to [install the Postman CLI](/docs/postman-cli/postman-cli-installation/). ## About the Postman CLI and Postman API usage Some Postman CLI commands use the [Postman API](/docs/developer/postman-api/intro-api/) to fetch data from and send data to Postman's servers. These commands count toward your monthly [Postman API usage](/docs/billing/resource-usage/#postman-api-usage). The number of Postman API calls you can make each month depends on your [Postman plan](https://www.postman.com/pricing/). The following Postman CLI commands make calls to the Postman API and count toward your Postman API usage: * `postman login` - Uses one call to authenticate a user with a Postman API key. * `postman collection run` - Uses one call to fetch a collection by ID, one call to fetch an environment (if any), and one call to send data back to Postman. * `postman monitor run` - Uses one call to fetch a monitor by ID, one call to start a monitor run, and multiple calls that poll Postman for the run's completion. * `postman spec lint` - Uses one call to fetch the API governance rules and one call to send a report back to Postman. * `postman api lint` - Uses one call to fetch the API governance and security rules and one call to send a report back to Postman. Learn more about [Postman CLI command options](/docs/postman-cli/postman-cli-options/). ## Postman Vault integrations Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ### Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ### Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ### Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 1. Click **Next**. The new installed app appears on the Installed apps page with the status as **Connected**. To create a new collection, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. * This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. ### Determine the structure of your teams and memberships A team within an Organization represents physical members of a functional team, for example, developer or test team, and also contains the workspaces that the group of users wants to keep secure and access controlled. By creating teams and memberships first, you can establish strategic collaborations and empower your teams to migrate their own work to their teams. For example, even if your QA team hasn't moved all their workspaces to a QA-designated team yet, other teams can still invite the QA team members to collaborate with their team. Once you define the teams, you can start the process of improving collaboration and security by populating the teams with your workspaces. To determine the team membership, do the following: 1. The [Organization Manager (or Super Admin)](/docs/administration/organization/roles/) creates a Team and assigns a Team Manager to it. 2. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** — Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** — Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 3. Populate the team with the members who are responsible for the team’s contents. * If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. * If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. * **Notes**: * Only a Team Member can create workspaces in the team. * Sharing an element with a new user triggers the process of adding that user to the Team's user list. * Any time a Team Member or Collaborator is removed from the Team's user list, they lose access to everything in the Team (until they're added back). * The team membership can continue to grow and change, and the users with edit access to the Team’s workspaces will adapt accordingly. * Analyze the remaining, unassigned workspaces. You can define your own process for handling unassigned workspaces, but Postman recommends using the upcoming archival process or creating an archive Team to hold such workspaces if they are no longer needed or active. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. ![Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. * **Notes**: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection.md). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior --- # Run a collection using the Postman CLI You can use the [Postman CLI](/docs/postman-cli/postman-cli-overview/) to manually run collections to test the functionality of your API. You can also use the Postman CLI to automate collection runs in CI/CD pipelines. > Postman supports running HTTP collections. You can't run multi-protocol collections. When the Postman CLI runs a collection, the collection and its tests run locally, and the results are sent to the Postman cloud using an API call. > The Postman CLI doesn't support OAuth 2.0 authentication. To learn how to use an OAuth 2.0 token with the Postman CLI, see [OAuth 2.0 overview](/docs/sending-requests/authorization/oauth-20/#oauth-20-overview). ## Run a collection locally with the Postman CLI You can use the Postman CLI to run the requests in a [collection](/docs/collections/use-collections/create-collections/) or a [folder](/docs/collections/use-collections/manage-collections/#add-folders-to-a-collection). 1. [Download and install the Postman CLI](/docs/postman-cli/postman-cli-installation/). 2. Click **Collections** in the sidebar and select the collection or folder you want to run. 3. Click ![Image 1: Runner icon](https://assets.postman.com/postman-docs/icon-runner-v9.jpg#icon) **Run**. 4. ![Image 2: Select Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) 5. On the **Functional** tab, click **Automate runs via CLI**. 6. ![Image 3: Automate runs using the Postman CLI](https://assets.postman.com/postman-docs/v11/pcli-automate-cli-v11-19.jpg) If you're running a [collection linked to an API](/docs/design-apis/api-builder/develop-apis/adding-api-elements/) that's connected to a [Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/), replace the collection ID with the path to the collection file in your remote repository. 7. Under **Run on Postman CLI**, click **Add API Key**. Do one of the following: * Click **Generate Key** to create a new API key. Enter a name for the API key and click **Generate**. Click ![Image 4: Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy** to copy the key and save it somewhere safe. * Click **Use Existing Key** and enter a valid API key. 8. Click **Insert Key**. 9. Click ![Image 5: Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy** to copy the commands. 10. Paste and run the commands in your terminal. After running the commands, the Postman CLI outputs a run report and a link to the run results in Postman. In the run report, `test-scripts` refers to [post-response scripts](/docs/tests-and-scripts/write-scripts/test-scripts/). 11. Follow the link to check the results in Postman. ![Image 6: Postman CLI view collection run results](https://assets.postman.com/postman-docs/v11/postman-cli-view-run-data-v11-19.jpg) ## Run a collection in CI/CD When the collection runs to your satisfaction, you can copy the commands into your CI/CD script to integrate them into your workflows. When adding the commands to your CI/CD script, you may want to replace the API key with a variable. To run a collection in CI/CD, do the following: 1. Click **Collections** in the sidebar and select the collection or folder you want to run. 2. Click ![Image 7: Runner icon](https://assets.postman.com/postman-docs/icon-runner-v9.jpg#icon) **Run**. 3. ![Image 8: Select Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) 4. On the **Functional** tab, click **Automate runs via CLI**. 5. ![Image 9: Automate runs using the Postman CLI](https://assets.postman.com/postman-docs/v11/pcli-automate-cli-v11-19.jpg) If you're running a [collection linked to an API](/docs/design-apis/api-builder/develop-apis/adding-api-elements/) that's connected to a [Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/), replace the collection ID with the path to the collection file in your remote repository. 6. Under **Run on CI/CD**, click **Configure command**. 7. Click a **Collection** to run during pipeline builds. You can also select an **Environment** to use. 8. If needed, click ![Image 10: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add Another Collection** to select more collections to run. 9. Click the **CI/CD Provider** and **Operating system** for your CI/CD pipeline. 10. To copy the Postman CLI configuration, click ![Image 11: Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy** or **Copy Postman CLI Command**. 11. Add the Postman CLI configuration to your CI/CD script. This process depends on your CI tool. ## Run a collection in a specific order By default, when you generate the command to run a collection from the Collection Runner, a single Collection ID for the collection is specified. This runs the folders and requests in that collection in the sequence they're listed in the collection. If you need to change the request order, select a request in the Collection Runner and drag it to its new location in the order. You can also remove an individual request from the run by clearing the checkbox next to its name. When you change the folder and request sequence, the generated command also changes. In addition to the Collection ID, the generated command specifies a number of folder and request UIDs with the `-i` option. This runs each of the folders or requests in that specified order. ## Run a collection that uses test data files The Postman CLI can't run requests that use files in your local [working directory](/docs/getting-started/installation/settings/#working-directory) to send [body data](/docs/sending-requests/create-requests/parameters/). If your collection has requests that use files, [upload your test data files](/docs/sending-requests/create-requests/test-data/) to make them available to the Postman CLI. ## Run a collection that uses packages > Using the Postman CLI to run packages from your team's Postman Package Library is available with [Postman Professional and Enterprise plans](https://www.postman.com/pricing/). You can use the Postman CLI to run collections with scripts that import packages from your team's [package library](/docs/tests-and-scripts/write-scripts/packages/package-library/). Learn how to [add packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#add-a-package) to the package library, and [import packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#import-a-package) into your scripts. You can also use the Postman CLI to run collections that [import external packages](/docs/tests-and-scripts/write-scripts/packages/external-package-registries/) from npm or JSR package registries. > Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values > Local Secret Protection requires Postman version 11.71.3 or later. ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 12: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 13: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 14: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 15: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 16: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 17: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 18: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 19: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. > The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then select **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. > This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** --- # About Postman elements As a comprehensive API development platform, Postman helps you organize and document your work and complete different phases of the [API development lifecycle](https://www.postman.com/api-platform/api-lifecycle/). Learn more about integral parts of Postman like collections and environments. ## Collections A [_collection_](/docs/collections/collections-overview/) is a set of requests sent to API endpoints. A collection can also include saved responses from those requests, along with each endpoint's authorization type, parameters, headers, request bodies, tests, and settings. Collections enable you to organize your requests using folders and subfolders according to the requirements of your API project. For example, you can group your API actions into tasks. You can design your APIs using an HTTP collection with types. Define types, such as data type and possible values, that describe your API's request parameters, headers, and body data. Adding details to your collection can help others better understand your API and send valid API requests. You can also generate an OpenAPI 3.0 specification in Spec Hub from a collection and keep them in sync. To learn more, see [Design your APIs with Postman Collections](/docs/design-apis/collections/overview/). To try a quick example, see [Create your first collection](/docs/getting-started/first-steps/creating-the-first-collection/). ## Requests A _request_ is a way for one application to access the capabilities of another application over the internet by way of an API server. A client application (like a mobile app) sends a request to the server, and after the request is processed the server returns a response to the client. In Postman, you can make [requests](/docs/sending-requests/requests/) using HTTP protocol, MQTT protocol, GraphQL, gRPC, WebSocket, and Socket.IO. An _API endpoint_ is a URL that acts as the point of contact between an API client and an API server. API clients send requests to API endpoints to access the API's functionality and data. The request _method_ indicates the action you want the API to perform. The most common methods include: * GET retrieves data from an API. * POST sends new data to an API. * PATCH and PUT update existing data. * DELETE removes existing data. To try a quick example, see [Send your first API request](/docs/getting-started/first-steps/sending-the-first-request/). To learn more about requests, see [Send a request with the Postman API client](/docs/sending-requests/create-requests/request-basics/). ## Documentation _API documentation_ is a set of human-readable instructions for using and integrating with an API. Documentation includes information about an API's endpoints, methods, resources, authentication protocols, parameters, and headers. It also includes examples of common requests and responses. Postman automatically generates [documentation](/docs/publishing-your-api/api-documentation-overview/) for your collection. To access it, click the collection's **Overview** tab and click **View complete documentation**. You can improve your documentation by adding descriptions for your collection, folders, and requests. ## Environments An _environment_ is a set of [variables](/docs/sending-requests/variables/environment-variables/) that you can reuse in your requests and share with your team. You can reference them in request authentication, query and path parameters, request bodies, and scripts. Variables help you work efficiently, collaborate with teammates, and set up dynamic workflows. You can [use environment variables](/docs/sending-requests/variables/environment-variables/) to call the same request against different servers, such as local, stage, or production. Each environment has its own set of variable values. When you change environments, selecting the correct environment points your request at the correct host (server) with the proper authentication and its defined variables. Global variables are useful in cases where you need to use the same variable across several collections. Environments can also help you to collaborate on Postman data if you're working as part of a team. You can use environments to share variables and manage the visibility of sensitive data such as API keys, passwords, or tokens. Learn more about [working with environments as a team in Postman](/docs/sending-requests/variables/team-environments/). To learn more about how variables are used in Postman in general, see [Reuse data with variables and environments in Postman](/docs/sending-requests/variables/variables-intro/). ## Flows _Postman Flows_ is a visual, low-code tool designed to streamline API workflows, making it easier for you to create, manage, and collaborate on API projects. Postman Flows provides an infinite canvas where you can functionally represent your APIs as blocks that can be connected to simulate data flow. The blocks are a set of visual abstractions. To form and visualize an application, you drag blocks, build an application, and run your workflow. To learn more, see [Build API applications visually using Postman Flows](/docs/postman-flows/overview/). ## Spec Hub [Spec Hub](/docs/design-apis/specifications/overview/) enables you to [design your API](https://www.postman.com/api-first/) in an OpenAPI 3.0 or AsyncAPI 2.0 specification. You can generate a collection from your API specification. If the collection was generated from an OpenAPI 3.0 specification, you can keep the collection and specification in sync with your latest changes. ## API Builder Postman supports [API-first development](https://www.postman.com/api-first/) with the API Builder. You can use the [API Builder](/docs/design-apis/api-builder/overview/) to design your API in Postman and then take your API through the complete development lifecycle by developing, testing, deploying, and observing it. Your [API definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/) can then act as the single source of truth for your API project. When you create a new API in the Postman API Builder, you can start your API development by [connecting to a repository](/docs/design-apis/api-builder/versioning-an-api/overview/) or clicking **continue without a repository**. ## Mock servers A _mock server_ enables you to simulate your API without having to configure a real API server. You can use any HTTP collection to set up a mock server. When you send a request to the mock server, Postman returns a real-world response using data from your collection. To learn more about how to get started with mock servers in Postman, see [Simulate your API in Postman with a mock server](/docs/design-apis/mock-apis/overview/). ## Monitors _Postman Monitors_ enable you to [continuously check the health and performance of your APIs](https://www.postman.com/api-platform/api-observability/). You can create monitors that run requests in selected collections. Requests can run API test scripts, chain together multiple requests, and more. You can also schedule how often Postman runs monitored collections. You'll be alerted to any test failures once the monitor is running, so you can identify and address issues before your API's consumers are affected. To learn more about monitors, see [Monitor health and performance of your APIs in Postman](/docs/monitoring-your-api/intro-monitors/). ## Troubleshoot vault secrets Vault secrets can be empty or unresolved in your HTTP requests. An *empty vault* secret is a vault secret that doesn't have a value but is referenced in your request. An empty vault secret may or may not exist in your Postman Vault. An *unresolved vault secret* is a vault secret that exists in your Postman Vault but the value can't be accessed from your request. A vault secret in a cloud vault may be empty if the cloud vault's name was updated, but references to the vault secret use the previous cloud vault name. To fix this, update references to the vault secret with the correct cloud vault name. To learn more about troubleshooting empty and unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. To publish a new version of your component, select **Draft** in the version dropdown list. [Edit the component file](#edit-a-component-file) and then publish a new version. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To reference a component in a specification, do the following: 1. Click **Docs** in the Postman header, then select **Specs** in the left sidebar. 2. Click **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. To learn more, see [Edit component file](#edit-a-component-file). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Organization settings _Postman Organizations_ streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives each team better control over its membership. Organization Teams can directly invite other Teams to collaborate or consume the Teams' content, improving collaboration scaling. By default, a given Organization Team's content is shared with the entire Organization. However, content sharing can be limited to just the team or specific team members, helping to reduce clutter and oversharing in your Organization. To migrate your teams to Organizations, contact your Customer Success Manager. Your teams will be migrated to a single team that you can then reorganize and redistribute. Also see [Migrate your Enterprise team to an Organization](/docs/administration/organization/migrate/) for further steps. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Migrate your Enterprise team to an Organization When you migrate your Enterprise team to an Organization, your Organization initially contains a single team that includes all the original team’s shared workspaces. These workspaces continue to be shared with the same users, and all members of the initial team become members of the migrated team. This single team continues to function as it did before the migration, but Postman recommends that you break up your original, monolithic team into multiple Organization Teams, to take full advantage of Organization benefits. To set up a productive Enterprise team in Postman, walk through the following general tasks. 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team’s membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. If your team is smaller and doesn’t use technologies to sync users from their Identity Provider through SCIM, your Team Manager can add users, or you can simply leave the Teams open for any user to join. 8. If your team has defined user groups through SCIM, add the groups as members of their teams to automate the process of maintaining Team memberships. 9. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 10. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 11. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click **![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon)** **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. * This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To reference a component in a specification, do the following: 1. Click **Docs** in the Postman header, then select **Specs** in the left sidebar. 2. Click **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Search for a component file and select it in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. To learn more, see [Edit component file](#edit-a-component-file). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: * [The Secret Scanner dashboard](/docs/reports/secret-scanner-reports/) --- # Integrate Postman Vault with external vaults **[Postman Vault integrations are available with Postman Enterprise plans with the Advanced Security Administration add-on.](https://www.postman.com/pricing/)** You can integrate your [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/) with external vaults, such as Azure Key Vault. This enables you to link vault secrets with secrets stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of secrets stored in external vaults when you send HTTP requests. You can create Postman Vault integrations from the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/). Before you integrate your Postman Vault with external vaults, make sure you understand how to [add vault secrets to your Postman Vault](/docs/sending-requests/postman-vault/manage-vault-secrets/#add-sensitive-data-as-vault-secrets), and [reference vault secrets in Postman](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets). You can't create an integration that links [vault secrets created using Guided Auth](/docs/sending-requests/postman-vault/manage-vault-secrets-using-guided-auth/) with external vaults. ## About Postman Vault integrations Postman Vault integrations enable you to link vault secrets with secrets that are stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of external vault secrets using end-to-end encryption when you send HTTP requests. Postman supports Postman Vault integrations with [1Password](https://1password.com/), [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/), [Azure Key Vault](https://azure.microsoft.com/en-us/products/key-vault/), and [HashiCorp Vault](https://www.hashicorp.com/en/products/vault). Postman retrieves authentication credentials that enable you to authenticate with your external vault, such as a user access token. The type of authentication credentials that Postman retrieves can vary depending on the external vault you're authenticating with. Postman must authenticate with your external vault to retrieve secrets from it when you send HTTP requests. Authentication credentials and retrieved secrets aren't stored in your local instance of Postman or the Postman cloud. Postman removes authentication credentials from your working memory and local storage when you close Postman or your authentication credentials expire. You'll need to [reauthenticate with external vaults](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/#reauthenticate-with-an-external-vault) each time you open Postman or when your authentication credentials expire in Postman. You'll need to create the integration again if you sign out and back in to Postman. You can only integrate your Postman Vault with one organization in an external vault provider at a time. If you want to integrate with a different organization in your external vault provider, you must [disconnect the integration](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/#disconnect-an-integration), then create a new integration that authenticates with a different organization. See the following details about creating and managing integrations with external vault providers: * **1Password, AWS Secrets Manager, and Azure Key Vault** - You create and manage the integration with your Postman Vault. This means you and your team members can integrate with different organizations in 1Password, AWS Secrets Manager, and Azure Key Vault. * **HashiCorp Vault** - Only a Postman [Team Admin or Super Admin](/docs/administration/roles-and-permissions/#team-roles) can create and manage the integration with your Postman Vault. This means that you and your team members must integrate with the same organization in HashiCorp. External partners assigned the [Partner role](/docs/administration/roles-and-permissions/#partner-team-and-partner-workspace-roles) can't access Postman Vault integrations. ## Supported integrations Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) ## Manage integrations You can [manage and update your Postman Vault integrations](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/). Set the expiration duration for cached secrets, change linked secrets, reauthenticate with your external vaults, and disconnect your integrations. ## Troubleshoot vault secrets To learn how to troubleshoot vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). --- # Store secrets in your Postman Vault _Postman Vault_ enables you to store sensitive data as vault secrets in your local instance of Postman. This enables you to securely reuse sensitive data in your HTTP collections and requests. Only you can access and use values associated with your vault secrets, and they aren't synced to the Postman cloud. ![Add secrets to Postman Vault](https://assets.postman.com/postman-docs/v11/add-postman-vault-secrets-v11-1.jpg) ## Access your Postman Vault You can open your Postman Vault from the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) or the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app). To open your Postman Vault, open a workspace then select **Vault** from the Postman footer. You can also select **Control+Shift+V** or **Ctrl+Shift+V** to open your Postman Vault. If this is your first time opening your Postman Vault, Postman generates your vault key when you open your Postman Vault. [Save your vault key](/docs/sending-requests/postman-vault/postman-vault-key/) to open your Postman Vault when you sign in to Postman again later. You'll need to enter your vault key each time you sign in to Postman to open your Postman Vault. You can enter your vault key in the following ways, depending on how you saved your vault key: * If you stored your vault key in your system's password manager, Postman gets your vault key and open your Postman Vault. If you're using the Postman web app, make sure you're using the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent) so Postman can get your vault key. * If you chose not to store your vault key in your system's password manager, open your Postman Vault, manually enter your vault key, and select **Open Vault**. Postman recommends you [use the latest version](/docs/getting-started/basics/about-postman-agent/#update-the-postman-desktop-agent) of the Postman Desktop Agent to receive recent changes and improvements. ## Vault secrets are deleted from your Postman Vault after signing out of Postman. Your vault secrets can't be recovered with your vault key. When you sign in to Postman and open your Postman Vault, you can add vault secrets back to your Postman Vault. Once you've opened your Postman Vault, you can [add, edit, and use your vault secrets](#add-edit-and-use-vault-secrets). ## About vault secrets *Vault secrets* are sensitive data, such as API keys and passwords, that you store in your Postman Vault and reuse in your local instance of Postman. Only you can access and reuse values associated with your vault secrets, and they aren't synced to the Postman cloud. Also your vault secrets are encrypted using Advanced Encryption Standard (AES) with a 256-bit key length. Collaborators can see references to your vault secrets, such as `{{vault:postman-api-key}}`, in shared workspaces, enabling secure collaboration between teammates. API consumers can also see references to your vault secrets in public workspaces, enabling you to show an example of a secret. Collaborators and API consumers can add each vault secret to their Postman Vault with their own value. If you're on an [Enterprise plan with the Advanced Security Administration add-on](https://www.postman.com/pricing/), you can link vault secrets with sensitive data stored in an external vault. Learn more about [Postman Vault integrations](#postman-vault-integrations). Learn about Postman Vault [features that require the Postman desktop app](#feature-availability). ### Other options for storing and reusing values You can use [variables](/docs/sending-requests/variables/variables/) to store and reuse the same value, such as URLs, in multiple places. Variables can be shared with teammates. While Postman Vault is highly recommended for storing sensitive data, you can use the following options to store sensitive data in variables: * You can add sensitive data as a variable's [local value](/docs/sending-requests/variables/variables/#defining-variables) and make sure to never share the value with your teammates. You can learn more about [sharing a variable value](/docs/sending-requests/variables/variables/#share-variable-values) with your teammates. * You can set the variable as [sensitive data](/docs/sending-requests/variables/variables/#set-a-value-as-sensitive-data) in global and environment variables, masking the value. This helps prevent you from unintentionally sharing the value during screen sharing or live streaming. Teammates who can access your workspace have permission to unmask the value. ## Manage your vault key Save your vault key to open your Postman Vault when you sign in to Postman. Save or download your vault key to a secure location. You can store your vault key in your system's password manager, enabling Postman to automatically get your vault key when you sign in to Postman. Otherwise, you must manually enter your vault key each time you sign in to Postman. Note that your vault key isn't synced to the Postman cloud. Learn how to [save and manage your vault key](/docs/sending-requests/postman-vault/postman-vault-key/). If you stored your vault key in your system's password manager and you're using the Postman web app, use the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent) so Postman can get your vault key. Vault secrets are deleted from your Postman Vault after signing out of Postman. Your vault secrets can't be recovered with your vault key. When you sign in to Postman and open your Postman Vault, you can add vault secrets back to your Postman Vault. ## Add, edit, and use vault secrets [Add vault secrets](/docs/sending-requests/postman-vault/manage-vault-secrets/#add-sensitive-data-as-vault-secrets) to your Postman Vault to reuse them in your local instance of Postman. Then you can [reference vault secrets](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) in your HTTP collections and requests, variables, and the Collection Runner. You can also [use Guided Auth to add vault secrets](/docs/sending-requests/postman-vault/manage-vault-secrets-using-guided-auth/#add-authorization-as-vault-secrets-using-guided-auth) that have authentication credentials for public APIs. [Reference vault secrets added using Guided Auth](/docs/sending-requests/postman-vault/manage-vault-secrets-using-guided-auth/#use-vault-secrets-added-using-guided-auth) in your HTTP requests, and reuse your authentication credentials in new HTTP requests to the same public APIs. The following shows some high-level differences between adding vault secrets without and with Guided Auth: | Vault secrets | Vault secrets using Guided Auth | | --- | --- | | Stores any type of secret, such as API keys and passwords | Stores authentication credentials for public APIs in Postman | | You can add vault secrets directly in Postman Vault | You must use Guided Auth to add vault secrets | | Add vault secrets at any time | API publishers must set up Guided Auth for their public APIs | | Postman doesn't suggest specific vault secrets | Postman suggests saved vault secrets for future requests to public APIs | | Link vault secrets with external vaults | Can't link vault secrets with external vaults | ## Postman Vault integrations Postman Vault integrations are available with Postman Enterprise plans with the Advanced Security Administration add-on. Postman Vault integrations enable you to link vault secrets with secrets stored in an external vault. You can then reference vault secrets in your local instance of Postman, and retrieve the value of secrets stored in external vaults when you send HTTP requests. You can also [manage and update your Postman Vault integrations](/docs/sending-requests/postman-vault/manage-postman-vault-integrations/). Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) ## Feature availability The following features require the Postman desktop app: * **Open Postman Vault from public workspaces** - You must use the Postman desktop app to open your Postman Vault from a [public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/), and reference vault secrets in a public workspace. If you're using the Postman web app, you must add new vault secrets to your Postman Vault if you're opening it from a public workspace. * **Create and manage Postman Vault integrations** ([Enterprise teams only](https://www.postman.com/pricing/)) - You must use the Postman desktop app to [create and manage Postman Vault integrations](/docs/sending-requests/postman-vault/postman-vault-integrations/). If you're using the Postman web app, Postman Vault integrations won't be available. ## Troubleshoot vault secrets To learn how to troubleshoot empty and unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). --- # pre-request-scripts Write pre-request scripts to add dynamic behavior in Postman =========================================================== You can use pre-request scripts in Postman to run JavaScript before a request runs. By including code in the **Pre-request** tab for a request, collection, or folder, you can carry out pre-processing such as setting variable values, parameters, headers, and body data. You can also use pre-request scripts to debug code, for example, by logging output to the Postman Console. ## Pre-request scripting example The following is an example of using pre-request scripts: * You have a series of requests in a collection and are running them in a sequence, such as when using the [Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/). * The second request is dependent on a value returned from the first request. * The value needs to be processed before you pass it to the second request. * The first request sets the data value from a response field to a variable in its post-response script. * The second request retrieves the value and processes it in its pre-request script, then sets the processed value to a variable. This variable is then referenced in the second request, for example, in its parameters. ## Scripting before your request runs To include code you want to run before Postman sends a request, do the following: 1. Click **Collections** in the sidebar. 2. Open the request, then select the **Scripts** tab. 3. Click the **Pre-request** tab. 4. Enter the JavaScript you need to process before the request runs, then click **Save**. 5. Click **Send** to send the request. The code runs before Postman sends the request to the API. ![Pre-Request Code](https://assets.postman.com/postman-docs/v11/pre-request-script-v11-12.jpg) To make your code more readable, click **Beautify** in the lower right of the code editor. ## Add documentation to pre-request scripts Postman supports JSDoc for documenting JavaScript functions in your pre-request scripts. Documentation added to your functions using JSDoc display in a popup window when you call your functions. You can use the official [JSDoc documentation](https://jsdoc.app/) to learn how to add documentation to your pre-request scripts. The following example has documentation for the `logger` function using JSDoc. The documentation explains what the function does, and defines what the `data` parameter is used for and that it accepts a string data type. ```js /** * This function prints a string to the Postman Console. * @param {string} data - The text to print to the Postman Console. */ function logger (data) { console.log(`Logging information to the console, ${data}`) } ``` ## Reuse pre-request scripts You can add pre-request scripts to entire collections and folders within collections. In both cases, your pre-request script will run before every request in the collection or direct child request in the folder. This enables you to define commonly used pre-processing or debugging steps you need to run for multiple requests. * You can define a pre-request script when you first create a collection or folder, or at any time after that. You can also [store pre-request scripts in the Postman Package Library](/docs/tests-and-scripts/write-scripts/packages/package-library/). This lets you maintain commonly used scripts in a single location, share them with your team, and reuse them in your internal workspaces. To add pre-request scripts to a collection or folder, do the following: 1. Click **Collections** in the sidebar. 2. Select a collection or folder. 3. Click the **Scripts** tab. 4. Click the **Pre-request** tab. Enter code that will run before every request in the collection or direct child request in the folder. 5. Click **Save**. ## Next steps After learning the basics of writing pre-request scripts, you can extend your scripts: * To learn more about how to use the `pm` object, visit the [Postman JavaScript reference](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/). * For more information about storing and reusing commonly used scripts, learn about [the package library](/docs/tests-and-scripts/write-scripts/packages/package-library/) in Postman. --- **Note:** The Postman Power Pass is available with Postman Enterprise plans with the Advanced Security Administration add-on. [Postman Power Pass](https://www.postman.com/pricing/) is a free, premium access to the platform that enables collaboration across the entire API development lifecycle. **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives you greater control over your team's security posture and compliance requirements. **To migrate your Enterprise team to an Organization, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? **To migrate your teams to Organizations, contact your Customer Success Manager.** **Learn more about:** * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Postman Organizations** streamline API collaboration, reduce clutter in --- # public-api-network-overview Explore and Publish to the Postman API Network | Postman Docs =============== Explore and Publish to the Postman API Network ============================================= The *Postman API Network* enables API publishers to share their public workspaces, collections, APIs, and Flows with their API's consumers. Publishers can help their API's consumers to discover and consume their APIs directly in Postman. The Postman API Network enables API consumers to discover new and popular public workspaces and elements to use in their own workspaces. As an API consumer, you can get started by exploring and using public workspaces and elements on the Postman API Network. To learn more, see [Explore APIs on the Postman API Network](/docs/postman-api-network/explore/overview/). As an API publisher, you can get started by sharing your public workspaces to the Postman API Network. Learn about [best practices and tips for sharing public workspaces](#become-an-api-publisher-and-showcase-your-public-apis) to the Postman API Network. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public-apis/) by making your workspace public and sharing and promoting your APIs on the Postman API Network. * **Maintain your public APIs** - Once you've published your APIs to the Postman API Network, continue to [maintain them](/docs/postman-api-network/showcase/publish/maintain-public-apis/) and give your API consumers access to your API's latest features and documentation. ![The Postman API Network interface](https://assets.postman.com/postman-docs/v11/postman-api-network-v11-18.jpg) ## Benefits of the Postman API Network The Postman API Network benefits both API consumers and publishers in the following ways: * **Consumers** - The Postman API Network enables you to search for, discover, and identify public workspaces and elements you'd like to use in your organization. You can fork collections from a variety of publishers, and build on their APIs in your own workspace. The Postman API Network also gives you access to the latest API workflows directly from publishers. * **Publishers** - The Postman API Network enables you to share your workspaces and elements with your API's consumers, and collect feedback from them through metrics and comments. Sharing APIs on the Public API Network increases your API's discovery in organic and Postman search results. Customize your public team profile to promote your workspaces and social media all in one place. You can improve your API's onboarding experience with detailed documentation, organized workspace resources, and more. ## Become an API Publisher and Showcase Your Public APIs To succeed as an API publisher, focus on API consumer success. This starts with getting your API consumers to their first 200 OK response in the fewest steps as possible. To learn more, see the following: * **Prepare your public APIs** - Before you publish your API to the Postman API Network, spend time [preparing them](/docs/postman-api-network/showcase/prepare/overview/) by creating and [curating](/docs/postman-api-network/showcase/prepare/curate/overview/) your publisher team, workspace, and collections. * **Publish your public APIs** - Once you've prepared your public APIs for your API consumers, you're ready to [publish them](/docs/postman-api-network/showcase/publish/public- --- # Publish your public APIs to the Postman API Network Once you've [prepared your public workspace](/docs/postman-api-network/showcase/prepare/public-workspace/), [prepared your public collections](/docs/postman-api-network/showcase/prepare/public-collections/), [curated them](/docs/postman-api-network/showcase/prepare/curate/overview/), and [prepared your team workspace for team collaboration](/docs/postman-api-network/showcase/prepare/team-workspace/), you're ready to publish your public APIs. ## Important: Protect your sensitive data. If Postman detects any API keys, tokens, or similar, it replaces them with placeholders. To learn more, see [Postman Secret Scanner](/docs/administration/managing-your-team/secret-scanner/overview/). ## Evaluate the developer experience Before you make your workspace public, and begin to share and promote your public APIs, walk yourself through the steps you outlined in your [overview collection](/docs/postman-api-network/showcase/prepare/public-collections/#create-your-public-overview-collection). Invite others on your team to do the same. If you haven't already, [create a team workspace](/docs/postman-api-network/showcase/prepare/team-workspace/#create-your-internal-workspace) and [fork your public collections](/docs/postman-api-network/showcase/prepare/team-workspace/#fork-your-public-collections-from-your-public-workspace). Even if you decide to use one workspace to manage your public APIs, the exercise will walk you through your API consumer's steps. Gather feedback and iterate to [curate your public collections](/docs/postman-api-network/showcase/prepare/curate/overview/). Continue to iterate until you're satisfied you can get your new users to their first 200 OK response in the fewest steps as possible. ## Pin your collections to your workspace overview To pin your collection to your workspace overview, do the following: 1. From the Postman sidebar, click your workspace's name. 2. Click ![Image 1: Pin icon](https://assets.postman.com/postman-docs/aether-icons/action-pin-stroke.svg#icon) **Pin Collections** or ![Image 2: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon), and pin your collection. 3. Choose an environment for your collection. When an API consumer selects your pinned collection, Postman opens it and sets the environment for them. To learn more, see [Pin collections to workspaces](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#pin-collections-to-workspaces). ## Make your workspace public To make your workspace public, do the following: 1. Open your public workspace. 2. If your workspace's ![Image 3: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. Then, click **Settings**. 3. Under **Workspace type**, click **Change**. 4. Click ![Image 4: Published icon](https://assets.postman.com/postman-docs/aether-icons/state-published-stroke.svg#icon) **Public**. 5. If you're prompted to submit a request, optionally add a note and click **Submit Request**. 6. Otherwise, click **Save Changes**. Your public workspace and its collections are available on the Postman API Network. To learn more, see [Convert an existing workspace to a public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/#convert-an-existing-workspace-to-a-public-workspace). --- # Prepare your public collections for the Postman API Network Create a public API reference collection and overview collection for your API consumers. When you [publish your public APIs](/docs/postman-api-network/showcase/publish/public-apis/), you can invite your API consumers to [fork your public collections](/docs/collaborating-in-postman/using-version-control/forking-elements/), and get them to their first 200 OK response fast. An API reference collection contains your public API's endpoints and their HTTP methods. An overview collection compliments your API reference collection and serves as a starting point for your API consumers. ## Important: Protect your sensitive data. If Postman detects any API keys, tokens, or similar, it replaces them with placeholders. To learn more, see [Postman Secret Scanner](/docs/administration/managing-your-team/secret-scanner/overview/). ## Create your public API reference collection An API reference collection is a comprehensive list of your public API's endpoints and their HTTP methods, which define your API's operations. It's often based on an API specification, such an OpenAPI definition. Postman recommends you [import your OpenAPI definition to create your API reference collection](#import-your-openapi-definition-to-create-your-api-reference-collection). If you don't have an OpenAPI definition, you can [manually create your API reference collection](#manually-create-your-api-reference-collection). ### Import your OpenAPI definition to create your API reference collection To import your OpenAPI definition to create your API reference collection, do the following: 1. From the Postman sidebar, click **Import**. 2. Use one of the options to import your OpenAPI definition. 3. Click **Postman Collection**. 4. (Optional) Click ![Image 1: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **View Import Settings** and edit your settings. 5. Click **Import**. Postman turns your OpenAPI definition into a Postman Collection. You can continue to edit your API reference collection as your public APIs evolve and you [curate your public collections](/docs/postman-api-network/showcase/prepare/curate/overview/). To learn more, see [Import an API into Postman](/docs/design-apis/api-builder/importing-an-api/). ### Manually create your API reference collection If you don't have an OpenAPI definition, you can manually create your API reference collection. To manually create your API reference collection, do the following: 1. From the Postman sidebar, click ![Image 2: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 2. Select ![Image 3: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create new collection** \[![Image 4: New collection icon](https://assets.postman.com/postman-docs/aether-icons/action-newCollection-stroke.svg#icon)\] **Blank collection**. 3. [Name your collection](/docs/postman-api-network/showcase/prepare/curate/public-collections-overview/#name-your-collection) and [write a description for it](/docs/postman-api-network/showcase/prepare/curate/public-collections-overview/#write-a-description-for-your-collection). 4. [Add requests to your collection](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#add-requests-to-your-collection) and [examples to your requests](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#add-examples-to-your-requests). 5. [Document your requests](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#document-your-requests). 6. [Organize your collection with folders](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#organize-your-collection-with-folders). You can continue to edit your API reference collection as your public APIs evolve and you [curate your public collections](/docs/postman-api-network/showcase/prepare/curate/overview/). To learn more, see [Create a new collection](/docs/collections/use-collections/create-collections/). ## Create your public overview collection An overview collection compliments your API reference collection. It's a starting point for your API consumers. Use an overview collection to summarize your public APIs and get your API consumers to their first 200 OK response in the fewest steps as possible. You can also showcase your public APIs with common use cases and popular workflows. To create your public overview collection, do the following: 1. From the Postman sidebar, click ![Image 5: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 2. Select ![Image 6: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Create new collection** \[![Image 7: New collection icon](https://assets.postman.com/postman-docs/aether-icons/action-newCollection-stroke.svg#icon)\] **Blank collection**. 3. [Name your collection](/docs/postman-api-network/showcase/prepare/curate/public-collections-overview/#name-your-collection) and [write a description for it](/docs/postman-api-network/showcase/prepare/curate/public-collections-overview/#write-a-description-for-your-collection). 4. [Add requests to your collection](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#add-requests-to-your-collection) and [examples to your requests](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#add-examples-to-your-requests). 5. [Document your requests](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#document-your-requests). 6. [Organize your collection with folders](/docs/postman-api-network/showcase/prepare/curate/public-collections-requests/#organize-your-collection-with-folders). You can continue to edit your overview collection as your public APIs evolve and you [curate your public collections](/docs/postman-api-network/showcase/prepare/curate/overview/). To learn more, see [Create a new collection](/docs/collections/use-collections/create-collections/). ## Create a Stripe API key To create a Stripe API key to use with Postman Flows, do the following: 1. Log in to [Stripe](https://dashboard.stripe.com/login). 2. In the Developer Dashboard, select [API keys](https://dashboard.stripe.com/test/apikeys). 3. Select **Create secret key** to create a new key. 4. Copy the key, and then save it as a variable in your Postman environment named `Stripe_Api_Key`. 5. Save the data center identifier as a variable in your Postman environment named `Stripe_DC`. ## Create a Slack API key To create a Slack API key to use with Postman Flows, do the following: 1. Log in to [Slack](https://www.slack.com/) 2. Navigate to **Settings** > **Account** > **Extras** > **API Keys**. 3. Select **Create A Key**. Enter a name for the key, and then select **Generate Key**. 4. Copy the key you generated, excluding the suffix that contains the data center identifier. For example, if the key value is `YOUR_API_KEY-us00`, don't include `-us00`. 5. Save the key value as a variable in your Postman environment named `Slack_API_Key`. ## Create a Notion API key To create a Notion API key to use with Postman Flows, do the following: 1. Log in to [Notion](https://www.notion.so/) 2. Navigate to **Settings** > **Account** > **Accounts** > **My Account**. 3. Select **Create a new account**. 4. Enter a name for the account, and then select **Create**. 5. Select **Notion** as the account type. 6. Select **Create account**. 7. Enter a password for the account, and then select **Save**. 8. Select **Notion** as the account type. 9. Select **Create account**. 10. Enter a password for the account, and then select **Save**. 11. Select **Notion** as the account type. 12. Select **Create account**. 13. Enter a password for the account, and then select **Save**. 14. Select **Notion** as the account type. 15. Select **Create account**. 16. Enter a password for the account, and then select **Save**. 17. Select **Notion** as the account type. 18. Select **Create account**. 19. Enter a password for the account, and then select **Save**. 20. Select **Notion** as the account type. 21. Select **Create account**. 22. Enter a password for the account, and then select **Save**. 23. Select **Notion** as the account type. 24. Select **Create account**. 25. Enter a password for the account, and then select **Save**. 26. Select **Notion** as the account type. 27. Select **Create account**. 28. Enter a password for the account, and then select **Save**. 29. Select **Notion** as the account type. 30. Select **Create account**. 31. Enter a password for the account, and then select **Save**. 32. Select **Notion** as the account type. 33. Select **Create account**. 34. Enter a password for the account, and then select **Save**. 35. Select **Notion** as the account type. 36. Select **Create account**. 37. Enter a password for the account, and then select **Save**. 38. Select **Notion** as the account type. 39. Select **Create account**. 40. Enter a password for the account, and then select **Save**. 41. Select **Notion** as the account type. 42. Select **Create account**. 43. Enter a password for the account, and then select **Save**. 44. Select **Notion** as the account type. 45. Select **Create account**. 46. Enter a password for the account, and then select **Save**. 47. Select **Notion** as the account type. 48. Select **Create account**. 49. Enter a password for the account, and then select **Save**. 50. Select **Notion** as the account type. 51. Select **Create account**. 52. Enter a password for the account, and then select **Save**. 53. Select **Notion** as the account type. 54. Select **Create account**. 55. Enter a password for the account, and then select **Save**. 56. Select **Notion** as the account type. 57. Select **Create account**. 58. Enter a password for the account, and then select **Save**. 59. Select **Notion** as the account type. 60. Select **Create account**. 61. Enter a password for the account, and then select **Save**. 62. Select **Notion** as the account type. 63. Select **Create account**. 64. Enter a password for the account, and then select **Save**. 65. Select **Notion** as the account type. 66. Select **Create account**. 67. Enter a password for the account, and then select **Save**. 68. Select **Notion** as the account type. 69. Select **Create account**. 70. Enter a password for the account, and then select **Save**. 71. Select **Notion** as the account type. 72. Select **Create account**. 73. Enter a password for the account, and then select **Save**. 74. Select **Notion** as the account type. 75. Select **Create account**. 76. Enter a password for the account, and then select **Save**. 77. Select **Notion** as the account type. 78. Select **Create account**. 79. Enter a password for the account, and then select **Save**. 80. Select **Notion** as the account type. 81. Select **Create account**. 82. Enter a password for the account, and then select **Save**. 83. Select **Notion** as the account type. 84. Select **Create account**. 85. Enter a password for the account, and then select **Save**. 86. Select **Notion** as the account type. 87. Select **Create account**. 88. Enter a password for the account, and then select **Save**. 89. Select **Notion** as the account type. 90. Select **Create account**. 91. Enter a password for the account, and then select **Save**. 92. Select **Notion** as the account type. 93. Select **Create account**. 94. Enter a password for the account, and then select **Save**. 95. Select **Notion** as the account type. 96. Select **Create account**. 97. Enter a password for the account, and then select **Save**. 98. Select **Notion** as the account type. 99. Select **Create account**. 100. Enter a password for the account, and then select **Save**. 101. Select **Notion** as the account type. 102. Select **Create account**. 103. Enter a password for the account, and then select **Save**. 104. Select **Notion** as the account type. 105. Select **Create account**. 106. Enter a password for the account, and then select **Save**. 107. Select **Notion** as the account type. 108. Select **Create account**. 109. Enter a password for the account, and then select **Save**. 110. Select **Notion** as the account type. 111. Select **Create account**. 112. Enter a password for the account, and then select **Save**. 113. Select **Notion** as the account type. 114. Select **Create account**. 115. Enter a password for the account, and then select **Save**. 116. Select **Notion** as the account type. 117. Select **Create account**. 118. Enter a password for the account, and then select **Save**. 119. Select **Notion** as the account type. 120. Select **Create account**. 121. Enter a password for the account, and then select **Save**. 122. Select **Notion** as the account type. 123. Select **Create account**. 124. Enter a password for the account, and then select **Save**. 125. Select **Notion** as the account type. 126. Select **Create account**. 127. Enter a password for the account, and then select **Save**. 128. Select **Notion** as the account type. 129. Select **Create account**. 130. Enter a password for the account, and then select **Save**. 131. Select **Notion** as the account type. 132. Select **Create account**. 133. Enter a password for the account, and then select **Save**. 134. Select **Notion** as the account type. 135. Select **Create account**. 136. Enter a password for the account, and then select **Save**. 137. Select **Notion** as the account type. 138. Select **Create account**. 139. Enter a password for the account, and then select **Save**. 140. Select **Notion** as the account type. 141. Select **Create account**. 142. Enter a password for the account, and then select **Save**. 143. Select **Notion** as the account type. 144. Select **Create account**. 145. Enter a password for the account, and then select **Save**. 146. Select **Notion** as the account type. 147. Select **Create account**. 148. Enter a password for the account, and then select **Save**. 149. Select **Notion** as the account type. 150. Select **Create account**. 151. Enter a password for the account, and then select **Save**. 152. Select **Notion** as the account type. 153. Select **Create account**. 154. Enter a password for the account, and then select **Save**. 155. Select **Notion** as the account type. 156. Select **Create account**. 157. Enter a password for the account, and then select **Save**. 158. Select **Notion** as the account type. 159. Select **Create account**. 160. Enter a password for the account, and then select **Save**. 161. Select **Notion** as the account type. 162. Select **Create account**. 163. Enter a password for the account, and then select **Save**. 164. Select **Notion** as the account type. 165. Select **Create account**. 166. Enter a password for the account, and then select **Save**. 167. Select **Notion** as the account type. 168. Select **Create account**. 169. Enter a password for the account, and then select **Save**. 170. Select **Notion** as the account type. 171. Select **Create account**. 172. Enter a password for the account, and then select **Save**. 173. Select **Notion** as the account type. 174. Select **Create account**. 175. Enter a password for the account, and then select **Save**. 176. Select **Notion** as the account type. 177. Select **Create account**. 178. Enter a password for the account, and then select **Save**. 179. Select **Notion** as the account type. 180. Select **Create account**. 181. Enter a password for the account, and then select **Save**. 182. Select **Notion** as the account type. 183. Select **Create account**. 184. Enter a password for the account, and then select **Save**. 185. Select **Notion** as the account type. 186. Select **Create account**. 187. Enter a password for the account, and then select **Save**. 188. Select **Notion** as the account type. 189. Select **Create account**. 190. Enter a password for the account, and then select **Save**. 191. Select **Notion** as the account type. 192. Select **Create account**. 193. Enter a password for the account, and then select **Save**. 194. Select **Notion** as the account type. 195. Select **Create account**. 196. Enter a password for the account, and then select **Save**. 197. Select **Notion** as the account type. 198. Select **Create account**. 199. Enter a password for the account, and then select **Save**. 200. Select **Notion** as the account type. 201. Select **Create account**. 202. Enter a password for the account, and then select **Save**. 203. Select **Notion** as the account type. 204. Select **Create account**. 205. Enter a password for the account, and then select **Save**. 206. Select **Notion** as the account type. 207. Select **Create account**. 208. Enter a password for the account, and then select **Save**. 209. Select **Notion** as the account type. 210. Select **Create account**. 211. Enter a password for the account, and then select **Save**. 212. Select **Notion** as the account type. 213. Select **Create account**. 214. Enter a password for the account, and then select **Save**. 215. Select **Notion** as the account type. 216. Select **Create account**. 217. Enter a password for the account, and then select **Save**. 218. Select **Notion** as the account type. 219. Select **Create account**. 220. Enter a password for the account, and then select **Save**. 221. Select **Notion** as the account type. 222. Select **Create account**. 223. Enter a password for the account, and then select **Save**. 224. Select **Notion** as the account type. 225. Select **Create account**. 226. Enter a password for the account, and then select **Save**. 227. Select **Notion** as the account type. 228. Select **Create account**. 229. Enter a password for the account, and then select **Save**. 230. Select **Notion** as the account type. 231. Select **Create account**. 232. Enter a password for the account, and then select **Save**. 233. Select **Notion** as the account type. 234. Select **Create account**. 235. Enter a password for the account, and then select **Save**. 236. Select **Notion** as the account type. 237. Select **Create account**. 238. Enter a password for the account, and then select **Save**. 239. Select **Notion** as the account type. 240. Select **Create account**. 241. Enter a password for the account, and then select **Save**. 242. Select **Notion** as the account type. 243. Select **Create account**. 244. Enter a password for the account, and then select **Save**. 245. Select **Notion** as the account type. 246. Select **Create account**. 247. Enter a password for the account, and then select **Save**. 248. Select **Notion** as the account type. 249. Select **Create account**. 250. Enter a password for the account, and then select **Save**. 251. Select **Notion** as the account type. 252. Select **Create account**. 253. Enter a password for the account, and then select **Save**. 254. Select **Notion** as the account type. 255. Select **Create account**. 256. Enter a password for the account, and then select **Save**. 257. Select **Notion** as the account type. 258. Select **Create account**. 259. Enter a password for the account, and then select **Save**. 260. Select **Notion** as the account type. 261. Select **Create account**. 262. Enter a password for the account, and then select **Save**. 263. Select **Notion** as the account type. 264. Select **Create account**. 265. Enter a password for the account, and then select **Save**. 266. Select **Notion** as the account type. 267. Select **Create account**. 268. Enter a password for the account, and then select **Save**. 269. Select **Notion** as the account type. 270. Select **Create account**. 271. Enter a password for the account, and then select **Save**. 272. Select **Notion** as the account type. 273. Select **Create account**. 274. Enter a password for the account, and then select **Save**. 275. Select **Notion** as the account type. 276. Select **Create account**. 277. Enter a password for the account, and then select **Save**. 278. Select **Notion** as the account type. 279. Select **Create account**. 280. Enter a password for the account, and then select **Save**. 281. Select **Notion** as the account type. 282. Select **Create account**. 283. Enter a password for the account, and then select **Save**. 284. Select **Notion** as the account type. 285. Select **Create account**. 286. Enter a password for the account, and then select **Save**. 287. Select **Notion** as the account type. 288. Select **Create account**. 289. Enter a password for the account, and then select **Save**. 290. Select **Notion** as the account type. 291. Select **Create account**. 292. Enter a password for the account, and then select **Save**. 293. Select **Notion** as the account type. 294. Select **Create account**. 295. Enter a password for the account, and then select **Save**. 296. Select **Notion** as the account type. 297. Select **Create account**. 298. Enter a password for the account, and then select **Save**. 299. Select **Notion** as the account type. 300. Select **Create account**. 301. Enter a password for the account, and then select **Save**. 302. Select **Notion** as the account type. 303. Select **Create account**. 304. Enter a password for the account, and then select **Save**. 305. Select **Notion** as the account type. 306. Select **Create account**. 307. Enter a password for the account, and then select **Save**. 308. Select **Notion** as the account type. 309. Select **Create account**. 310. Enter a password for the account, and then select **Save**. 311. Select **Notion** as the account type. 312. Select **Create account**. 313. Enter a password for the account, and then select **Save**. 314. Select **Notion** as the account type. 315. Select **Create account**. 316. Enter a password for the account, and then select **Save**. 317. Select **Notion** as the account type. 318. Select **Create account**. 319. Enter a password for the account, and then select **Save**. 320. Select **Notion** as the account type. 321. Select **Create account**. 322. Enter a password for the account, and then select **Save**. 323. Select **Notion** as the account type. 324. Select **Create account**. 325. Enter a password for the account, and then select **Save**. 326. Select **Notion** as the account type. 327. Select **Create account**. 328. Enter a password for the account, and then select **Save**. 329. Select **Notion** as the account type. 330. Select **Create account**. 331. Enter a password for the account, and then select **Save**. 332. Select **Notion** as the account type. 333. Select **Create account**. 334. Enter a password for the account, and then select **Save**. 335. Select **Notion** as the account type. 336. Select **Create account**. 337. Enter a password for the account, and then select **Save**. 338. Select **Notion** as the account type. 339. Select **Create account**. 340. Enter a password for the account, and then select **Save**. 341. Select **Notion** as the account type. 342. Select **Create account**. 343. Enter a password for the account, and then select **Save**. 344. Select **Notion** as the account type. 345. Select **Create account**. 346. Enter a password for the account, and then select **Save**. 347. Select **Notion** as the account type. 348. Select **Create account**. 349. Enter a password for the account, and then select **Save**. 350. Select **Notion** as the account type. 351. Select **Create account**. 352. Enter a password for the account, and then select **Save**. 353. Select **Notion** as the account type. 354. Select **Create account**. 355. Enter a password for the account, and then select **Save**. 356. Select **Notion** as the account type. 357. Select **Create account**. 358. Enter a password for the account, and then select **Save**. 359. Select **Notion** as the account type. 360. Select **Create account**. 361. Enter a password for the account, and then select **Save**. 362. Select **Notion** as the account type. 363. Select **Create account**. 364. Enter a password for the account, and then select **Save**. 365. Select **Notion** as the account type. 366. Select **Create account**. 367. Enter a password for the account, and then select **Save**. 368. Select **Notion** as the account type. 369. Select **Create account**. 370. Enter a password for the account, and then select **Save**. 371. Select **Notion** as the account type. 372. Select **Create account**. 373. Enter a password for the account, and then select **Save**. 374. Select **Notion** as the account type. 375. Select **Create account**. 376. Enter a password for the account, and then select **Save**. 377. Select **Notion** as the account type. 378. Select **Create account**. 378. Enter a password for the account, and then select **Save**. 379. Select **Notion** as the account type. 380. Select **Create account**. 381. Enter a password for the account, and then select **Save**. 382. Select **Notion** as the account type. 383. Select **Create account**. 384. Enter a password for the account, and then select **Save**. 385. Select **Notion** as the account type. 386. Select **Create account**. 387. Enter a password for the account, and then select **Save**. 388. Select **Notion** as the account type. 389. Select **Create account**. 390. Enter a password for the account, and then select **Save**. 391. Select **Notion** as the account type. 392. Select **Create account**. 393. Enter a password for the account, and then select **Save**. 394. Select **Notion** as the account type. 395. Select **Create account**. 396. Enter a password for the account, and then select **Save**. 397. Select **Notion** as the account type. 398. Select **Create account**. 395. Enter a password for the account, and then select **Save**. 396. Select **Notion** as the account type. 397. Select **Create account**. 398. Enter a password for the account, and then select **Save**. 399. Select **Notion** as the account type. 400. Select **Create account**. 401. Enter a password for the account, and then select **Save**. 402. Select **Notion** as the account type. 403. Select **Create account**. 404. Enter a password for the account, and then select **Save**. 405. Select **Notion** as the account type. 406. Select **Create account**. 407. Enter a password for the account, and then select **Save**. 408. Select **Notion** as the account type. 409. Select **Create account**. 410. Enter a password for the account, and then select **Save**. 411. Select **Notion** as the account type. 412. Select **Create account**. 413. Enter a password for the account, and then select **Save**. 414. Select **Notion** as the account type. 415. Select **Create account**. 416. Enter a password for the account, and then select **Save**. 417. Select **Notion** as the account type. 418. Select **Create account**. 419. Enter a password for the account, and then select **Save**. 420. Select **Notion** as the account type. 421. Select **Create account**. 422. Enter a password for the account, and then select **Save**. 423. Select **Notion** as the account type. 424. Select **Create account**. 425. Enter a password for the account, and then select **Save**. 426. Select **Notion** as the account type. 427. Select **Create account**. 428. Enter a password for the account, and then select **Save**. 429. Select **Notion** as the account type. 430. Select **Create account**. 431. Enter a password for the account, and then select **Save**. 432. Select **Notion** as the account type. 433. Select **Create account**. 434. Enter a password for the account, and then select **Save**. 435. Select **Notion** as the account type. 436. Select **Create account**. 437. Enter a password for the account, and then select **Save**. 438. Select **Notion** as the account type. 435. Select **Create account**. 436. Enter a password for the account, and then select **Save**. 437. Select **Notion** as the account type. 438. Select **Create account**. 439. Enter a password for the account, and then select **Save**. 440. Select **Notion** as the account type. 441. Select **Create account**. 442. Enter a password for the account, and then select **Save**. 443. Select **Notion** as the account type. 444. Select **Create account**. 445. Enter a password for the account, and then select **Save**. 446. Select **Notion** as the account type. 447. Select **Create account**. 448. Enter a password for the account, and then select **Save**. 449. Select **Notion** as the account type. 450. Select **Create account**. 451. Enter a password for the account, and then select **Save**. 452. Select **Notion** as the account type. 453. Select **Create account**. 454. Enter a password for the account, and then select **Save**. 455. Select **Notion** as the account type. 456. Select **Create account**. 457. Enter a password for the account, and then select **Save**. 458. Select **Notion** as the account type. 459. Select **Create account**. 460. Enter a password for the account, and then select **Save**. 461. Select **Notion** as the account type. 462. Select **Create account**. 463. Enter a password for the account, and then select **Save**. --- # Prepare your public workspace for the Postman API Network Your public workspace is a landing page for your public APIs. It's where API consumers find your public APIs, learn about them, and can [fork your public collections to their own workspace](/docs/collaborating-in-postman/using-version-control/forking-elements/), where they can start using them. Before you [make your workspace public](/docs/postman-api-network/showcase/publish/public-apis/#make-your-workspace-public), you'll prepare it, [prepare your public collections](/docs/postman-api-network/showcase/prepare/public-collections/), [curate them](/docs/postman-api-network/showcase/prepare/curate/overview/), and [prepare your team workspace for team collaboration](/docs/postman-api-network/showcase/prepare/team-workspace/). ## Create your public workspace Depending on your team's workflow, you can create a private or team workspace (you'll make it public later). If you want to limit access to invited team members, create a private workspace. If you want to invite everyone from your team, create a team workspace. You'll make your workspace public when you're ready to [publish your public APIs to the Postman API Network](/docs/postman-api-network/showcase/publish/public-apis/). To create your public workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 1: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 2: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for your team members. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 3: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add tags. You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Postman Vault integrations Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: - HTTP collections - Environments variable values - Global variable values Local Secret Protection requires Postman version 11.71.3 or later. ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 4: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 5: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: - To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. - To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** > **Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: - The total number of detected secrets automatically moved to the Postman Vault. - The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. - Any endpoint errors reported during a performance test. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Connect Zoom to your Flows action You can connect [Zoom](https://www.zoom.com/) to a flow with the Zoom **Connector** block. Use this block to perform the following operations: - Create Meeting - Update Meeting - Get Meeting - Get Meeting By ID - Delete Meeting - Add Meeting Registrant - Get Meeting Registrant - Delete Meeting Registrant - Get Recording By Meeting ID - Search Recording - Create Folder - Move Folder - Get Folder By ID - Search Folders - Delete Folder - Download File To connect Zoom to a Flows action, do the following: 1. In [Postman Flows](/docs/postman-flows/overview/), [create an action](/docs/postman-flows/build-flows/structure/actions/). 2. Click ![Image 6: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. 3. Right-click the canvas and select **Zoom** from the list of blocks. 4. Click **Select an operation...** and select the operation you want the action to perform. 5. Click **Select an account...** and follow the prompts to connect your Zoom account. 6. Connect the **Request** block's output ports to the Zoom **Connector** block's input ports, based on the selected operation. 7. Connect the Zoom **Connector** block's **Result** port to the **Response** block's input ports, based on the selected operation. ![Image 7: Connect Zoom to your Flows action](https://assets.postman.com/postman-docs/v11/zoom-connector-v11.67.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 8: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 9: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. ![Image 10: Open Postman Component Library](https://assets.postman.com/postman-docs/v11/component-library-open-v11.png) 1. Click ![Image 11: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**. 2. Enter a name for the component file and select the OpenAPI specification format it'll be used in. You can't change the name or OpenAPI specification version of a component file later. 3. Click **Create**. ![Image 12: Create a component file](https://assets.postman.com/postman-docs/v11/component-library-create-v11.png) Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click ![Image 13: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Specs** in the sidebar, and open a specification. 2. Click ![Image 14: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click ![Image 15: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ![Image 16: Edit a component file](https://assets.postman.com/postman-docs/v11/component-library-edit-v11.png) In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your component file, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 17: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 18: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 19: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 20: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 21: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 22: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 23: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 24: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. - When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. - When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: - [Creating organization teams and workspaces](/docs/administration/organization/create/) - [Organization roles](/docs/administration/organization/roles/) - [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Team** in the left sidebar. 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): - **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. - **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team's contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 25: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 26: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: - [Organization roles](/docs --- # Collaborate with the Postman community using public workspaces Anyone in the Postman community can access a _public workspace_. A public workspace can enhance a new user's onboarding experience with your API, inspire your existing users with new use cases and resources, increase your API's discovery in Postman search results, and enable you to work publicly with partners. ## Make your team profile public Before other Postman users can work with your team in a public workspace, your team needs to have a public team profile. A public team profile encourages other users to collaborate with you in a public workspace, enables you to ask for contributions and gather feedback, and increases your API's discovery in search results. A public team profile also shows up on the [Postman API Network](https://www.postman.com/explore). [Team Admins](/docs/administration/roles-and-permissions/#team-roles) manage the team profile and other team settings. To make your [team profile](https://go.postman.co/settings/team/general) public, do the following: 1. In the upper-right corner of Postman next to your avatar, select **Team > Team settings**. 2. Select **Team profile**. 3. Select **Make team profile public** to set the profile to public. For information on how to create a public profile, see [Edit your publisher team](/docs/administration/managing-your-team/team-settings/#edit-your-publisher-team). ## Create a public workspace You can create a public workspace to share your workspace and its elements with the Postman community on the Postman API Network. Make sure to never expose secrets, such as API keys, in your public workspaces. The [Postman Secret Scanner](/docs/administration/managing-your-team/secret-scanner/overview/) scans your public workspaces to detect any exposed secrets. To create a public workspace, do the following: 1. Select **Workspaces** from the header, then select **Create Workspace**. ![Create new workspace](https://assets.postman.com/postman-docs/v10/create-workspace-from-dropdown-v10.23.0.jpg) 1. You can use [workspace templates](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace) to help you set up a new workspace. Select a workspace template to populate the workspace with helpful information and sample collections, or select **Blank workspace** to create an empty workspace. Then select **Next**. ![Create new workspace](https://assets.postman.com/postman-docs/v10/create-workspace-and-apply-template-full-screen-v10-2.jpg) 1. Select a unique name for your workspace. You can't have two public workspaces with the same name. 1. Select **Public** as your workspace type. 1. If you're not an admin, add a note for the workspace creation approval. 1. Select **Create**. ![Create public workspace](https://assets.postman.com/postman-docs/v11/create-public-workspace-v11.33.jpg) ## Convert an existing workspace to a public workspace As a [Workspace Admin](/docs/administration/roles-and-permissions/#workspace-roles), you can convert an existing workspace to a public workspace. If you're on a [Postman Professional or Enterprise plan](https://www.postman.com/pricing/), making a workspace public requires a [Community Manager's](/docs/administration/roles-and-permissions/#team-roles) approval. Once you make a workspace public, all elements within that workspace become publicly available on the Postman API Network. Before you convert your workspace to a public workspace, make sure you aren't exposing any secrets. You can give your API consumers a placeholder [variable](/docs/sending-requests/variables/variables/#setting-values-for-variables-without-a-scope) or [vault secret](/docs/sending-requests/postman-vault/manage-vault-secrets/#set-a-value-for-a-vault-secret-that-doesnt-exist) (recommended). Learn how [the Secret Scanner scans your public workspaces](/docs/administration/managing-your-team/secret-scanner/overview/). Postman sends in-app and email notifications to all workspace members when the workspace is made public. To view your in-app notifications, select the notification icon ![Changelog icon](https://assets.postman.com/postman-docs/icon-notification-bell-v9.jpg#icon) in the Postman header. To convert an existing workspace to a public workspace with a Postman Free or Basic plan, do the following: 1. Open the workspace. In the **Overview** tab, select **Settings**. 2. Under **Workspace types**, select **Public**. 3. Select **Save Changes**. To convert an existing workspace to a public workspace in a Postman Professional or Enterprise plan, do the following: 1. Open the workspace. In the **Overview** tab, select **Settings**. 2. Under **Workspace type**, select **Change**. 3. Select **Public**. 4. Enter a note for approval. 5. Select **Submit Request**. ![Request visibility change](https://assets.postman.com/postman-docs/v11/public-workspace-request-v11.33.jpg) This sends a request to team members with the Community Manager role for their approval, and triggers the [Secret Scanner](/docs/administration/managing-your-team/secret-scanner/overview/). The workspace's visibility will be set to [internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#change-workspace-visibility) until it's [approved](/docs/administration/managing-your-team/manage-team-workspaces/#approve-workspace-creation-requests). While you're waiting for the request to be reviewed, you can check the status of the secret scan or cancel the request from the workspace settings. ## Feature collections in public workspaces You can feature collections in a public workspace to give API consumers quick access to specific collections. On a public workspace's **Overview** tab under **Featured collections**, select ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add**, then select the collection you'd like to feature. ![Featured collection in public workspace](https://assets.postman.com/postman-docs/v11/featured-collections-v11-12.jpg) You can choose an environment for each featured collection you'd like to be active when it's opened from the **Overview** tab. The environment will be active in the [environment selector](/docs/sending-requests/variables/managing-environments/#switch-between-environments). If you don't feature any collections in a public workspace, Postman will automatically feature popular collections in the public workspace. To remove a featured collection, hover over the collection and select ![Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon), then select **Remove**. ## Invite collaboration on a public workspace An informative and inviting public workspace can help increase adoption of your APIs. To invite collaboration from other users on your public workspace, you need to have: * A complete [public team profile](#make-your-team-profile-public). * A complete [workspace overview](#edit-public-workspace-details), including a name, summary, and description. * Descriptive [documentation](/docs/publishing-your-api/api-documentation-overview/) for your APIs. Signs of a public workspace that invites collaboration include: * **Active forks of your workspace** - The number of people who [fork your workspace](/docs/collaborating-in-postman/using-version-control/forking-elements/) and work on their forks shows strong collaborator engagement. * **People watching your workspace** - The number of people who [watch your workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#watch-a-workspace) for activity can reflect interest from potential collaborators. * **Recent activity on the workspace** - A [workspace activity feed](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#view-workspace-activity) that shows ongoing work reassures potential collaborators that your team updates and maintains the workspace. For more information on using a public workspace to help increase adoption of your API, see [Increasing adoption of an API with a public workspace](https://blog.postman.com/increasing-adoption-of-an-api-with-a-public-workspace/) on the Postman blog. ### Share a public workspace You can share a public workspace by giving collaborators its **workspace URL** directly. To access a workspace's URL, do the following: 1. Go to the workspace **Overview** page. 2. Select ![Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy link to workspace** next to the workspace name to copy the workspace's URL to your clipboard. ![Copy link to workspace](https://assets.postman.com/postman-docs/v10/copy-workspace-link-v10.jpg) 3. Share the workspace URL with others. When you share a workspace with Postman users who aren't team members, its visibility must be public. If the workspace is an internal workspace, users who don't have access won't be able to open it. ## Announce your workspace updates Keep the watchers of your workspace and collection informed about any changes to your APIs. You can share updates across multiple collections and link to the specific request, collection, or folder that changed. These watchers get notified and can engage with these updates by commenting and reacting. ### Post an update To post a workspace update, do the following: 1. Open a workspace and select the **Updates** tab. If this is the first update, select **Post an Update**. Otherwise, you'll see a **Post an update** field above other updates. 2. Enter your update's title and description. 3. Select a tag from the dropdown list: **Improvement**, **New Feature**, **Bug Fix**, **Breaking Change**, or **Announcement**. 4. (Optional) Select **Link a Resource** to include links to collections, requests, and saved examples in your update. When you add links to collections or requests, the watchers of the collections, who may not be watching the workspace, are notified about the update alongside workspace watchers. 5. If you've integrated Postman with Slack, you can post a workspace update to a channel. Select **Post Update**. If a Slack channel is already subscribed to workspace updates, the checkbox next to **Share on Slack** on the bottom right of the post will be checked. If not, select ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) integrations page. ![Posting a public workspace update](https://assets.postman.com/postman-docs/v11/workspace-post-update-v11-38.jpg) Your API consumers can respond to a workspace update by adding a comment or reacting with an emoji response. Teams can connect up to 10 Slack channels to a single public workspace. ### Share workspace updates To share a workspace update select ![Share icon](https://assets.postman.com/postman-docs/aether-icons/action-share-stroke.svg#icon) the share icon. Select **Share via X** or **Share via LinkedIn** to share on social media, or select **Copy Link** to copy a link to the update. Viewers in a public workspace (including those inside and outside the team that owns the public workspace) can subscribe to public workspace updates. ### Edit or delete a workspace update To edit or delete an update, do the following: 1. Open a workspace and select **Updates**. 2. Select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. 3. Select **Edit** or **Delete**. ## Manage a public workspace When a user opens a public workspace, Postman shows an overview of its contents, activity, and members in an **Overview** tab. The user interacts with the contents of the public workspace, including the collections, APIs, environments, and other elements. As a team member with an [Admin role](/docs/administration/roles-and-permissions/#workspace-roles) on the workspace, you can manage the overview, the elements in the workspace, and the members of the workspace. ### Edit public workspace details Users with an [Admin role](/docs/administration/roles-and-permissions/#workspace-roles) for a workspace can edit workspace details, including updating the workspace's name, summary, description, and visibility. For more information, see [Editing workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). The [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/) displays your workspace's name and summary. Make your workspace name and summary informative to improve its visibility on the Postman API Network. ### Move elements to a public workspace You can move Postman elements from your internal workspace into a public workspace. You must have an [Admin or Editor role](/docs/administration/roles-and-permissions/#workspace-roles) for the public workspace to move elements to it. To move an existing element to a public workspace, do the following: 1. Select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to the collection or environment name, then select **Move**. 2. Select the public workspace to which you want to move the collection or environment, then select **Move Collection** or **Move Environment**. The Postman element that you move to the public workspace will no longer exist in the original workspace. If there are monitors, mock servers, or integrations associated with the moved element, they remain in the original workspace. The API's collections will move with the API to the new workspace. ### Delete elements from a public workspace You can delete Postman elements from a public workspace for which you have an [Admin or Editor role](/docs/administration/roles-and-permissions/#workspace-roles). 1. Select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to the element's name, then select **Delete**. 2. Select **Delete** to confirm your choice. Learn more about [deleting a collection](/docs/collections/use-collections/manage-collections/#delete-a-collection) and [restoring a deleted collection](/docs/collections/use-collections/manage-collections/#recover-or-permanently-delete-a-collection). ### Delete a public workspace To delete a public workspace, you must change its visibility first. You must have an [Admin role](/docs/administration/roles-and-permissions/#workspace-roles) for a workspace to be able to delete it. 1. On the workspace overview, select **Settings**. 2. Under **Workspace type**, select **Change**. 3. Select **Internal**. 4. Select **Save Changes**. 5. After you update its visibility, select **Delete Workspace**. 6. Enter the workspace name to confirm that you want to delete it, then select **Delete workspace**. ![Unable to delete a public workspace](https://assets.postman.com/postman-docs/public-workspace-cant-delete-v9.jpg) ### Manage public workspace users and roles If you're a [Team Admin](/docs/administration/roles-and-permissions/#team-roles), you can manage collaborators and user roles in a public workspace: * **Invite team members, groups, and external users to collaborate in a public workspace.** To learn more about inviting users to work with you in your public workspace, see [Sharing workspaces](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). * **Assign access to elements within a workspace.** Workspace roles control access to elements. You can assign workspace roles to an individual user or to a user group. To learn more about assigning workspace roles or removing a user from a workspace, see [Manage workspace roles](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles). Team members will receive an email and in-app notification when they're added to a public workspace. ## Collaborate in another user's public workspace To collaborate with someone else in their public workspace, select **Workspaces** from the header, and then select the workspace you want to work in. For **collections** and **environments**, [create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork) and request to merge changes using a [pull request](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). For **APIs**, select the API and version. Select the **Definition** tab and then select **Request Access** to request an Editor role. You can access public workspaces using the Postman Explore page's [**Workspaces** category](https://www.postman.com/explore/workspaces). You can also access the public workspaces that you own or are a member of using **Workspaces** in the header. The list of avatars in the Postman header shows you who's active in your workspace. This list will include all active users with [public profiles](/docs/getting-started/installation/postman-profile/#make-your-profile-public), and users who've chosen to remain anonymous by not enabling their public profile. ![Active users in public workspace](https://assets.postman.com/postman-docs/presence-public-workspace-v9.19.jpg) Viewers in a public workspace (including those inside and outside the team that owns the public workspace) can subscribe to public workspace updates. ## Next steps Once you start working collaboratively in a public workspace, users can fork collections and create pull requests. --- # Publish documentation in Postman Publishing your documentation makes it publicly available to anyone with the link to the documentation. Publish your documentation to help people around the world learn how to use your collection or interact with your public API. Public documentation automatically includes details for each request or endpoint in the published collection, along with sample code in various client languages. As you update your collection, the published documentation automatically stays in sync with your latest changes. There's no need to publish the documentation again after making changes. Your public documentation includes the **Run in Postman** button ![Image 1: Run in Postman button](https://assets.postman.com/postman-docs/run-in-postman-button-icon.jpg#icon) so users can interact with your collection or API directly in Postman. For an example, check out the [Postman API documentation](https://documenter.getpostman.com/view/12959542/UV5XjJV8) which was published from a Postman Collection. ## Make your documentation public To publish [documentation](/docs/publishing-your-api/document-a-collection/), it must be part of a collection. You can publish documentation for any collections you've created or have permission to edit. Publishing is only supported for collections with HTTP requests. Also, you can't publish a collection that has been added to an API. Instead, you can [publish a version of the API in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/). A published version includes the API's definition and collections. To publish the documentation for a collection, do the following: 1. Click **Collections** in the sidebar, and then select your collection. 2. From the collection's **Overview** tab, click **View complete documentation**. 3. Click **Publish** to navigate to the **Publish Documentation** interface. ![Publish documentation](https://assets.postman.com/postman-docs/v11/documentation-publish-button-v11.jpg) ## Update publication settings In the **Publish Documentation** interface, change any publication settings as needed. ### Content Select the content that you want to publish with your docs: * **Version** - This defaults to **CURRENT**. You can't create versions or releases for collections in Postman v10 and later, but you can [publish versions of an API in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/). * **Environment** - Select an [environment](/docs/publishing-your-api/document-a-collection/#associate-environments-with-documentation) to publish environment variables with your documentation. The shared values of all variables are published with your documentation, so make sure they don't contain sensitive information such as passwords or tokens. ### URL Select a [custom domain](/docs/publishing-your-api/custom-doc-domains/) from the **Custom domain** dropdown list where you want to publish your documentation. ### Appearance Select the appearance settings for your published docs. You can preview any changes you make in the sample layouts in this section before you publish your docs. * **Default layout** - Select a default layout style for your documentation. **Double column** displays sample code in a column next to the documentation. **Single column** displays sample code inline beneath each request. Your documentation uses this layout by default, but users can select a preferred layout style. * **Default Theme** - Select a light or dark theme for your documentation. You can also choose to use the system theme. Your documentation uses the selected theme by default, but users can switch between themes. * **Logo** - By default, public documentation uses your [team logo](/docs/administration/managing-your-team/team-settings/#customize-your-teams-branding). You can also select a custom logo for each theme (light and dark): * To add a logo, click the edit icon ![Image 2: Edit icon](https://assets.postman.com/postman-docs/documentation-edit-icon-v8-10.jpg#icon) and click **Upload**. Drag and drop an image file, or select an image file. Drag the handles to adjust the part of the image you want to display, then click **Upload**. * To delete a logo, click the edit icon ![Image 3: Edit icon](https://assets.postman.com/postman-docs/documentation-edit-icon-v8-10.jpg#icon) and click **Delete**. You can use different logos for each collection you publish. Logos must be 2 MB or less in size and must be in JPEG or PNG format. The logo can be any aspect ratio (square or rectangle.) * **Colors** - You can customize the colors (in hex format) for each theme (light and dark): * **Header background** - Specify a color for the header at the top of the documentation window. * **Code background** - Specify a color for sample code blocks. * **Highlight** - Specify a color for hyperlinks. ### SEO Add metadata to your documentation to make it more discoverable on the web. * **Title** - Add a title for your documentation (60 characters or less). The title appears in web searches and in browser tabs. * **Description** - Add a brief description to let users know what your documentation is about (160 characters or less). You can also add relevant keywords to help users find your documentation when searching the web. ### Preview your documentation To preview your documentation using the current settings, click **Preview Documentation**. The preview automatically updates as you change settings. If Postman detects a possibly sensitive token or other secret, a warning appears at the top of the preview window. Postman also highlights the token so you can remove it from the documentation before publishing. ### Publish your documentation When you're finished changing settings, click **Publish** to publish your documentation. * **Postman Free, Basic, and Professional plans** - You can optionally select a [public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) to move the collection to. This makes the collection discoverable on the [Postman API Network](https://www.postman.com/explore). When you're ready, click **Publish**. You can view your public documentation at the provided URL. * **Postman Enterprise plans** - Your [Community Manager](/docs/administration/roles-and-permissions/#team-roles) controls the Postman elements your team makes public. Enter a note for your Community Manager and click **Request Publish**. When your request is approved, you'll receive an email notification with a link to the public documentation. To retract your publish request, [change the pending publication settings](#change-publication-settings) and click **Retract request**. ![Published documentation example](https://assets.postman.com/postman-docs/v11/documentation-published-docs-v11.jpg) ## Share your public docs To share your public documentation, share the published URL with your team members, other users, or the community. If you have forgotten the URL of your published documentation, you can get it at any time. 1. Click **Collections** in the sidebar, and then select your collection. 2. From the collection's **Overview** tab, click **View complete documentation**. 3. Click **Published**, and then click **Copy published link**. ![Copy published link](https://assets.postman.com/postman-docs/v11/documentation-published-link-v11.jpg) If your collection is in a public workspace, others can search for and find your collection on the [Postman API Network](https://www.postman.com/explore), along with its documentation. If you haven't already moved your collection to a public workspace, you can do so at any time by [changing the publication settings](#change-publication-settings). By sharing your documentation with the Postman API Network, you increase the visibility of your API to a wider range of consumers in the Postman community. Learn more about [public workspaces](/docs/collaborating-in-postman/using-workspaces/public-workspaces/). ## Change publication settings Change the publication settings for your documentation to update your documentation's look or make your collection public. You can change the publication settings at any time after publishing your documentation. 1. Click **Collections** in the sidebar and click **View complete documentation**. 2. Click **Published** at the upper right, and then click **Edit published documentation**. ![Edit published documentation](https://assets.postman.com/postman-docs/v11/documentation-edit-published-docs-v11.jpg) 1. Click **Edit settings**, and then change the [publication settings](#make-your-documentation-public) as needed. 2. Click **Save and republish**. ## Unpublish your docs If you no longer want your documentation to be publicly available, you can unpublish it. 1. Click **Collections** in the sidebar and click **View complete documentation**. 2. Click **Published** at the upper right, and then click **Edit published documentation**. 3. Click **Unpublish**. If you change your mind, you can [publish your documentation](#make-your-documentation-public) again at any time. ![Unpublish documentation](https://assets.postman.com/postman-docs/v11/documentation-unpublish-v11.jpg) --- # Send a request with the Postman API client Postman supports sending requests using HTTP, [GraphQL](/docs/sending-requests/graphql/graphql-overview/), [gRPC](/docs/sending-requests/grpc/grpc-client-overview/), [WebSocket](/docs/sending-requests/websocket/websocket-overview/), [MQTT](/docs/sending-requests/mqtt-client/mqtt-client-overview/), and [SOAP](/docs/sending-requests/soap/making-soap-requests/) protocols. Postman also supports AI-driven development with [AI requests in collections](/docs/postman-ai/ai-requests/overview/) and [AI Request blocks in Postman Flows](/docs/postman-ai/ai-request-blocks/overview/). You can also use Postman as your Model Context Protocol (MCP) client and [send requests to MCP servers](/docs/postman-ai/mcp-requests/overview/). Start a new request by specifying the request type, then fill the details and test the request by clicking **Send**. After you save the request, you can share it with your team. You can also refer to [requests from publicly maintained workspaces](#leverage-public-api-examples) for the APIs you're testing and integrating with. This topic primarily covers creating and sharing HTTP requests. For more detail about sending requests using other protocols, follow the respective links above. ## Create a new request Your requests can include multiple details determining the data Postman sends to the API you're working with. Depending on the type of request, enter a URL and select a method (HTTP, GraphQL, gRPC, WebSocket, Socket.IO, or MQTT request) or select a model (AI request) or enter a command (MCP request), then specify other details. You can create a new request from a workspace by clicking **New** and selecting the request type. ![Create new request](https://assets.postman.com/postman-docs/v11/create-new-http-v11-1.jpg) Alternatively, click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add** next to an open tab. You can switch your request type by clicking the request icon next to the request name. ![Switch request type](https://assets.postman.com/postman-docs/v11/switch-request-type-v11.51.png) You can't change the request protocol after you click **Save**. To open an HTTP request quickly, click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add request** from a collection in the sidebar. ![Add a request from a collection](https://assets.postman.com/postman-docs/v11/add-request-from-collection-v11.51.png) Click **Save** to save your request. You can give your request a name and description, and choose or create a [collection](/docs/sending-requests/create-requests/intro-to-collections/) to save it in. You can also specify values such as authorization, parameters and body data, and headers. To test sending a request in Postman, set the URL to the [Postman Echo](/docs/developer/echo-api/) `https://postman-echo.com/get` endpoint, select the GET method, then click **Send**. ![New Request](https://assets.postman.com/postman-docs/v11/empty-request-v11-2.jpg) You can turn on autosave to automatically save your changes to requests. Learn more about [autosave](/docs/getting-started/installation/settings/#application). ### Specify request URLs Most requests you send in Postman require a URL that represents the API endpoint you're working with. Each operation you can perform using an API is typically associated with an endpoint. Each endpoint in an API is available at a specific URL. This is what you enter into Postman to access the API. * If you're building an API, the URL is typically the base location plus path. For example, in the `https://postman-echo.com/get` request, `https://postman-echo.com` is the base URL, and `/get` is the endpoint path. * If you’re using a public API, your API provider supplies the URLs you need, often located in their developer documentation. As you start typing in the URL box, Postman displays a dropdown list of requests you've used before in your current workspace. The dropdown list also includes requests used in collections in your current workspace. Choose a request from the list of suggestions to autofill your request with details, such as parameters and authorizations. If you're using a public API from a [verified team](/docs/postman-api-network/explore/consume/#choose-public-elements), suggestions display in the URL box after you enter the base URL, such as `https://api.getpostman.com`. You can click a suggested endpoint to autofill your request with a template of what you need to get started, such as parameters and authorization. Your request may autofill with an empty variable if the API publisher didn't define a value for the variable. Learn how to [set a value for an empty variable](/docs/sending-requests/variables/variables/#setting-values-for-variables-without-a-scope). ![Auto-suggest public API endpoints](https://assets.postman.com/postman-docs/v11/auto-suggest-public-api-v11-43.jpg) Postman automatically adds `http://` to the start of your URL if you don't specify a protocol. You can optionally enter *query* parameters in the URL box or enter them in the **Params** tab. If your request uses *path* parameters, you can enter them in the URL box. Learn more about [sending parameters and body data with API requests in Postman](/docs/sending-requests/create-requests/parameters/). You can use [next generation URL encoding](/docs/sending-requests/create-requests/request-settings/#encode-your-request-urls) in your requests. ### Select request methods By default, Postman selects the GET method for new request. GET methods typically retrieve data from an API. You can use a variety of other methods to send data to your APIs, including: * **POST** - Add new data. * **PUT** - Replace existing data. * **PATCH** - Update existing data fields. * **DELETE** - Delete existing data. For example, if you're working with an API for a to-do list application, you might use a GET method to get the current list of tasks. You can then use a POST method to create a new task or use a PUT or PATCH method to edit an existing task. Postman supports a number of extra request methods by default, and you can use custom methods. Click the method dropdown list, edit the method name text, and save your new method. To delete a method, hover over it in the list and click the delete icon ![Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke-small.svg#icon). The same location (sometimes called *route*) can provide more than one endpoint by accepting different methods. For example, an API might have a POST `/customer` endpoint for adding a new customer, and a GET `/customer` endpoint for retrieving an existing customer. ## Send a request After you specify the request protocol, method, and URL, add any other details required by the API you're sending the request to: * Specify any [parameters and body data](/docs/sending-requests/create-requests/parameters/) or request [headers](/docs/sending-requests/create-requests/headers/) you need to send with the request. * Set up any required [authentication and authorization](/docs/sending-requests/authorization/authorization/). * You can also [use cookies with your requests](/docs/sending-requests/response-data/cookies/) by clicking **Cookies** (under **Send**). After you enter all the request details, click **Send** to send the request to the API server. You can view the response from the server in the response pane. There you can use several tools to help you understand the response, like [search specific phrases](/docs/sending-requests/response-data/responses/#search) or [filter relevant information](/docs/sending-requests/response-data/responses/#filter) with JSONPath and XPath. Learn more about [API response structure in Postman](/docs/sending-requests/response-data/responses/). You can view requests you've sent in **History** in the sidebar and send them again. You can also save and organize requests in a [collection](/docs/sending-requests/create-requests/intro-to-collections/). ![Send a request](https://assets.postman.com/postman-docs/v11/send-first-request-v11-35-4.jpg) ## Share your requests You can share requests with collaborators by opening the request you want to share in the sidebar. Click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to the request, then click **Share**. Learn more about [sharing your work in Postman](/docs/collaborating-in-postman/sharing/). ![Share request](https://assets.postman.com/postman-docs/v11/share-request-v11.24.jpg) ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs/v11/icon-related-request.jpg#icon) **Related requests**. A pane opens displaying Notion's example search-related requests with links to the API collections. ![Open related requests](https://assets.postman.com/postman-docs/v11/related-requests-open-v11-14.jpg) You can view related documentation and example responses in place without navigating to a different page or window. You can also fork a collection and use it in your own workspace to test and reuse requests. ![Collections icon](https://assets.postman.com/postman-docs/Collections.png#icon) To try out a collection template that has a typical REST API, select [REST API Basics](https://www.postman.com/templates/collections/rest-api-basics/). ## Leverage public API examples To help you get started faster, as you create requests, Postman searches the [Postman API Network](http://postman.com/explore) in the background for related content from popular collections and from collections owned by verified teams. If you're testing and integrating with public APIs and their relevant content is found, it shows up in the **Related requests** tab in the right sidebar. For example, suppose you're testing an integration with Notion. Notion is a verified team, so you know you can trust their content. 1. Enter `api.notion.com/search` in the URL box. A dot appears next to ![Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-request-stroke.svg#icon) **Related requests**. ![Trigger related requests](https://assets.postman.com/postman-docs/v11/related-requests-trigger-v11-14.jpg) 1. Click ![Related requests icon](https://assets.postman.com/postman-docs --- # request The **Request** block is a special block that’s present by default in [Flows actions](/docs/postman-flows/build-flows/structure/actions/). The **Request** block takes request data sent to a deployed action’s URL and routes the data through its **Headers**, **Params**, and **Body** output ports. The **Request** block can’t be added or deleted. > You can change a **Request** block to a **Schedule** block to run the action at regular intervals or at specific times. To learn how, see [Schedule an action to run automatically](/docs/postman-flows/build-flows/structure/actions/#schedule-an-action-to-run-automatically). Prior to an action being deployed, the **Request** block takes the values for headers, parameters, and the request body that you store in [scenarios](/docs/postman-flows/build-flows/configure/scenarios/). By running different scenarios, you can test how your action will behave once it’s deployed. Testing with scenarios is necessary because the action won’t have a URL until you deploy it. > The **Request** block can ingest input data of up to 5 megabytes if you’ve [purchased the Flows add-on](https://www.postman.com/pricing/), or 1 megabyte if you’re using Flows for free. ## Outputs * **Headers** - Sends the request headers to the deployed action’s URL. * **Params** - Sends the request’s query parameters to the deployed action’s URL. * **Body** - Sends the request body to the deployed action’s URL. Actions support JSON, `form-data`, and `x-www-form-urlencoded` formats. ## Setup The **Request** block itself requires no setup, but it does require you to create at least one scenario with data that the **Request** block can take as input. This is a prerequisite for testing your action locally. By testing, you verify that the blocks you add make your action perform the desired work. The procedure for creating a scenario depends on the type and structure of the data you plan to send in the request body. > This procedure assumes you already know the JSON structure of the action you’re creating will require, or that you have a correct example request body available to copy and paste. If that’s not the case, see [Send URL-encoded or form data to actions in Postman Flows](/docs/postman-flows/build-flows/structure/actions-form-data/). 1. Create a scenario and type or paste a correctly structured example request body into the **Body** field. For an empty request body, use the empty JSON object `{}`. 2. (Optional) Add content for the **Headers** and **Query Params** fields as needed. 3. Save and run the scenario. 4. Click the **Body** output of the **Request** block to open the block footer, and verify that the block emitted the correct request body, headers, and parameters. ## Related blocks The **Request** block is one of the three blocks that every action has upon creation. The others are the [**Template**](/docs/postman-flows/reference/blocks/template/) and the [**Response**](/docs/postman-flows/reference/blocks/response/) block. --- # About resource usage Postman provides you with a specified number of resources you can use each month, depending on your [Postman plan](https://www.postman.com/pricing/). Monthly resources include calls to the Postman API, requests made by monitors and scheduled collection runs, mock server requests, and Cloud Agent requests. Your Postman plan also has other limits, such as the number of integrations you can create, the number of custom domains, and storage for uploaded images. To find out what the resource limits are for your plan, go to the [Postman Plans and Pricing page](https://www.postman.com/pricing/). To view the resources you are using, go to your [Resource Usage dashboard](https://go.postman.co/billing/add-ons/overview). You can view how close you are to your limits and when your monthly limits will reset. If you need more resources, you can [purchase add-on resources](/docs/billing/billing/#purchasing-add-on-resources) or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). Refer to the following sections to understand what happens when your resource usage reaches the limits set by your Postman plan. ## Team usage limits Your team's usage limits are based on your [plan type](https://www.postman.com/pricing/) and any [add-ons](/docs/billing/billing/#purchasing-add-on-resources) your team has purchased. Open the [**Resource usage** dashboard](http://go.postman.co/billing/add-ons/overview) to view your team's usage of mock servers and monitors, APIs created, collection runner runs, image and file storage, flows created by your team, performance tests, integrations, and the Postman Cloud Agent. To open the **Resource usage** dashboard, do one of the following: * **Free users** - In the Postman header, select ![Down Large icon](https://assets.postman.com/postman-docs/aether-icons/direction-down-large.svg#icon) next to **Upgrade**. * **Paid users** - In the Postman header, select **Team**. To learn more about the resources included with your Postman plan and what happens when you reach your usage limits, go to [About resource usage](/docs/billing/resource-usage/). ![Team resource usage information](https://assets.postman.com/postman-docs/v10/team-dropdown-resource-usage-v10-22.jpg) Team members with the [Billing role](/docs/administration/roles-and-permissions/#team-roles) can [purchase extra blocks](/docs/billing/billing/#purchasing-add-on-resources) of monitoring requests, mock server calls, and custom domains in the [billing dashboard](http://go.postman.co/billing). ## Mock server usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of requests that can be sent to your [Postman mock servers](/docs/design-apis/mock-apis/set-up-mock-servers/) each month. Requests to all of your mock servers count toward this same limit. After the limit is reached, you will get a `Usage limit reached` error message in the response body when sending a request to one of your mock servers. To make more requests to your mock servers before your monthly limit resets, you can [enable pay-as-you-go](/docs/billing/billing/#managing-resources), [purchase add-on resources](/docs/billing/billing/#purchasing-add-on-resources), or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Monitoring usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of requests that can be run by your [Postman Monitors](/docs/monitoring-your-api/setting-up-monitor/) each month. Requests run by your [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/) and [Private API Monitoring](/docs/monitoring-your-api/runners/overview/) count toward this same limit. After the limit is reached, you will get a notification by email and in the Postman app letting you know that you've reached the usage limit for monitors. Once you've reached your usage limit, your monitors and scheduled collection runs will no longer run on their configured schedules and can't be run manually. To resume running your monitors and scheduled collection runs before your monthly limit resets, you can [enable pay-as-you-go](/docs/billing/billing/#managing-resources), [purchase add-on resources](/docs/billing/billing/#purchasing-add-on-resources), or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). Learn more about [viewing and managing your monitor usage](/docs/monitoring-your-api/monitor-usage/). ## Custom domains Postman paid [plans](https://www.postman.com/pricing/) give you a limited number of [custom domains](/docs/publishing-your-api/custom-doc-domains/) you can use when publishing API documentation. After the limit is reached, you won't be able to add a new custom domain. To add a new custom domain, delete one of your existing custom domains, [purchase add-on resources](/docs/billing/billing/#purchasing-add-on-resources), or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## API Builder resources Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of APIs you can create in the [API Builder](/docs/design-apis/api-builder/overview/). After the limit is reached, you won't be able to create new APIs in API Builder. To create a new API, delete one of your existing API Builder APIs, or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Manual Collection Runner runs Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of [collection runs](/docs/collections/running-collections/intro-to-collection-runs/) you can use each month. This limit applies to collections that you run in a workspace using the **Run manually** option. This is separate from the limits for [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/) in the Postman cloud. A collection run with multiple iterations counts as a single run. You can check your manual collection run usage in the [Resource Usage dashboard](https://go.postman.co/billing/add-ons/overview). Also, a message will display in the Collection Runner when you're approaching your usage limit. Once you've reached your usage limit, you will no longer be able to run your collections using the **Run manually** option. To resume running collections before your monthly limit resets, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes), [schedule collection runs](/docs/collections/running-collections/scheduling-collection-runs/) in the Postman cloud, or run collections using the [Postman CLI](/docs/postman-cli/postman-cli-run-collection/) or [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). Requests run in the Postman cloud by your [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/) count toward your [monitoring usage](#monitoring-usage). Scheduled collection runs don't count toward your manual collection runs usage. ## Storage usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited amount of storage for [uploaded images](/docs/publishing-your-api/authoring-your-documentation/#uploading-an-image) in your API documentation. You will get an error message if you try to upload an image that would exceed your storage limit. To upgrade your available storage, contact [Postman support](https://www.postman.com/support/). Learn more about [image storage limits](/docs/publishing-your-api/authoring-your-documentation/#image-storage-limits) for API documentation. ## Flows usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of credits that can be consumed by AI blocks like the [**Create with AI** block](/docs/postman-flows/reference/blocks/create-with-ai/) in [Postman Flows](/docs/postman-flows/overview/). Credits are shared across all users on a team. To get more credits, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). Learn about [flows usage](/docs/billing/flows-usage/). ## Performance test limit Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of [performance test runs](/docs/collections/performance-testing/testing-api-performance/) you can use each month. This limit applies to collections that you run using the **Performance** tab in the Collection Runner. This is separate from the limits for functional tests ([manual collection runs](/docs/collections/running-collections/intro-to-collection-runs/) and [scheduled collection runs](/docs/collections/running-collections/scheduling-collection-runs/)). You can check your performance test usage in the [Resource Usage dashboard](https://go.postman.co/billing/add-ons/overview). Also, a message will display in the Collection Runner when you're approaching your usage limit. Once you've reached your usage limit, you will no longer be able to run performance tests. To resume running performance tests before your monthly limit resets, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Specifications Your [Postman plan](https://www.postman.com/pricing/) gives your team a limited number of [specifications](/docs/design-apis/specifications/overview/) to create in Spec Hub in internal workspaces. In the [Resource Usage dashboard](https://go.postman.co/billing/add-ons/overview), you can see how many specification have been created in internal workspaces. To create more specifications in internal workspaces, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Packages Your [Postman plan](https://www.postman.com/pricing/) gives your team a limited number of [packages](/docs/tests-and-scripts/write-scripts/packages/package-library/) to create in the Postman Package Library. In the [Resource Usage dashboard](https://go.postman.co/billing/add-ons/overview), you can see how many packages have been created. To create more, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). As a [Team Admin](/docs/administration/roles-and-permissions/#team-roles), you can select **View detailed usage** to view a detailed list of packages in your team. For each package, you can view the package name, who created the package, and when the package was created. You can also view when the package was last used. The last used date increases when one of the following occurs: * A teammate views the package in the package library. * A teammate sends an HTTP request that imports the package, and this is the first time they send the request after opening Postman. To work with packages in your team, do any of the following: * To filter the list by package name, start typing in the search box. * To filter the list by the user who created the package, select a team member in the **Uploaded by** dropdown list. * To delete a package, hover over a package and select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) > ![Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke.svg#icon) **Delete**. ![Manage test data](https://assets.postman.com/postman-docs/v11/test-data-manage-v11-40.jpg) Once you've reached your test data storage limit, you won't be able to upload more test data files. You can delete files to free up storage space, or you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). Once you're reached your test data retrieval limit, requests that use uploaded data files won't be able to retrieve those files before being sent. This includes requests that are sent manually or automatically from a scheduled collection run, monitor, flow, or the Postman CLI. To resume using test data before your monthly limit resets, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Agent Mode usage With [Agent Mode](/docs/agent-mode/overview/), you get a monthly AI credit allowance on Free, Basic, and Professional plans. On the Free plan, when your team members reach their monthly credit limit, you can purchase the Postman AI add-on to get more monthly credits. On Basic and Professional plans, you can keep using Agent Mode after reaching your limit if credit overages are enabled by an Admin. If overages aren’t enabled, Agent Mode pauses until credits renew. To learn more, see [Manage your Postman Agent Mode credits](/docs/billing/agent-mode-usage/). ## Postbot usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of Postbot activities each month. Postbot will notify you when you reach the monthly activity limit. You can't use it for the remaining month unless you [purchase Postbot as an add-on](/docs/billing/billing/#purchasing-add-on-products). ## Postman API usage Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of requests that can be sent to the [Postman API](/docs/developer/postman-api/intro-api/) each month. After the limit is reached, you will get a `Service limit exhausted` error message in the response body when sending a request to the Postman API. To make more requests to the Postman API before your monthly limit resets, you can [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Integrations Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of [integrations](/docs/integrations/intro-integrations/) for connecting Postman to third-party tools you use for API development. After the limit is reached, you won't be able to add a new integration. You will get a notification in the Postman app when attempting to add a new integration. To add a new integration, delete one of your existing integrations or [upgrade your plan](/docs/billing/billing/#team-and-plan-changes). ## Cloud Agent usage The [Postman Cloud Agent](/docs/getting-started/basics/about-postman-agent/#postman-cloud-agent) enables you to send requests from the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app) without encountering cross-origin resource sharing (CORS) limitations. Your [Postman plan](https://www.postman.com/pricing/) gives you a limited number of requests that can be sent using the Cloud Agent each month. After the limit is reached, you will get a `Cloud Agent Error` message in the response body when sending a request from the Postman web app using the Cloud Agent. To continue sending requests from the Postman web app before your monthly limit resets, [upgrade your plan](/docs/billing/billing/#team-and-plan-changes) or switch to the Postman Desktop Agent. In the error message, select **Use Postman's Desktop Agent**. If you haven't already installed the Desktop Agent, you'll be prompted to download it. Learn more about [installing and using the Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent). --- # API response structure in Postman The Postman response viewer helps you visualize and check the correctness of API responses. An API response consists of the response body, headers, cookies, and the HTTP status code. You can view details about the response, including test results, network information, response size, response time, and security warnings. You can also save responses as examples or files. ## Response body The Postman **Body** tab gives you several tools to help you understand the response, including a data type selector, preview, search, filter, and Postbot-powered visualization. ### Data type selector When you send a request, Postman automatically displays the data type of your response. For example, JSON responses are automatically shown in the JSON mode. Syntax is highlighted depending on the data type. You can select a different type: **JSON**, **XML**, **HTML**, **Raw**, **Base64**, or **Hex**. If your response contains a link, it's highlighted. Selecting it loads a `GET` request. ![Select data type](https://assets.postman.com/postman-docs/v11/data-type-selector-v11.23.jpg) **Force JSON formatting**. You can choose to have Postman auto-select your response data type or force JSON formatting. To update your selection, go to ![Settings](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the Postman header, then select **Settings**. Under **General > Request > Response format detection**, select **JSON**. ### Preview The ![Play AI icon](https://assets.postman.com/postman-docs/aether-icons/action-playAI-stroke.svg#icon) **Preview** tab provides a friendlier view into the data that's being sent and helps you understand any errors that occur. It supports many file formats, including **audio**, **video**, **script**, **image**, **plain**, and **embed**. JSON and XML data types display as tables. ![Response preview](https://assets.postman.com/postman-docs/v11/response-pane-preview-v11.23b.jpg) ### Search You can use search phrases to find content of interest in your response. Click ![Search icon](https://assets.postman.com/postman-docs/aether-icons/action-search-stroke.svg#icon) **Search** in the response pane. You can also place your cursor in the response and press **⌘+F** or **Ctrl+F**. ![Response search](https://assets.postman.com/postman-docs/v11/response-pane-search-v11-35-4.jpg) ### Filter To improve readability, you can filter your responses to show only relevant information. Use [JSONPath](https://datatracker.ietf.org/doc/html/rfc9535/) to filter JSON responses. Use [XPath](https://www.w3.org/TR/2010/REC-xpath20-20101214/) to filter XML and HTML responses. With **JSON**, **XML**, or **HTML** selected in the data type selector, select ![Filter icon](https://assets.postman.com/postman-docs/aether-icons/action-filter-stroke.svg#icon) **Filter** in the response pane. Then enter a JSONPath expression to filter JSON or an XPath expression to filter XML or HTML. For JSONPath expressions, Postman suggests autocomplete options based on keys in the response. The response automatically displays the results of your expression. If you enter an expression that doesn't return results, Postman will flag it with a yellow underline. If you enter an expression that isn't valid, Postman will flag it with a red underline. Hover over the expression to view a tooltip about the issue. The expression persists in the response unless you close the request or clear the expression. A green dot on ![Filter icon](https://assets.postman.com/postman-docs/aether-icons/action-filter-stroke.svg#icon) indicates that the response is being filtered with an expression. Select ![Clear icon](https://assets.postman.com/postman-docs/aether-icons/action-clear-stroke.svg#icon) to clear the expression and display the full response. When you enter an XPath expression, you can use it with both the **XML** and **HTML** data types. ![Response filter](https://assets.postman.com/postman-docs/v11/response-pane-filter-v11-35-4.jpg) ### Visualization The ![Image icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-image-stroke.svg#icon) **Visualization** tab renders the data in the API response according to visualization code that you add to the **Scripts > Post-response** tab. You can also use Postbot to generate visualizations for you. For details on how to add, use, and debug visualization code, see [Visualize request responses using Postman Visualizer](/docs/sending-requests/response-data/visualizer/). ![Response visualization](https://assets.postman.com/postman-docs/v11/response-pane-visualization-v11.23.jpg) ## Server-sent events Server-sent events (SSE) is a standard server-push technology for real-time communication between a client and a server over HTTP/S. SSE supports efficient and low-latency data transmission, making it a popular choice for applications that require real-time updates, such as chat apps and live sports updates. You can test, debug, and document your SSE-based APIs along with your other APIs in Postman. Consume server-sent events by creating a new HTTP request. Postman establishes the SSE connection and then streams and displays the events. You can drill into, search through, and clear the SSE messages in the response section. You can also save the response. To try SSE communication, use the following Postman Echo service endpoint: `https://postman-echo.com/server-events/:numberOfEvents`. ![SSE endpoint test](https://assets.postman.com/postman-docs/v11/sse-endpoint-test-v11.jpg) ## Cookies You can select **Cookies** to inspect cookies sent by the server. A cookie's entry includes its name, value, the associated domain and path, and other information about the cookie. To learn more about working with cookies in Postman, see [Create and capture cookies using Postman's cookie manager](/docs/sending-requests/response-data/cookies/). ## Headers Headers are displayed as key-value pairs under the **Headers** tab. Hover over the information icon ![Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) next to the header name to get a description of the header according to the HTTP specification. ## Test results If the API request you are viewing had any tests, the results are displayed in the **Test Results** tab. To learn more about running tests against API requests in Postman, see [Write scripts to test API response data in Postman](/docs/tests-and-scripts/write-scripts/test-scripts/). ## Network information Postman displays network information when your API returns a response. Hover over the network icon ![Connection secure icon](https://assets.postman.com/postman-docs/aether-icons/state-connectionSecure-stroke.svg#icon) to get the local and remote IP addresses for the request you sent. When you make an `https` request, the network icon includes a padlock. When you hover over the icon, the network information will show more information including the [HTTP version](/docs/sending-requests/response-data/troubleshooting-api-requests/#debugging-by-http-version) and [certificate verification](/docs/sending-requests/authorization/certificates/) details. ![Hover over the network icon for network information](https://assets.postman.com/postman-docs/v11/https-network-info-response-v11.23.jpg) ### SSL verification errors If SSL verification is enabled and verification fails, the response area displays an error message. Select the link to open the Console and view more information about the error. ![Verification error](https://assets.postman.com/postman-docs/v11/response-error-disable-ssl-v11.23.jpg) If needed, you can turn off SSL verification for the request or turn it off globally in Postman: * To turn off SSL verification for a request, select **Disable SSL Verification** in the response error message. * To turn off SSL verification globally, select ![Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the header and under **Settings > Request** turn off **SSL certificate verification**. If you have **SSL verification** turned off and your request returns a certificate verification error, you can hover over the network information for details about the error. ![Certificate error](https://assets.postman.com/postman-docs/v11/network-ssl-error-v11.23b.jpg) For requests that are successful and return data but with a certificate verification failure, the [Console](/docs/sending-requests/response-data/troubleshooting-api-requests/) displays a warning. ## Response code Postman displays the response code returned by the API. Hover over the response code to get a short description of the code and what it means. ![Hover over the response code to get a description](https://assets.postman.com/postman-docs/v11/response-code-v11.23.jpg) Some API responses also contain custom messages that can help you understand response codes. For example, if you receive a `401 Unauthorized` response, the message might tell you to check the token you used in the request. If custom messages are returned, they're displayed in the **Body** of the response. ## Response time Postman automatically calculates the time in milliseconds it took for the response to arrive from the server. This information can be useful for some preliminary performance testing. Hover over the response time for a graph with information on how long each event in the process took. ![Hover over the response code for a description](https://assets.postman.com/postman-docs/v11/response-time-v11.23.jpg) ## Response size Postman displays the size of the response. Hover over the response size to get a breakdown by body and header sizes. ## Saving responses If a request has been saved in a collection, you can save responses for that request. Once the response has been returned, you can: * Select ![Example icon](https://assets.postman.com/postman-docs/aether-icons/entity-example-stroke.svg#icon) **Save Response** to save the response as an [example](/docs/sending-requests/response-data/examples/) that you can access later. * Select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions > Save response to file** to save the response as a JSON file. * Select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions > Clear response** to remove any data in the response viewer. Note that for event-based requests, this is available after the stream is closed. ![Save an API response as an example or file](https://assets.postman.com/postman-docs/v11/save-response-v11.23.jpg) ## Security warnings Postman applies security rules configured for your [API requests](/docs/api-governance/api-testing/api-testing-warnings/) when you send requests to any API using either the Postman web app or the Postman desktop app. A security warning indicates that there are potential security risks the API might be vulnerable to, but they don't mean the API is broken. To view the specific security warnings that Postman applies to all requests, see [Security warnings](/docs/api-governance/api-testing/security-warnings/). If it finds any potential security risks, Postman adds the number of warnings to the **Security** tab in the response. ![Security tab showing one warning](https://assets.postman.com/postman-docs/v11/api-response-security-tab-v11.23.jpg) To view the list of security warnings and to get more information about specific warnings, do the following: 1. Select **Security** to view the warnings. 1. For more details, select a warning to expand it. 1. Select **Possible fix** to learn about possible ways to fix the underlying problem. ![Select Possible fix in a security warning](https://assets.postman.com/postman-docs/v11/api-response-security-tab-possible-fix-v11.23.jpg) ### Hide security warnings To turn a warning off for the current API response, do the following: 1. Select **Hide warning**. 1. Choose a reason for hiding it, then select **Hide**. This will turn the warning off for all members of your team for this response. To turn a warning off globally for your team, you can [configure your API Security rules](/docs/api-governance/configurable-rules/configuring-api-governance-rules/) (available for [Enterprise teams](https://www.postman.com/pricing/)). ![Select Hide warning in a security warning](https://assets.postman.com/postman-docs/v11/api-response-security-tab-hide-warning-v11.23.jpg) When you or another member of your team has hidden a warning, Postman shows a message in the **Security** tab to indicate how many are hidden. To turn this warning back on later, do the following: 1. Select **Review** in the **Security** tab. 1. Review your hidden warnings and select the eye icon ![Eye icon](https://assets.postman.com/postman-docs/eye.jpg#icon) next to the one you want to turn back on. ![Review hidden security warnings](https://assets.postman.com/postman-docs/v10/api-response-security-tab-review-hidden-warnings-v10-18.jpg) --- # Define roles and permissions within a Postman team Certain team options are only available with **[paid plans](https://www.postman.com/pricing/)**. To learn which roles are available with your plan, go to your **[web dashboard](https://go.postman.co/settings/team/roles)**. Roles define user permissions within a Postman team and a user's level of access to a Postman element, like a collection or an API. ## Team roles With the Admin role, you have the power to define Postman access at the team level. You can use Postman's role-based access control system to limit visibility of team resources, define your development workflow, and give access to administrative and billing personnel. Each user on a team must have at least one role attached to them, and can hold multiple roles simultaneously. You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/) one or more role types to team members, based on the functions those team members require: - **Super Admin** ([Enterprise plans only](https://www.postman.com/pricing/)) - Manages everything within a team, including team settings, members, roles, and resources. This role can view and manage all elements in [internal and public workspaces](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#change-workspace-visibility). Super Admins can perform all actions that other roles can perform. For information on assigning this role, see [Manage Super Admins](/docs/administration/managing-your-team/team-members/manage-roles/#manage-super-admins). - **Admin** - Manages team members and team settings. Can also view monitor metadata and pause and resume monitors. - **Billing** - Manages team plan and payments. Billing roles can be granted by a Super Admin, Team Admin, or by a fellow team member with a Billing role. - **Developer** - Has access to all team resources and workspaces. - **Community Manager** ([Professional and Enterprise plans only](https://www.postman.com/pricing/)) - Manages the public visibility of workspaces and team profile. - **Partner Manager** (Internal, [Enterprise plans only](https://www.postman.com/pricing/)) - Manages all [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/manage/) within an organization. Controls Partner Workspace settings and visibility, and can invite, remove, and manage partners. To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). - **Partner** (External, [Professional and Enterprise plans only](https://www.postman.com/pricing/)) - All partners are automatically granted the Partner role at the team level. Partners can only access the [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/manage/) they've been invited to. To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). - **Guest** (Internal) - Views collections and sends requests in collections that have been shared with them. This role can't be directly assigned to a user. To learn more, see [Share collections with guest users](/docs/collaborating-in-postman/sharing/#share-collections-with-guests). If you are on a [Postman Enterprise plan](https://www.postman.com/pricing/), you can also assign roles at the [group level](/docs/administration/managing-your-team/user-groups/). Team roles offer high-level access control: | Permission | Super Admin | Admin | Billing | Developer | Community Manager | | --- | --- | --- | --- | --- | --- | | Add users |    |    | | | | | Remove users |    |    | | | | | Update user email for other members of the team by SCIM |    |    | | | | | Manage team Admins and Developers |    |    | | | | | Manage SSO |    |    || | | | Add and edit custom domains |    |    | | |    | | Delete custom domains |    |    | | |    | | View audit logs |    |    | | |    | | View usage data |    |    |    |    |    | | Manage Billing members |    |    |    | | | | Manage payment |    |    |    | | | | Change plan |    |    |    | | | | View shared APIs, collections, environments, mock servers, monitors, and flows |    |    |    |    |    | | View and create internal workspaces |    |    |    |    |    | | Change visibility of workspaces to internal or public |    |    || | |    | | Enable public team profile |    |    | | |    | | Manage a team's Private API Network |    |    || | |    | There are additional specialized roles for [Enterprise](https://www.postman.com/pricing/) teams: - **API Network Manager** - Manages a team's [Private API Network](/docs/collaborating-in-postman/private-api-network/overview/). To learn more, see [Network roles](#network-roles). - **API Governance Manager** - Manages [API governance](/docs/api-governance/api-governance-overview/) within a team, including governance [rules](/docs/api-governance/configurable-rules/configuring-api-governance-rules/), [functions](/docs/api-governance/configurable-rules/configuring-custom-governance-functions/), and [workspace groups](/docs/api-governance/configurable-rules/configuring-api-governance-rules/#turn-configured-rules-on-and-off). - **Partner** (External, [Professional and Enterprise plans only](https://www.postman.com/pricing/)) - All partners are automatically granted the Partner role at the team level. Partners can only access the [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/manage/) they've been invited to. To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). - **Partner Lead** (External, [Enterprise plans only](https://www.postman.com/pricing/)) - Can invite other partners from their organization to join a [Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/manage/). To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). Partner team and Partner Workspace roles relate to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/) and are applied at the team, workspace, and collection levels. There are different team and Partner Workspace roles you can assign to team members and external partners: | | For team members | For partners | | --- | --- | --- | | **Team level** | Partner Manager | Partner | | **Workspace level** | Admin, Viewer, Editor | Viewer, Editor | | **Collection level** | Viewer, Editor | Viewer, Editor | You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/) the Partner Manager role to team members at the team level, and [invite](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/setup/#invite-collaborators-to-a-partner-workspace) partners with the Partner role: - **Partner Manager** - Manages all Partner Workspaces within an organization. Controls Partner Workspace settings and visibility, and can send invites to partners. If no Partner Manager role is assigned, the Team Admin is auto-assigned the Partner Manager role when they create their first Partner Workspace. - **Partner** - Can only access the Partner Workspaces they've been invited to. All partners are assigned [Workspace Editor or Viewer](#workspace-roles) roles when invited to a Partner Workspace. You can edit Partner Workspace permissions for partners at the workspace and collection levels. You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles) Partner Workspace roles to partners at the workspace level: - **Partner Lead** - Can invite other partners from their organization to join a Partner Workspace. - **Editor** - Partners can create and edit Partner Workspace resources, [import and export](/docs/getting-started/importing-and-exporting/importing-and-exporting-overview/) elements, and [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) elements to Partner Workspaces within the same team. - **Viewer** - Partners can view Partner Workspace resources and [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) elements to another Partner Workspace within the same team where they're assigned the Workspace Editor role. You can also [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) Partner Workspace roles to partners at the collection level: - **Editor** - Partners can [export collections](/docs/getting-started/importing-and-exporting/exporting-data/#export-collections). They can also [fork collections](/docs/collaborating-in-postman/using-version-control/forking-elements/) within the same Partner Workspace or to another Partner Workspace within the same team. They can't fork collections outside the team. - **Viewer** - Partners can [fork collections](/docs/collaborating-in-postman/using-version-control/forking-elements/) to another Partner Workspace within the same team where they're assigned the Workspace Editor role. They can't fork elements outside the team. Also, they can't export collections. To learn more about collaborating as a team member or partner, see [Collaborate in a Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/collaborate/). ## Workspace roles You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles) three role types in Postman workspaces: **Admin**, **Editor**, and **Viewer**. Partner Workspaces offer an additional role type: **Partner Lead**. - **Admin** - Can manage workspace resources and settings. - **Editor** ([Professional and Enterprise plans only](https://www.postman.com/pricing/)) - Can create and edit workspace resources. - **Viewer** ([Professional and Enterprise plans only](https://www.postman.com/pricing/)) - Can view, fork, and export workspace resources. - **Partner Lead** (External, [Enterprise plans only](https://www.postman.com/pricing/)) - Can invite other partners from their organization to join a [Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/manage/). To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). Partners have different permissions for Workspace Editor and Viewer roles in Partner Workspaces ([Enterprise plans only](https://www.postman.com/pricing/)). To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). You can use the Postman API to programmatically manage users and user groups for workspaces. For more information, see the [Postman API collection](https://api.postman.com/). The following roles control access at a workspace level: | Action | Admin | Editor | Viewer | | --- | --- | --- | --- | | Join and leave workspaces |    |    |    | | Send requests |    |    |    | | Add APIs, collections, environments, flows, and specifications |    |    |    | | Edit and delete specifications |    |    |    | | Move and delete APIs, collections, environments, and flows |    |    || | | Restore and permanently delete collections |    |    || | | Manage integrations |    |    || | | Add and delete monitors and mock servers |    |    || | | Move mock servers |    |    || | | Create and delete workspaces |    |    || | | Edit workspace details |    |    || | | Add and remove members |    |    || | | Manage workspace roles |    |    || | | Manage workspace visibility |    |    || | Workspace Editors can't move or delete any API. They must have the API Admin role on APIs they want to move or delete. On Professional and Enterprise plans, an Admin for a workspace must request to change its visibility to public. This request will go to the [Community Manager](#team-roles). On Basic and Free plans, or if a team has no Community Manager assigned, an Admin for a workspace can control its visibility. You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-workspace-roles) Partner Workspace roles to partners at the workspace level: - **Partner Lead** - Can invite other partners from their organization to join a Partner Workspace. - **Editor** - Partners can create and edit Partner Workspace resources, [import and export](/docs/getting-started/importing-and-exporting/importing-and-exporting-overview/) elements, and [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) elements to Partner Workspaces within the same team. - **Viewer** - Partners can view Partner Workspace resources and [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) elements to another Partner Workspace within the same team where they're assigned the Workspace Editor role. You can also [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) Partner Workspace roles to partners at the collection level: - **Editor** - Partners can [export collections](/docs/getting-started/importing-and-exporting/exporting-data/#export-collections). They can also [fork collections](/docs/collaborating-in-postman/using-version-control/forking-elements/) within the same Partner Workspace or to another Partner Workspace within the same team. They can't fork collections outside the team. - **Viewer** - Partners can [fork collections](/docs/collaborating-in-postman/using-version-control/forking-elements/) to another Partner Workspace within the same team where they're assigned the Workspace Editor role. They can't fork elements outside the team. Also, they can't export collections. To learn more about collaborating as a team member or partner, see [Collaborate in a Partner Workspace](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/collaborate/). ## Element-based roles At the [element](/docs/getting-started/basics/postman-elements/) level, you can assign roles to team members that decide their level of access to the following elements: - [Collections](#collection-roles) - [APIs](#api-roles) - [Environments](#environment-roles) - [Mock servers](#mock-server-roles) - [Monitors](#monitor-roles) ## Collection roles You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) two role types in Postman collections: **Editor** and **Viewer**. - **Editor** - Can edit collections directly - **Viewer** - Can view, fork, and export collections Partners have different permissions for Collection Editor and Viewer roles in Partner Workspaces ([Enterprise plans only](https://www.postman.com/pricing/)). To learn more, see [Partner team and Partner Workspace roles](#partner-team-and-partner-workspace-roles). You can assign a limited Viewer role to a coworker who isn't in your Postman team by [allowing them to view specific collections](/docs/collaborating-in-postman/sharing/#share-collections-with-guests). Users with this role can only view specific collections and send requests in the collections that have been shared with them. The following roles control access at a collection level: | Collections | Editor | Viewer | | --- | --- | --- | | Edit, delete, and restore collections |    |    | | View deleted collections |    |    | | Manage roles on collections |    |    | | Export collections |    |    | | Fork collections |    |    | | Merge forks on collections |    |    | | Publish collection documentation and add to API Network |    |    | | Share collection variables |    |    | | Share collections to a different workspace |    |    | | Tag collections |    |    | | Add, edit, and delete mock servers |    |    | ## API roles You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) three role types in Postman APIs: **Admin**, **Editor**, and **Viewer**. - **Admin** - Can publish, move, and delete APIs - **Editor** - Can edit APIs and API definitions - **Viewer** - Can view published API versions If you have the [Workspace Admin](/docs/administration/roles-and-permissions/#workspace-roles) role, you will automatically inherit Admin permissions for all APIs in the workspace, even if you are assigned the Editor or Viewer role for an API. The following roles control access at an API level: | APIs | Admin | Editor | Viewer | | --- | --- | --- | --- | | Edit APIs and API definitions |    |    |    | | Publish APIs |    |    |    | | Move and delete APIs |    |    |    | | Manage roles on APIs |    |    |    | | Comment on APIs |    |    |    | | Comment on published API versions |    |    |    | | Share APIs |    |    |    | | Generate collections from the API definition |    |    |    | | Add and remove API documentation collections |    |    |    | | Add and remove API test collections |    |    |    | | Add and remove CI integrations |    |    |    | | Add and remove APM integrations |    |    |    | | Add and remove API gateway integrations |    |    |    | | View reports for APIs |    |    |    | API Editors can assign users the Viewer or Editor role. API Editors can't assign a user the Admin role, or change an Admin to an Editor or Viewer. ## Environment roles You can [assign](/docs/sending-requests/variables/team-environments/#share-an-environment) two role types for Postman environments: **Editor** and **Viewer**. - **Editor** - Can edit and manage environments - **Viewer** - Can view and use environments The following roles control access at an environment level: | Environment | Editor | Viewer | | --- | --- | --- | | View environment |    |    | | Use environment |    |    | | Edit environment variables |    |    | | Share environment variables |    |    | | Edit and delete environments |    |    | | Manage environment roles |    |    | ## Mock server roles You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) two role types for Postman mock servers: **Editor** and **Viewer**. - **Editor** - Can edit and manage mock servers - **Viewer** - Can view mock servers and associated metadata The following roles control access at the mock server level: | Mock server | Editor | Viewer | | --- | --- | --- | | View mock server |    |    | | View mock server call logs and call log details |    |    | | View mock server metadata |    |    | | Edit and delete mock servers |    |    | | Manage mock server roles |    |    | ## Monitor roles You can [assign](/docs/administration/managing-your-team/team-members/manage-roles/#manage-element-based-roles) two role types for Postman Monitors: **Editor** and **Viewer**. - **Editor** - Can view monitor metadata, metrics, jobs, and runs. Can also run, update, delete, pause, and resume the monitor. - **Viewer** - Can view monitor metadata, metrics, jobs, and runs. Monitors | Editor | Viewer | | --- | --- | --- | | View monitor |    |    | | View monitor metadata, results, activity, and summary metrics |    |    | | Create monitor read integrations |    |    | | View monitor based integrations |    |    | | Edit and delete monitor |    |    | | Run, pause, and resume monitor |    |    | | Update monitor roles |    |    | --- # Assign input values with scenarios _SCenarios_ are sets of values assigned to [**Start**](/docs/postman-flows/reference/blocks/start/) block inputs. You can define multiple scenarios with different values for inputs, and change between scenarios for different use cases. For example, scenarios are convenient when you're testing flow modules or actions that require the same inputs but different values for each test. They're also useful when you want to use different input values for a beta or production deployment. ## Start block inputs You can [add inputs to the **Start** block](/docs/postman-flows/reference/blocks/start/#receive-data-with-inputs) to receive data from a scenario. The **Start** block can then pass that data to other blocks as key-value pairs. The key is the input's name and the value is any data received by the input. ## Create a scenario When you add inputs to the **Start** block, you can assign them values with a scenario. Your flow module or action will then use the scenario's values when it runs. To create a scenario, do the following: 1. Create a new flow [module](/docs/postman-flows/get-started/build-your-first-flow/) or [action](/docs/postman-flows/build-flows/structure/actions/#create-an-action). 2. If you created a flow module, [add one or more inputs to your **Start** block.](/docs/postman-flows/reference/blocks/start/#receive-data-with-inputs) 3. In the right sidebar, click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios** \u003e **Create scenario**. The scenario editor appears with editable fields for each input in the **Start** block. 4. Enter data for each input field. 5. Click **Save**. ## Run a flow module or action using scenario data Once you've created a scenario, you can run the flow module or action using the scenario's data as values assigned to the **Start** block's inputs. To run a flow module or action using a scenario's data, do the following: 1. Click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios**. 2. Hover over the scenario you want to use and click **Run**. The flow runs using data defined in the scenario. ## Secrets in scenarios When adding inputs to the [**Start** block](/docs/postman-flows/reference/blocks/start/), you can designate an input as \u003cimg alt=\"Locked icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/state-locked-stroke.svg#icon\" width=\"16px\"\u003e **Secret** provided its value will be a string. Postman encrypts the values of **Secret** inputs and stores them securely, giving you a safe way to handle API keys or other sensitive values in your modules. Postman redacts them in run logs, **Output** blocks, and the Console, even when used in nested modules. When you clone a module that has a secret input, the input appears in the **Start** block and scenarios pane, but its value is left blank and is never present in the clone. In the Scenarios pane, inputs designated as \u003cimg alt=\"Locked icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/state-locked-stroke.svg#icon\" width=\"16px\"\u003e **Secret** in the **Start** block: * Also have type \u003cimg alt=\"Locked icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/state-locked-stroke.svg#icon\" width=\"16px\"\u003e **Secret**. * Are shown with their values masked by default. What you can do with secret inputs depends on your permissions: * Flow Editors can unmask secret inputs by clicking \u003cimg alt=\"View icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon\" width=\"16px\"\u003e **Show**. They can create, edit, and save secret input values. * Runners can run modules with secret inputs, but can't view their values. At runtime, Postman decrypts secret values if needed, without making them visible. * Viewers can't run modules with secret inputs, and can't view the values of secret inputs. ## Edit a scenario You can change and save the values in a scenario. To edit a scenario, do the following: 1. Click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios**. 2. Hover over the scenario you want to edit and click **Edit**. 3. Enter new values in the input fields. 4. Click **Save**. ## Rename a scenario You can change a scenario's name. To rename a scenario, do the following: 1. Click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios**. 2. Hover over the scenario you want to delete and click \u003cimg alt=\"Options icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon\" width=\"16px\"\u003e the more actions icon \u003e **Rename**. 3. Enter a new name. 4. Press the **Return** or **Enter** key. ## Duplicate a scenario You can make a copy of an existing scenario. To duplicate a scenario, do the following: 1. Click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios**. 2. Hover over the scenario you want to delete and click \u003cimg alt=\"Options icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon\" width=\"16px\"\u003e the more actions icon \u003e **Duplicate**. 3. Click **Save**. ## Delete a scenario To delete a scenario, do the following: 1. Click \u003cimg alt=\"Scenarios\" src=\"https://assets.postman.com/postman-docs/v11/flows-scenarios-icon-v11.png#icon\" width=\"16px\"\u003e **Scenarios**. 2. Hover over the scenario you want to delete and click \u003cimg alt=\"Options icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon\" width=\"16px\"\u003e the more actions icon \u003e **Delete**. ## Troubleshoot vault secrets Vault secrets can be empty or unresolved in your HTTP requests. An *empty vault* secret is a vault secret that doesn't have a value but is referenced in your request. An empty vault secret may or may not exist in your Postman Vault. An *unresolved vault secret* is a vault secret that exists in your Postman Vault but the value can't be accessed from your request. A vault secret in a cloud vault may be empty if the cloud vault's name was updated, but references to the vault secret use the previous cloud vault name. To fix this, update references to the vault secret with the correct cloud vault name. To learn more about troubleshooting empty and unresolved vault secrets, see [Troubleshoot vault secrets](#troubleshoot-vault-secrets). ## Use vault secrets You can reference vault secrets stored in your local vault or a cloud vault by adding the vault secret inside double curly braces (`{{ }}`) and append the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` To reference a vault in a cloud vault, do the following: 1. Open the Postman workspace where you created the vault secret. 2. Select the vault secret in the left sidebar. 3. Choose a published version of the vault secret using the version dropdown list. 4. In the left sidebar, click \u003cimg alt=\"Link icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon\" width=\"16px\" role=\"img\"\u003e **Copy** next to a vault. This copies the URL to the version of the vault secret you select in the dropdown list. 5. Add the URL to a reference (`$ref`) in your specification. ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 8. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 9. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 10. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. Postman adds a new component file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. * If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click \u003cimg alt=\"Slack icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon\" width=\"16px\"\u003e \u003cimg alt=\"Teams icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon\" width=\"16px\"\u003e **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. * Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. * This only applies to workspaces created after you set a policy. To apply the policy to existing workspaces, [update their policy](#update-secret-protection-policies). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: * [The Secret Scanner dashboard](/docs/reports/secret-scanner-reports/) --- # Automate collection runs on a schedule Instead of running collections manually, Postman can run collections for you on a schedule. Use the Collection Runner to select a collection and configure a schedule. For example, you can run a collection that tests the functionality of your API every day at a specific time. When you schedule a collection run with the Collection Runner, the scheduled run is added to the **Runs > Scheduled** tab in the collection. From here you can view, pause, edit, and delete scheduled collection runs. You can also schedule collection runs with [monitors](/docs/collections/running-collections/scheduling-collection-runs-monitors/). Schedule runs with monitors when you want to set up alerts, like triggering on-call alerts for failures. For all other use cases, such as automating API tests, schedule runs with the Collection Runner. ## About scheduled collection runs When working with scheduled collection runs, keep in mind the following: - Scheduled collections run in the Postman Cloud, not locally. - Scheduled runs don't support requests that use files in your local [working directory](/docs/getting-started/installation/settings/#working-directory) to send [body data](/docs/sending-requests/create-requests/parameters/). Instead, [upload your test data files](/docs/sending-requests/create-requests/test-data/) to make them available for scheduled runs in the cloud. - Schedules share permissions with their collections. For example, if you have permission to edit a collection, you can edit that collection's schedules. - You can schedule collection runs in personal, private, and team [workspaces](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). - If you import or export a collection, its schedules don't import or export with it. However, if you delete a collection, its schedules are also deleted. - Scheduled collection runs share the same [usage limits as monitors](/docs/monitoring-your-api/monitor-usage/). - Scheduled runs don't support OAuth 2.0 authentication. To learn how to use an OAuth 2.0 token with scheduled runs, see [OAuth 2.0 overview](/docs/sending-requests/authorization/oauth-20/#oauth-20-overview). You can run collections with scripts that import packages from your team's [Postman Package Library](/docs/tests-and-scripts/write-scripts/packages/package-library/). Learn how to [add packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#add-a-package) to the package library, and [import packages](/docs/tests-and-scripts/write-scripts/packages/package-library/#import-a-package) into your scripts. ## Schedule a collection run You can schedule a run for the requests in a [collection](/docs/collections/use-collections/create-collections/) or a [folder](/docs/collections/use-collections/manage-collections/#add-folders-to-a-collection). 1. Click **Collections** in the sidebar and select the collection or folder you want to schedule. 2. Click ![Image 1: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. 3. ![Image 2: Select Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) You can also click ![Image 3: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Runner** from the Postman footer and drag a collection from **Collections** or **History** in the sidebar. 4. On the **Functional** tab, click **Schedule runs**. ![Schedule runs](https://assets.postman.com/postman-docs/v10/schedule-runs-v10-13.jpg) 5. Choose any configuration options: - **Schedule name** - A name for your scheduled run. - **Run Frequency** - When and how often you want the collection to run. - **Environment** - (Optional) The [environment](/docs/sending-requests/variables/managing-environments/) with variables you want the collection to use. - **Iterations** - The number of times to run the collection. - **Data** - A [data file](/docs/collections/running-collections/working-with-data-files/) for the scheduled run. - **Notification recipients** - Up to five team members who will receive notifications for the scheduled run. - **Advanced settings** - **Retry if run fails** - Select this checkbox to retry a request after it fails, and enter the number of times to retry the request. Each retry counts toward your [monitoring usage](/docs/billing/resource-usage/#monitoring-usage). - **Set request timeout** - Select this checkbox to skip a request after it times out, and enter the timeout period in milliseconds. A scheduled run can't exceed a total duration of 15 minutes. - **Set delay before requests** - Select this checkbox to wait before sending requests, and enter the interval delay in milliseconds. - **Follow redirects** - Clear this checkbox to prevent requests that return a 3xx series response from automatically redirecting. - **Enable SSL validation** - Clear this checkbox to prevent Postman from checking the validity of SSL certificates when making requests. 6. By default, your requests run in the sequence they're listed in the collection. If you need to change the run order, click and drag a request to its new location in the order. You can also remove an individual request from the run by clearing the checkbox next to its name. For more information, see [Change run order](#change-run-order). 7. Click **Schedule Run**. Requests sent by scheduled collection runs are deducted from your maximum number of monitoring API calls. For more information about checking your monitor usage, see [Manage monitor usage in Postman](/docs/monitoring-your-api/monitor-usage/). ## View a scheduled run You can view the results of past scheduled runs. 1. Click **Collections** in the sidebar and select the collection with the scheduled run you want to view. 2. Select the **Runs > Scheduled** tab. 3. Hover over a scheduled run and click **View**. ![Runs tab](https://assets.postman.com/postman-docs/v11/scheduled-runs-tab-view-v11-10b.jpg) 4. Each column in the graph represents an individual run. Click a column to view test results and the Console log for that run. For more information see [View scheduled collection runs in Postman](/docs/collections/running-collections/viewing-scheduled-collection-runs/). ![Scheduled runs view results](https://assets.postman.com/postman-docs/v11/view-scheduled-run-results-v11a.jpg) ## Manually run a scheduled run When a scheduled run is triggered manually, it runs in the Postman Cloud. Running scheduled runs manually is useful when you are fixing bugs or reproducing issues. 1. Click **Collections** in the sidebar and select the collection with the scheduled run you want to run manually. 2. Select the **Runs > Scheduled** tab. 3. Hover over a scheduled run and click **View**. ![Scheduled runs tab](https://assets.postman.com/postman-docs/v11/scheduled-runs-tab-view-v11-10b.jpg) 4. Click **Run**. ## Pause or resume a scheduled run When you pause a scheduled run, Postman won't run the collection again until you resume the schedule. 1. Click **Collections** in the sidebar and select the collection with the scheduled run you want to pause or resume. 2. Select the **Runs > Scheduled** tab. 3. Hover over a scheduled run, click ![Image 10: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** and select **Pause** or **Resume**. ![Scheduled runs tab](https://assets.postman.com/postman-docs/v11/scheduled-runs-more-actions-v11-10b.jpg) ## Edit a scheduled run 1. Click **Collections** in the sidebar and select the collection with the schedule you want to edit. 2. Select the **Runs > Scheduled** tab. 3. Hover over a scheduled run, click ![Image 11: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**, and click **Edit**. ![Scheduled runs tab](https://assets.postman.com/postman-docs/v11/scheduled-runs-more-actions-v11-10b.jpg) 4. Make any changes to the scheduled run, then click **Save Changes**. ## Change run order You can send the requests in a collection in different combinations or sequences to simulate various workflows. In the Collection Runner, change the order of requests by dragging them, or clear the checkbox next to a request to skip it. When you schedule a collection run, you can change the order of your requests and save the custom order to run on a schedule. In this way, you can use the same collection to automate multiple tests scenarios. To change the request order in a scheduled run, do the following: 1. Click **Collections** in the sidebar and select the collection or folder you want to schedule. 2. Click ![Image 12: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. ![Image 13: Click Run from the collection overview](https://assets.postman.com/postman-docs/v11/collection-runner-button-v11.jpg) You can also click ![Image 14: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Runner** from the Postman footer and drag a collection from **Collections** or **History** in the sidebar. 3. On the **Functional** tab, click **Schedule runs**. ![Image 15: Schedule runs](https://assets.postman.com/postman-docs/v10/schedule-runs-v10-13.jpg) 4. Under **Run Order**, change the order by dragging and dropping requests. Skip a request by clearing its checkbox. ![Image 16: Custom run order](https://assets.postman.com/postman-docs/v11/scr-custom-order-v11.gif) 5. Click **Schedule Run**. On the **Runs > Scheduled** tab, the message **Custom run order** indicates a scheduled run uses a custom request order. If a request is added or deleted from a scheduled collection, a **Review Changes** link appears next to the scheduled run. Click the link to review and edit the changes. --- # SCIM provisioning overview > **[Provisioning with SCIM is available with Postman Enterprise plans.](https://www.postman.com/pricing/)** Postman supports [SCIM](https://datatracker.ietf.org/doc/html/rfc7642) (System for Cross-domain Identity Management), enabling you to automate user provisioning and de-provisioning for your team. With this feature, you can efficiently deploy Postman at scale across your organization and control access to it with your identity provider (IdP). You can enable SCIM provisioning with the [SCIM API](#configuring-scim-with-the-scim-api), [Okta](/docs/administration/scim-provisioning/configuring-scim-with-okta/), [Microsoft Entra ID](/docs/administration/scim-provisioning/configuring-scim-with-azure-ad/), or [OneLogin](/docs/administration/scim-provisioning/configuring-scim-with-onelogin/). You must be a [Postman Team Admin or Super Admin](/docs/administration/roles-and-permissions/#team-roles) to enable SCIM for your team. A SCIM key belonging by a Team Admin can be used to provision and de-provision users through SCIM. However, the SCIM key belonging by a Team Admin can't be used to de-provision a Super Admin. Also, account email updates only work if the SCIM key belongs to a user with the Super Admin role. To ensure complete functionality, you can assign the SCIM key to a user with the Super Admin role. Alternatively, you can create a service account and assign it the Super Admin role, avoiding the risk of service disruption in case a team member leaves the company. Learn more about [assigning the Super Admin role to a service account](/docs/administration/enterprise/enterprise-onboarding/#the-super-admin-role). With SCIM enabled, users won't have the option to leave your team on their own, and won't be able to change their account email or password. Only Team Admins and Super Admins have permission to remove team members. Only administrators in your IdP have permission to use SCIM to change user account emails if they're associated with a domain your team verified. With [domain verification](/docs/administration/domain-verification-and-capture/add-and-verify-a-domain/), you can do the following: * Onboard users faster, by not requiring the [account linking](/docs/getting-started/account/manage/#link-your-account-to-postman) step. * Update users' emails using SCIM if the user account email domain matches a domain your team verified. ## SCIM features Postman supports the following provisioning features: * **Create user** - Creates a new user account in Postman, adds the account to your organization's Postman team, and activates authentication for the user if their email ID isn't attached to an existing Postman account. If a Postman account with the same email ID exists and it's associated with a domain your team has verified, the user will be automatically added to your team. If a Postman account with the same email ID exists, and it's not associated with a verified domain, an email invite to join your Postman team is sent to the user. Once the user accepts the invite, they'll be added to your team. > The newly added user will have the Developer role in Postman by default. You can later [update account roles in Postman](/docs/administration/managing-your-team/team-members/manage-roles/). * **Update user information** * **Update user attributes** - Updates a user's first and last name in Postman. * **Activate user** - Creates a new user on your Postman team, if one doesn't already exist, and activates the user to authenticate into your Postman team. * **Deactivate user** - Removes a user from your Postman team and deactivates their account, blocking the account from authenticating into Postman. > User accounts and the data corresponding to them won't be deleted. * **Reactivate user** - Reactivates an existing deactivated user by unblocking the account's authentication into Postman and adds the account back to your Postman team. * **Create group** - Creates a new [user group](/docs/administration/managing-your-team/user-groups/) in Postman. When you assign the Postman app to a group, Postman creates a new account for each user, adds each account to your organization's Postman team, and activates authentication for each user. If an existing Postman account uses an email that matches a user's email ID, an [email invite](/docs/administration/managing-your-team/team-members/invite-members/#manage-invites) to join your Postman team is sent to that user. Once the user accepts the invite, they'll be added to your team. > Newly created groups will have the Developer role in Postman by default. You can later [update group roles in Postman](/docs/administration/managing-your-team/user-groups/#editing-team-roles-for-a-group) and [control a group's access to workspaces and individual Postman elements](/docs/administration/managing-your-team/user-groups/#managing-roles-on-workspaces-and-postman-elements), such as collections and APIs. * **Delete group** - Deletes a user group in Postman. User accounts that were part of the deleted group are deactivated in Postman. > User accounts and the data corresponding to them won't be deleted. * **Update group information** * **Update group attributes** - Updates a group's name in Postman. * **Update group members** - Adds or removes users from a group in Postman. * **Set user roles** - Use SCIM to assign roles to users by [creating a user group](/docs/administration/managing-your-team/user-groups/#creating-a-group) in Postman, then assigning roles to the group. When you add users to the group using SCIM, users will get the roles assigned to the group. Learn how to [update team roles for groups](/docs/administration/managing-your-team/user-groups/#editing-team-roles-for-a-group), and [update workspace and elements roles for groups](/docs/administration/managing-your-team/user-groups/#managing-roles-on-workspaces-and-postman-elements). Postman doesn't support the following provisioning features: * Push groups from Postman to your IdP * Push or sync password updates * Push user attribute updates from your IdP to Postman other than name * Pull user attribute updates from Postman to your IdP ## Enabling SCIM provisioning You must [configure SSO in Postman](/docs/administration/sso/admin-sso/) before you can enable SCIM for your Postman team. You can use SCIM with multiple SSO method configurations. To enable SCIM with multiple SSO, contact your customer success manager. ### Enabling SCIM in Postman 1. Open Postman and select **Team > Team Settings** in the Postman header. 2. Click **Authentication** in the left sidebar. 3. Click **Authentication Methods**. 4. Select the **SCIM Provisioning** toggle to turn it on. ![Image 1: Enable SCIM in dashboard](https://assets.postman.com/postman-docs/v10/auth-enable-scim-v10-19.jpg) 1. Click **Turn On** to enable SCIM provisioning. ![Image 2: Enable SCIM in dashboard](https://assets.postman.com/postman-docs/v10/turn-on-scim-provisioning-v10-19.jpg) ### Generating SCIM API key 1. Under **SCIM Provisioning**, click **Generate SCIM API Key**. ![Image 3: Generate SCIM API key](https://assets.postman.com/postman-docs/v10/generate-scim-api-key-v10-19.jpg) 1. Enter a key name, then click **Generate**. 1. Copy your new API key for later use and click **Done**. You can revisit this page to manage your SCIM API keys. If you regenerate an existing API key, you'll have the option to keep the previous key active while you switch to the new one. For more information or help with configuring SCIM, [contact Postman support](https://www.postman.com/support/). ## Configuring SCIM with the SCIM API Visit Postman's [SCIM API documentation](https://www.postman.com/postman/postman-public-workspace/folder/l6yozde/scim) for information on setting up SCIM for your Postman team using the SCIM 2.0 API. ## Next steps After the SCIM setup is complete, learn how to manage roles and permissions for your team: * To learn how to enable SCIM provisioning through your IdP, see [Configure SCIM with Okta](/docs/administration/scim-provisioning/configuring-scim-with-okta/), [Configure SCIM with Microsoft Entra ID](/docs/administration/scim-provisioning/configuring-scim-with-azure-ad/), or [Configure SCIM with OneLogin](/docs/administration/scim-provisioning/configuring-scim-with-onelogin/). * To learn how to enable SCIM using the SCIM 2.0 API, see Postman's [SCIM API documentation](https://www.postman.com/postman/postman-public-workspace/folder/l6yozde/scim). * Learn more about [defining roles](/docs/administration/roles-and-permissions/) in your team and how to [create user groups](/docs/administration/managing-your-team/user-groups/#creating-a-group). --- **Tip:** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 4: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 5: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 6: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 7: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 8: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. > If a social channel is already subscribed to workspace updates the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Image 9: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 10: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** To get started using Postman within your organization, you can walk through the following tasks to set your Postman team up for success. --- **Note:** If you're on a Free individual plan, create a new team to connect to a remote repository. --- **Note:** You can't delete component files. ### View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the Documentation preview, do the following: 1. Under **Documentations** in the left sidebar, click **Documentations**. 2. Click **Preview**. 3. Click **Preview** again to see the live documentation preview. ### Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. > Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. 1. Click **Documentations** in the left sidebar, then click **Components**. 2. Click **Open Component Library**. 3. Click a component file in the left sidebar. 4. Choose a published version of the component file using the version dropdown list. 5. In the left sidebar, click ![Image 11: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 6. Add the URL to a reference (`$ref`) in your specification. > From a specification, you can also copy the URL to the latest version of a component. Click ![Image 12: Library icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-library-stroke.svg#icon) **Components** in the lower right of the specification. Then hover over a component and click ![Image 13: Link icon](https://assets.postman.com/postman-docs/aether-icons/action-link-stroke.svg#icon) **Copy link**. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) and select it from the suggestions list. The URL to the latest version is added as the value. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip:** To get started using Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 14: The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. * Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 15: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Image 16: Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 17: Set default policy for new workspaces](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 18: Set default policy for new workspaces](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 19: Set default policy for new workspaces](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 20: Set default policy for new workspaces](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use the **Search workspaces** text box to search for and select workspaces, or use the **Created by** dropdown list to filter by specific users. You can also use the **Type** dropdown list to filter workspaces by their [visibility](/docs/collaborating-in-postman/using-workspaces/overview/#workspace-types): * **Public** - [Public](/docs/collaborating-in-postman/using-workspaces/public-workspaces/) workspaces are visible to everyone in the Postman community. * **Partner** - Only invited team users and partners have access to [Partner Workspaces](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/overview/). * **Internal** - [Internal](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/overview/) workspaces are visible to only you or your team. ![Image 21: Set default policy for new workspaces](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. --- **Tip:** To get started with Postman in VS Code, choose the supported application where you'd like to install the Postman VS Code extension. --- **Note:** You can't delete published versions of component files. ### Set default policy for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific --- # secret-scanner-dashboard The Secret Scanner dashboard is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner dashboard, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can view secrets the Secret Scanner detects in your team's public workspaces. You can [resolve detected secrets](#resolve-detected-secrets) to let your team know if the secret is revoked, a false positive, or not relevant. You can also [change the status of a resolved secret](#change-the-status-of-resolved-detected-secrets). Admins can [subscribe to summary emails](#secret-scanner-summary-emails) to stay informed on detected secrets. For Enterprise plans with the [Advanced Security Administration add-on](/docs/administration/managing-your-team/secret-scanner/how-secret-scanner-works/#advanced-security-administration-add-on), Secret Scanner also scans internal workspaces and Partner Workspaces and delivers results in the dashboard. To open the dashboard, select **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. ![Secret Scanner dashboard](https://assets.postman.com/postman-docs/v11/secret-scanner-dashboard-v11-21.jpg) ## Resolve detected secrets [Team Admins and Super Admins](/docs/administration/roles-and-permissions/#team-roles) can review the [default](/docs/administration/managing-your-team/secret-scanner/secret-scanner-patterns#default-patterns) and [custom](/docs/administration/managing-your-team/secret-scanner/secret-scanner-patterns#custom-patterns) secrets that the Secret Scanner has found in the **Secrets detected** tab of the [Secret Scanner dashboard](https://go.postman.co/settings/team/secret-scanner/findings). From the **Unresolved** tab, you can resolve detected secrets in bulk, or you can select a detected secret to view details and resolve it. Filter findings by visibility type, workspace name, and secret type. Admins and Super Admins can access all identified secrets within a team, including ones in public workspaces. Workspace Admins can also view secrets within the workspaces they manage. Partner Managers can manage and resolve secrets detected in Partner Workspaces. To resolve detected secrets in bulk with the same status, select the checkbox next to each detected secret. You can also select the checkbox next to **Secrets** to select all detected secrets on the page. Click **Resolve** and then select a status to resolve the secrets. ![Bulk resolve detected secrets](https://assets.postman.com/postman-docs/v11/secret-scanner-bulk-resolve-detected-secrets-v11-21.jpg) You can also select a detected secret to view more details and resolve it. Each detected secret shows where it was found and when it was detected. To view the SHA256 hash value of a detected secret, hover over the masked value and click ![Image 3: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) **Secret Details**. To resolve the secret, click **Unresolved** and then select a status. You can resolve a detected secret with the following statuses: * **Revoked** - This secret has been revoked. * **False positive** - This secret isn't valid. * **Won't fix** - This secret isn't relevant. ## Change the status of resolved detected secrets After you [resolve a detected secret](#resolve-detected-secrets), Team and Super Admins can change the status of a resolved secret. From the **Resolved** tab, you can change the status of resolved secrets in bulk, or you can select a resolved secret to view details and change its status. You can also unresolve a secret if Team and Super Admins need to review it again. Filter findings by visibility type, workspace name, secret type, and status type. To change resolved detected secrets to the same status in bulk, select the checkbox next to each resolved detected secret. You can also select the checkbox next to **Secrets** to select all resolved detected secrets on the page. Click **Change Status** and then select a different status to resolve the secrets. You can also click a resolved detected secret to view more details and change its status. Each detected secret shows where it was found and when it was detected. To view the SHA256 hash value of a detected secret, hover over the masked value and click ![Image 5: Info icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon) **Secret Details**. To change the resolved secret's status, click the status and then select a different status. ![Change status of detected secret](https://assets.postman.com/postman-docs/v11/secret-scanner-change-detected-secret-v11-20.jpg) You can select **Unresolved** instead of changing the status for a detected secret. This moves it back to the **Unresolved** tab, where Team and Super Admins can review and resolve the secret again. ## Secret Scanner summary emails Team Admins, Super Admins, and Workspace Admins can stay informed about Secret Scanner findings by subscribing to daily, weekly, or monthly summary emails. You'll receive the following based on your selections: * A daily summary email every day at 12:00 AM UTC. * A monthly summary email on the first of every month. * A weekly summary email every Monday. Navigate to [Notification preferences](https://go.postman.co/settings/me/notifications) or click your avatar in the Postman header, then select **Settings > Notifications** to view the Secret Scanner summary options. From there, you can select the box for either daily, weekly, monthly, or all summaries, and save your preferences. --- # Send information from one system to another using Postman Flows Developers often integrate multiple APIs to leverage their individual features. For example, you can get customer profiles from a payment services provider like [Stripe](http://www.stripe.com) and add those profiles as contacts on a marketing platform like [Brevo](http://www.brevo.com). This tutorial shows you how to do this with Postman Flows. ## Goal Create a flow that gets a list of customer profiles from [Stripe](http://www.stripe.com) and adds them as contacts to a database in [Brevo](http://www.brevo.com). ## Prerequisites * A [Stripe](http://www.stripe.com) account and API key. * At least 15 Stripe customers. * A [Brevo](http://www.brevo.com) account and API key. ## Create the flow, collections, and environment 1. Open the [**Integration Flows** public workspace](https://www.postman.com/postman/integration-flows/flows-get-started) and [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) the **Brevo API** collection, the **Stripe API** collection, and the **Stripe + Brevo** environment to your workspace. 1. In your workspace, [open the Stripe + Brevo environment](/docs/sending-requests/variables/managing-environments/#edit-an-environment). 1. [Replace](/docs/sending-requests/variables/environment-variables/#edit-environment-variables) the **stripe\_secret\_key** variable's value, **your key here**, with your Stripe API key. 1. [Create a new flow module](/docs/postman-flows/get-started/build-your-first-flow/) and click **Send a request**. ## Set up the initial Stripe request 1. Click **Find or create new request** and select **Stripe API > Customers > List all customers**. 1. Click **Add environment** and select **Stripe + Brevo**. The **HTTP Request** block shows the request's three variables. The `baseUrl` and `stripe_secret_key` variables are populated automatically from values stored in the request's collection and environment. 1. Next to the **limit** variable, click \[![Image 1: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon)\] **Add data blocks** and select **Number**. Enter "5" to specify how many contacts to include in each page of results. This tutorial uses 15 contacts, so a limit of 5 will send three pages of results. \[![Image 2: Create a new flow](https://assets.postman.com/postman-docs/v10/flows-tut-system-first-sr-v10.png)\] 1. Add pagination logic: 1. Connect the **HTTP Request** block's **Success** output to a **Select** block. 1. Click **Enter path** and enter "body.has_more". \[![Image 3: Select body.has_more](https://assets.postman.com/postman-docs/v10/flows-tut-select-has_more-v10.png)\] 1. Connect the **HTTP Request** block's **Success** output to another **Select** block. 1. Click **Enter path** and enter "body.data". \[![Image 4: Select body.data](https://assets.postman.com/postman-docs/v10/flows-tut-select-data-v10.png)\] 1. Connect the `has_more` **Select** block's output to an **If** block's **variable** input and rename `value1` to `has_more`. 1. Click **Start writing TypeScript** and enter "has_more". 1. Connect the `body.data` **Select** block's output to the **If** block's **Data** input. \[![Image 5: Add an If block](https://assets.postman.com/postman-docs/v10/flows-tut-if-has_more-v10.png)\] 1. Connect an **Evaluate** block's **variable** input to the **If** block's **THEN** output. Rename `value1` to `contacts`. 1. Click **Start writing TypeScript** and enter "contacts[$count(`contacts`)-1].id". This gets the ID of the last object when there is at least one more contact in the original response. \[![Image 6: Add an Evaluate block](https://assets.postman.com/postman-docs/v10/flows-tut-eval-contacts-v10.png)\] ## Add a paginated request 1. Connect an **HTTP Request** block to the **Evaluate** block's **Result** output. 1. Click **Find or create new request** and select **Stripe API > Customers > List all customers pagination**. The block automatically selects the **Stripe + Brevo** environment. 1. Next to the **limit** variable, click \[![Image 7: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon)\] **Add data blocks** and select **Number**. Enter "5" to specify how many contacts to include in each page of results. 1. Connect the **Evaluate** block's **Result** output to the `starting_after` variable in the **HTTP Request** block. 1. Connect the **HTTP Request** block's **Success** output to both the `body.has_next` and the `body.data` **Select** blocks' inputs. \[![Image 8: Add another HTTP Request block](https://assets.postman.com/postman-docs/v10/flows-tut-send-request-pagination-v10.png)\] ## Add a loop to send contacts to Brevo 1. Connect the **If** block's **THEN** and **ELSE** outputs to a **For** block's **List** input. 1. Connect the **For** block's **Item** output to an **HTTP Request** block. \[![Image 9: Add a For block](https://assets.postman.com/postman-docs/v10/flows-tut-if-for-send-v10.png)\] 1. In the **HTTP Request** block, click **Find or create new request** and select **Brevo API > Contact management > Contacts > POST Create a contact**. Click **Add environment** and select **Stripe + Brevo**. \[![Image 10: Select the POST request](https://assets.postman.com/postman-docs/v10/flows-tut-post-contact-v10.png)\] 1. Connect the **For** block's **Item** output to the `email` and `first_name` variables' inputs. Enter "name" for the `first_name` variable and "email" for the `email` variable. \[![Image 11: Set variables](https://assets.postman.com/postman-docs/v10/flows-tut-email-name-v10.png)\] ## Run and verify the flow Run the flow and confirm the records are added to Brevo. ![Image 12: Postmanaut illustration for Postman Flows section.](https://voyager.postman.com/illustration/flows-postman-illustration.svg) --- # Send a request with the HTTP Request block You can build a flow that uses a request from your workspace or the [Postman API Network](/docs/collaborating-in-postman/public-api-network/public-api-network-overview/). You can also create a new request when building your flow. In this tutorial, you’ll create a new flow, collection, and request. Then, you’ll use the **HTTP Request** block to send a request to the [Postman Echo API](/docs/developer/echo-api/). ## Create a new flow You build flows in a workspace. Workspaces let you organize your API projects and collaborate with your team. To create a new flow, do the following: 1. Choose an existing workspace or [create a new one](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). 1. In the upper left corner, click **New** > ![Image 1: Flow icon](https://assets.postman.com/postman-docs/aether-icons/entity-flow-stroke.svg#icon) **Flow**. ## Add an HTTP Request block and create a request With an **HTTP Request** block, you can select a request from your collection or create a new request. In this tutorial, you’ll create a new request with the **HTTP Request** block. To add an **HTTP Request** block and create a new request, do the following: 1. From the Postman sidebar, click ![Image 2: Flow icon](https://assets.postman.com/postman-docs/aether-icons/entity-flow-stroke.svg#icon) **Flows**. 1. Select your new flow. 1. Click ![Image 3: HTTP Request icon](https://assets.postman.com/postman-docs/aether-icons/entity-httpRequest-stroke.svg#icon) **Send a request**. ![Image 4: Send a request](https://assets.postman.com/postman-docs/v11/flows-select-send-request-v11-60.png) 1. Click **Find or create new request**. The collections in your workspace appear in a dropdown list. 1. Select a collection and click **Create a new request**. If you don’t have any collections, click **Create a new request**. The Postman Flows request editor opens. ![Image 5: Postman Flows request editor](https://assets.postman.com/postman-docs/v11/flows-request-editor-v11-69.png) 1. In the request editor, select a method from the dropdown list and enter a URL. 1. (Optional) Edit the request’s name. 1. (Optional) Edit the request’s parameters, headers, and body. 1. Click **Save**. ![Image 6: Display request](https://assets.postman.com/postman-docs/v11/flows-requests-icon-v11.png#icon) To edit a request in an existing **HTTP Request** block, click ![Image 7: Requests icon](https://assets.postman.com/postman-docs/v11/flows-requests-icon-v11.png#icon) **Requests** in the right sidebar, then select the **HTTP Request** block whose request you want to edit. ## Connect a Display block When you connect two blocks, you connect one block's input to another block's output. Inputs are on the block's left side and outputs are on its right side. The **Display** block shows incoming data, such as the **HTTP Request** block's outgoing API response. To connect a **Display** block, do the following: 1. Hover over the **HTTP Request** block's **Success** output port. The pointer changes to a crosshair. 1. Decide where on the canvas you want to place the **Display** block and drag the port to that location. 1. Click ![Image 8: Output icon](https://assets.postman.com/postman-docs/aether-icons/action-output-stroke.svg#icon) **Display**. If you want to search for the block, enter **Display** in search. ## Run the flow From the canvas toolbar, click ![Image 9: Run icon](https://assets.postman.com/postman-docs/aether-icons/action-run-stroke.svg#icon) **Run**. ![Image 10: Send a request flow](https://assets.postman.com/postman-docs/v11/postman-flows-simple-request-v11-60.png) Congratulations! You sent a request and displayed the response in a **Display** block. --- # Send your first API request Postman's API client enables you to create and send API [requests](/docs/getting-started/basics/postman-elements/#requests), including HTTP, GraphQL, and gRPC requests. Using Postman, you can send a request to an endpoint, retrieve data from a data source, or test an API's functionality. You don't need to enter commands in a terminal or write any code. When you create a new request and click **Send**, the API response returns directly in Postman. ## Send an API request Make sure you've [downloaded and installed the Postman desktop app](/docs/getting-started/first-steps/get-postman/). When you're ready, open the Postman desktop app and send your first API request. 1. Click ![Image 1: Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add** in the workbench to open a new [tab](/docs/getting-started/basics/navigating-postman/#tabs). 2. Enter "postman-echo.com/get" for the request URL. 3. Click **Send**. Postman displays the response data sent from the server in the lower pane. ![Image 2: Sending a request](https://assets.postman.com/postman-docs/v11/send-first-request-v11-71-7.jpg) ## How it works In this example, Postman acts as the client application and communicates with an API server. Here's what happened when you clicked **Send**: 1. Postman sent a GET request to the [Postman Echo API](/docs/developer/echo-api/) server located at `postman-echo.com`. 2. The API server received the request, processed it, and returned a response to Postman. 3. Postman received the response and displayed it in the **Response** pane. You used Postman to send an API request and got a response from the API server. ## Next steps You've sent your first API request, and you're ready to do more with Postman! * Send more requests to the Postman Echo API, a handy tool you can use to test API requests in Postman. To learn more about using the Echo API, see the [Postman Echo API documentation](/docs/developer/echo-api/). * When you're ready to learn more about building and sending requests in Postman, see [Create and send API requests in Postman](/docs/sending-requests/create-requests/create-requests/). ## Troubleshoot vault secrets You can reference vault secrets stored in your Postman Vault by adding the vault secret inside double curly braces (`{{vault:secret-name}}`) and appending the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key", use the following syntax: ```txt {{vault:postman-api-key}} ``` To reference a vault secret in your local vault or a cloud vault, put the vault secret inside double curly braces (`{{vault:secret-name}}`) and append the prefix `vault:` to the vault secret's name. For example, to reference a vault secret named "postman-api-key" in a cloud vault named "postman_engineering", use the following syntax: ```txt {{vault:postman_engineering/postman-api-key}} ``` To learn more about troubleshooting empty and unresolved vault secrets, see [Troubleshoot vault secrets](/docs/sending-requests/postman-vault/troubleshoot-vault-secrets/). ## Postman Vault integrations Integrate your Azure API Gateway with Postman Collections and streamline your testing workflow. The Azure API Gateway app enables developers to troubleshoot and reproduce issues in deployed environments. ## Import APIs from Azure API Gateway to Postman Before you get started with creating a collection from an imported API, connect your Azure API Gateway to Postman. You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. To learn more, see [Connect your Azure API Gateway to Postman](#connect-your-azure-api-gateway-to-postman). ## Create collections in Postman from Azure Gateway APIs Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To learn more, see [Create a collection from an imported API](#create-a-collection-from-an-imported-api). ## Connect your Azure API Gateway to Postman Once connected to the Azure API Gateway, any one of the available APIs can be automatically imported, along with the environment and the associated environment variables. To connect your Azure API Gateway to Postman, do the following: 1. In Postman, select **Team > Team Settings**. 2. Click **Installed apps**. 3. Select the Azure Gateway app and click **Install**. A popup window displays, click **Allow**. 4. Enter the following information to authorize installation of the app: * Azure Tenant ID * Azure Client ID * Azure Client Secret * Azure Subscription ID 5. Click **Next**. The new installed app appears on the Installed apps page with the status as **Connected**. ## Create a collection from the Azure API Gateway app You can select an API to troubleshoot or test, and create a collection from the information available in the API gateway. Collections created using the API gateway app contain the latest data from the deployed environment. This lets you keep collaborative workspaces up to date by bringing runtime API information to a collection. To create a collection from an imported API, do the following: 1. After setting up the connection, you can create a new collection. 2. Click **Collections**, then select **Create from Azure**. 3. In the **Create a new collection from API gateway** popup window, enter the following information: * Select an API from the gateway. * Select the stage on which the API is deployed. * Create an environment (optional). This creates a new environment on Postman for the API variables from the gateway. 4. Click **Create collection**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/organization/roles/#edit-workspace-details). ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click ![Image 3: Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Secret Scanner** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is to use the **No policy** option and store detected secrets in the Postman cloud. Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default detection policies for workspace types You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also update the policy for workspaces to their default, which is to use the **No policy** option and store detected secrets in the Postman cloud. Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specification. To reference a component file, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. 4. In the **Create a new collection from API gateway** popup window, enter the following information: * Select an API from the gateway. * Select the stage on which the API is deployed. * Create an environment (optional). This creates a new environment on Postman for the variables associated with the selected API. 5. Click **Create collection**. In the upper right of the editor, you can beautify, wrap, copy, and search content in the component file. As you edit your specification, Postman displays autocomplete suggestions for published components in your team's component library. Enter a component name as the value of a reference (`$ref`) in your specification. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Organization settings _Postman Organizations_ streamline API collaboration, reduce clutter in teams, maintain tighter access controls, and prevent the unwanted exposure of work and secrets. Organizations enable you to replicate your internal structure by creating independent teams, each with its own set of managers and members. This setup prevents sharing sensitive information and gives each team better control over its membership. ### Create Organization teams To create an Organization Team, do the following: 1. Access ![Image 4: Organization settings](https://assets.postman.com/postman-docs/v11/organization-settings-v11.67.png) 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. ![Image 5: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don’t necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 1. Populate the team with the members who are responsible for the team’s contents. 2. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 3. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 4. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 5. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/administration/organization/roles/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click ![Image 6: Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Image 7: Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization settings](/docs/administration/organization/settings/) * [Team roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * [Organization settings](/docs/administration/organization/settings/) * --- # Set up a Postman mock server Create _mock servers_ in Postman to help with API development and testing. A mock server simulates a real API server by accepting requests and returning responses. By configuring a mock server for your [collection](/docs/sending-requests/create-requests/intro-to-collections/) and adding [examples](/docs/sending-requests/response-data/examples/) to your requests, you can simulate the behavior of a real API. When you send a request to a mock server, Postman matches the request to a saved example in your collection. Postman then responds with the data in the example. To view existing mock servers in your workspace, click **Mock servers** in the sidebar. Mock servers can be private or public. Private mock servers require a Postman API key in the request header. Public mock servers can receive requests from anyone and anywhere (such as a browser, application code, or a curl command). New mock servers are public by default. [Super Admins and Team Admins](/docs/administration/roles-and-permissions/#team-roles) can enable or prohibit users from creating public mock servers. See [Manage mock server privacy](/docs/administration/managing-your-team/manage-team-workspaces/#manage-mock-server-privacy) to learn more. Postman mock servers only support HTTP collections. You can't use mock servers with multi-protocol collections. ## Create mock servers You can create a mock server in the following ways: 1. Create a [new mock server](#create-a-mock-server) from scratch. 2. Create a mock server from an [API call](#create-a-mock-server-from-an-api-call). 3. Create a mock server from [your request history](#create-a-mock-server-from-history). ### Create a mock server 1. Click **Mock servers** in the sidebar, then click **Create mock server**. You can also click **View more actions** next to the collection you want to mock and select **More > Mock**. ![Image 1: Create Postman Mock Server](https://assets.postman.com/postman-docs/v11/mock-server-create-v11.png) 2. Select an existing collection from the dropdown list. Or you can choose **Create a new collection**, then add requests in the **Add requests** section. 3. Configure your [mock server details](#configure-mock-server-details). ### Create a mock server from an API call 1. In Postman, send an HTTP request to an API (for example, `https://postman-echo.com/get`). 2. Click **Save** and save the request to a collection. 3. In the response pane, click **Save Response**. Postman automatically populates the example with the response you received when you sent the request. 4. Click **Collections** in the sidebar. Click **View more actions** next to the collection where the request was saved and select **More > Mock**. 5. Give your mock a name and leave the other settings at their defaults. Click **Create Mock Server**. 6. Click **Copy URL** to copy the mock URL, then go back to your request. Replace the base part of the URL with the mock server URL (everything before the path, for example, up to `/get`). 7. Add your [Postman API key](/docs/developer/postman-api/authentication/#generate-a-postman-api-key) to the request as an `x-api-key` header in the **Headers** tab. 8. Click **Send**. Postman returns the example response you saved for the request, this time from the mock server. 9. Open the example and change the response, then save the example and send the request again. Postman returns your edited mock response. ### Create a mock server from history You can build a collection and mock server based on requests from your Postman history. 1. Click **History** in the sidebar. 2. Click **View more actions** next to a request and select **Mock Request**. You can also mock all requests for a specific date. Postman creates a new collection for the mocked request or requests. 3. [Configure](#configure-mock-server-details) the mock server's details. Enter a server name, (optionally) select an environment, choose whether to enable **Make this mock server private** and **Save the mock server URL as an environment variable**, and select a response delay or enter a custom delay. 4. Click **Create Mock Server**. ## Configure mock server details Some configuration options may be different, depending on the method you used to [create the mock server](#create-mock-servers). 1. To finish creating a mock server, specify the following details: * **Mock Server Name** - Enter a name for your mock server. * **Collection** - The collection used for the mock server. To choose a different collection, click **Back**. * **Environment** - (Optional) Select an [environment](/docs/sending-requests/variables/managing-environments/) to use environment variables with your mock server. * **Simulate a fixed network delay** - Select a response delay or enter a custom delay. The mock server waits the specified time before sending the response. * **Save the mock server URL as a new environment variable** - Select this option to save the mock server URL as a variable in a new environment. You can then reference the variable in your requests. Learn more about [using variables with mock servers](/docs/design-apis/mock-apis/create-dynamic-responses/#use-postman-variables-with-mock-servers). * **Make mock server private** - Select this option to make your mock server private. You must specify an API key in the request header when sending requests to a private mock server. Learn more about [making calls to a private mock server](/docs/design-apis/mock-apis/mock-server-calls/#make-calls-to-a-private-mock-server). If the **Make mock server private** option is unavailable, it may be turned off in [Team resources](http://go.postman.co/settings/team/team-resources). A [Team Admin or Super Admin](/docs/administration/roles-and-permissions/#team-roles) can turn it back on. 2. Click **Create Mock Server**. Postman displays the details you need to use the mock server. You can get these details at any time by clicking **Mock servers** in the sidebar and selecting the mock server. ![Image 2: Configuring mock server details](https://assets.postman.com/postman-docs/v11/mock-server-configure-details-v11-20.png) 3. Click **Copy URL** to begin [making calls to your mock server](/docs/design-apis/mock-apis/mock-server-calls/). ### Edit the mock server configuration You can change the configuration for a mock server at any time. 1. Click **Mock servers** in the sidebar. 2. Select a mock server and click **Edit Configuration**. ![Image 3: Editing mock server configuration](https://assets.postman.com/postman-docs/v11/mock-server-edit-configuration-v11-8.jpg) 3. Make any changes to the mock server configuration. You can change the mock server's name, environment, network delay, and privacy setting. You can also [specify options for response matching](#match-request-body-and-headers). You can't change the mock server's collection. If you need to mock a different collection, [create a new mock server](#create-mock-servers). 4. When you are done making configuration changes, click **Update Mock Server**. ### Match request body and headers When you send a request to the mock server, Postman uses a [matching algorithm](/docs/design-apis/mock-apis/matching-algorithm/#6-check-for-header-and-body-matching) to decide which example to return in a response. By default, the matching algorithm doesn't consider the request's body or headers when selecting the best response to return. You can change this behavior in the mock server's configuration. Using body or header matching, you can specify the exact response you want the mock server to return by matching the body or headers of the saved example. If you enable request body matching, you must add the `Content-Type` header to your examples and use the same value as your request, such as `application/json`. To use body or header matching with a mock server, do the following: 1. Click **Mock servers** in the sidebar, select a mock server, and click **Edit Configuration**. 2. Under **Response Matching**, select the matching options you want to use: * **Request body** - The mock server matches the request's body to the body of the saved examples. * **Headers** - The mock server matches the request's headers to the headers of the saved examples. In the box, add a comma-separated list of the header keys that you want the mock server to match. Header matching isn't case-sensitive. 3. Click **Update Mock Server**. ### Delete a mock server To delete a mock server, click **Mock servers** in the sidebar. Click **View more actions** next to the mock server's name and click **Delete**. ## Next steps To learn more about mock servers, see the following resources: * [Make calls to your mock server](/docs/design-apis/mock-apis/mock-server-calls/) * [Mock APIs with response examples](/docs/design-apis/mock-apis/tutorials/mock-with-examples/) * [Create and use a mock server using the Postman API](/docs/design-apis/mock-apis/tutorials/mock-with-api/) * [How a Postman mock server matches requests to saved examples](/docs/design-apis/mock-apis/matching-algorithm/) --- # Set up the Postman MCP Server The Postman MCP Server supports both [remote servers](#remote-server) through streamable HTTP and [local servers](#local-server) with STDIO. The remote server is available at `https://mcp.postman.com/` and `https://mcp.eu.postman.com` for the EU, and the local server is available in the [Postman MCP Server GitHub repository](https://github.com/postmanlabs/postman-mcp-server). You can also fork the Postman MCP collection from the Postman Public Workspace: [![Fork the Postman MCP Server](https://run.pstmn.io/button.svg)](https://god.gw.postman.com/run-collection/681dc649440b35935978b8b7?action=collection%2Ffork&source=rip_markdown&collection-url=entityId%3D681dc649440b35935978b8b7%26entityType%3DextensibleCollection%26workspaceId%3D405e0480-49cf-463b-8052-6c0d05a8e8f3) Postman also offers servers as an [npm package](https://www.npmjs.com/package/@postman/postman-mcp-server) and as a [Docker image](#install-in-docker). ## Before getting started, ensure that you have a valid [Postman API key](https://postman.postman.co/settings/me/api-keys). ## Remote server The remote Postman MCP server offers the following tool configurations through streamable HTTP: * **Minimal** - (Default) This mode only includes essential tools for basic Postman operations, available at `https://mcp.postman.com/minimal` and `https://mcp.eu.postman.com/minimal` for EU users. * **Code** - Includes tools for searching public and internal API definitions and generating client code, available at `https://mcp.postman.com/code` and `https://mcp.eu.postman.com/code` for EU users. * **Full** - Includes all available Postman API tools (100+ tools), available at `https://mcp.postman.com/mcp` and `https://mcp.eu.postman.com/mcp` for EU users. ### Install in Cursor Click the button to install the remote Postman MCP Server in Cursor: [![Install the remote Postman MCP Server](https://cursor.com/deeplink/mcp-install-dark.svg)](https://cursor.com/en/install-mcp?name=postman_mcp_server&config=eyJ1cmwiOiJodHRwczovL21jcC5wb3N0bWFuLmNvbS9taW5pbWFsIiwiaGVhZGVycyI6eyJBdXRob3JpemF0aW9uIjoiQmVhcmVyIFlPVVJfQVBJX0tFWSJ9fQ%3D%3D) After installing, ensure that the Authorization header uses the `Bearer $POSTMAN-API-KEY` format. To access **Full** mode, change the `url` value to `https://mcp.postman.com/mcp` in the `mcp.json` file. To access **Code** mode, change the value to `https://mcp.postman.com/code` in this file. ### Install in Visual Studio Code To install the remote Postman MCP Server in VS Code, click the install button or use the [Postman VS Code Extension](/docs/developer/vs-code-extension/postman-mcp-server/): [![Install the remote Postman MCP Server in VS Code](https://img.shields.io/badge/VS_Code-Install_Server-0098FF?style=flat-square&logo=visualstudiocode&logoColor=white)](https://insiders.vscode.dev/redirect/mcp/install?name=postman_mcp_server&config=%7B%22type%22%3A%20%22http%22%2C%22url%22%3A%20%22https%3A%2F%2Fmcp.postman.com%2Fminimal%22%2C%22headers%22%3A%7B%22Authorization%22%3A%22Bearer%20YOUR_API_KEY%22%7D%7D) To access **Full** mode, change the `url` value to `https://mcp.postman.com/mcp` in the `mcp.json` file. To access **Code** mode, change the value to `https://mcp.postman.com/code` in this file. #### Manual installation You can use the Postman MCP Server with MCP-compatible extensions in Cursor VS Code, such as GitHub Copilot, Claude for VS Code, or other AI assistants that support MCP. To do so, add the following JSON block to the `mcp.json` configuration file: ```json { "servers": { "postman-api-http-server": { "type": "sse", "url": "https://mcp.postman.com/{minimal OR mcp}", // Use "https://mcp.postman.com/mcp" for full or "https://mcp.postman.com/minimal" for minimal mode. // For the EU server, use the "https://mcp.eu.postman.com" URL. "headers": { "Authorization": "Bearer ${input:postman-api-key}" } } }, "inputs": [ { "id": "postman-api-key", "type": "promptString", "description": "Enter your Postman API key" } ] } ``` Start the server. When prompted, enter your Postman API key. ### Install in Claude Code To install the MCP server in Claude Code, run the following command in your terminal: For **Minimal** mode: ```bash claude mcp add --transport http postman https://mcp.postman.com/minimal --header "Authorization: Bearer ${POSTMAN_API_KEY}" ``` For **Code** mode: ```bash claude mcp add --transport http postman https://mcp.postman.com/mcp --header "Authorization: Bearer ${POSTMAN_API_KEY}" ``` For **Full** mode: ```bash claude mcp add --transport http postman https://mcp.postman.com/mcp --header "Authorization: Bearer ${POSTMAN_API_KEY}" ``` ### Use as a Gemini CLI extension To install the MCP server as a Gemini CLI extension, run the following command in your terminal: ```bash gemini extensions install https://github.com/postmanlabs/postman-mcp-server ``` ### Install in Docker To use the Postman MCP Server in Docker, you can use one of the following methods: * To install the Postman MCP Server in Docker, see the [Postman MCP Server](https://hub.docker.com/mcp/server/postman/overview) at Docker MCP Hub. Click **+ Add to Docker Desktop** to automatically install it. * To run the Postman MCP Server image in Docker, run the following command in your terminal. Docker automatically discovers, downloads, and runs the Postman MCP Server image: ```bash docker run -i -e POSTMAN_API_KEY="your-secret-key" mcp/postman ``` * To build and run the server in Docker manually, run the `docker build -t postman-api-mcp-stdio .` command. Then, run one of the following commands, replacing `$YOUR-POSTMAN-API-KEY` with your Postman API key: * **Minimal** - `docker run -i -e POSTMAN_API_KEY="your-secret-key" postman-api-mcp-stdio` * **Full** - `docker run -i -e POSTMAN_API_KEY="your-secret-key" postman-api-mcp-stdio --full` ### Install in Kiro To use the Postman MCP Server in Kiro, you can use one of the following methods: To set up the Postman MCP Server with one-click, see [API Testing with Postman](https://kiro.dev/powers/) on the Kiro Powers page. Click **Add to Kiro**. To install the Postman MCP Server manually, do the following: 1. Launch Kiro and click the Kiro ghost icon in the left sidebar. 1. Add an MCP Server and select either **User Config** or **Workspace Config** to install the Postman MCP server. 1. Add the following JSON block to the `mcp.json` configuration file: ```json { "mcpServers": { "postman": { "command": "npx", "args": [ "@postman/postman-mcp-server" ], "env": { "POSTMAN_API_KEY": "postman-api-key" }, "disabled": false, "autoApprove": [ "getAuthenticatedUser" ] } } } ``` After you've completed your MCP configuration, you can return to the flow template or set up authorization for another integration in Postman. ## Local server If remote MCP servers aren't supported by your MCP host, you can install the Postman MCP Server to your local machine. STDIO is a lightweight solution that's ideal for integration with editors and tools like Visual Studio Code. Install an MCP-compatible VS Code extension, such as GitHub Copilot, Claude for VS Code, or other AI assistants that support MCP. To run the server as a Node application, install [Node.js](https://nodejs.org/) before getting started. The local server supports the following tool configurations: * **Minimal** - (Default) Only includes essential tools for basic Postman operations. * **Code** - Includes tools for searching public and internal API definitions and generating client code. * **Full** - Includes all available Postman API tools (100+ tools). Use the `--full` flag to enable this configuration. Use the `--region` flag to specify the Postman API region (`us` or `eu`), or set the `POSTMAN_API_BASE_URL` environment variable directly. By default, the server uses the `us` option. ### Install in Cursor Click the button to install the local Postman MCP Server in Cursor: [![Install the local Postman MCP Server in Cursor](https://cursor.com/deeplink/mcp-install-dark.svg)](https://cursor.com/en/install-mcp?name=postman_api_mcp&config=eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyJAcG9zdG1hbi9wb3N0bWFuLW1jcC1zZXJ2ZXIiLCItLWZ1bGwiXSwiZW52Ijp7IlBPU1RNQU5fQVBJX0tFWSI6IllPVVJfQVBJX0tFWSJ9fQ%3D%3D) By default, the server uses **Full** mode. To access **Minimal** mode, remove the `--full` flag from the `mcp.json` configuration file. To access **Code** mode, replace the `--full` flag with the `--code` flag. ### Install in Visual Studio Code Click the button to install the local Postman MCP Server in VS Code: [![Install the local Postman MCP Server in VS Code](https://img.shields.io/badge/VS_Code-Install_Server-0098FF?style=flat-square&logo=visualstudiocode&logoColor=white)](https://insiders.vscode.dev/redirect/mcp/install?name=postman_api_mcp&inputs=%5B%7B%22id%22%3A%22postman_api_key%22%2C%22type%22%3A%22promptString%22%2C%22description%22%3A%22Enter%20your%20Postman%20API%20key%22%7D%5D&config=%7B%22command%22%3A%22npx%22%2C%22args%22%3A%5B%22%40postman%2Fpostman-mcp-server%22%2C%22--full%22%5D%2C%22env%22%3A%7B%22POSTMAN_API_KEY%22%3A%22%24%7Binput%3Apostman-api-key%7D%22%7D%7D) By default, the server uses **Full** mode. To access **Minimal** mode, remove the `--full` flag from the `mcp.json` configuration file. To access **Code** mode, replace the `--full` flag with the `--code` flag. #### Manual installation You can manually integrate your MCP server with VS Code to use it with extensions that support MCP. To do so, create a `.vscode/mcp.json` file in your project and add the following JSON block to it: ```json { "servers": { "postman-api-mcp": { "type": "stdio", "command": "npx", "args": [ "@postman/postman-mcp-server", "--full" // (optional) Use this flag to enable full mode. "--code" // (optional) Use this flag to enable code mode. "--region us" // (optional) Use this flag to specify the Postman API region (us or eu). Defaults to us. ], "env": { "POSTMAN_API_KEY": "${input:postman-api-key}" } } }, "inputs": [ { "id": "postman-api-key", "type": "promptString", "description": "Enter your Postman API key" } ] } ``` ### Claude integration To integrate the local Postman MCP Server with Claude, check the [latest Postman MCP server release](https://github.com/postmanlabs/postman-mcp-server/releases) and get the `.mcpb` file: * **Minimal** - `postman-api-mcp-minimal.mcpb` * **Code** - `postman-mcp-server-code.mcpb` * **Full** - `postman-api-mcp-full.mcpb` For more information, see the [Claude Desktop Extensions](https://www.anthropic.com/engineering/desktop-extensions) documentation. ### Install in Claude Code To install the MCP server in Claude Code, run the following command in your terminal: For **Minimal** mode: ```bash claude mcp add postman --env POSTMAN_API_KEY=YOUR_KEY -- npx @postman/postman-mcp-server@latest ``` For **Code** mode: ```bash claude mcp add postman --env POSTMAN_API_KEY=YOUR_KEY -- npx @postman/postman-mcp-server@latest --code ``` For **Full** mode: ```bash claude mcp add postman --env POSTMAN_API_KEY=YOUR_KEY -- npx @postman/postman-mcp-server@latest --full ``` ### Use as a Gemini CLI extension To install the MCP server as a Gemini CLI extension, run the following command in your terminal: ```bash gemini extensions install https://github.com/postmanlabs/postman-mcp-server ``` ### Install in Docker To use the Postman MCP Server in Docker, you can use one of the following methods: * To install the Postman MCP Server in Docker, see the [Postman MCP Server](https://hub.docker.com/mcp/server/postman/overview) at Docker MCP Hub. Click **+ Add to Docker Desktop** to automatically install it. * To run the Postman MCP Server image in Docker, run the following command in your terminal. Docker automatically discovers, downloads, and runs the Postman MCP Server image: ```bash docker run -i -e POSTMAN_API_KEY="your-secret-key" mcp/postman ``` * To build and run the server in Docker manually, run the `docker build -t postman-api-mcp-stdio .` command. Then, run one of the following commands, replacing `$YOUR-POSTMAN-API-KEY` with your Postman API key: * **Minimal** - `docker run -i -e POSTMAN_API_KEY="your-secret-key" postman-api-mcp-stdio` * **Full** - `docker run -i -e POSTMAN_API_KEY="your-secret-key" postman-api-mcp-stdio --full` ### Install in Kiro To use the Postman MCP Server in Kiro, you can use one of the following methods: To set up the Postman MCP Server with one-click, see [API Testing with Postman](https://kiro.dev/powers/) on the Kiro Powers page. Click **Add to Kiro**. To install the Postman MCP Server manually, do the following: 1. Launch Kiro and click the Kiro ghost icon in the left sidebar. 1. Add an MCP Server and select either **User Config** or **Workspace Config** to install the Postman MCP server. 1. Add the following JSON block to the `mcp.json` configuration file: ```json { "mcpServers": { "postman": { "command": "npx", "args": [ "@postman/postman-mcp-server" ], "env": { "POSTMAN_API_KEY": "postman-api-key" }, "disabled": false, "autoApprove": [ "getAuthenticatedUser" ] } } } ``` After you've completed your MCP configuration, you can return to the flow template or set up authorization for another integration in Postman. --- # Set up a monitor in Postman Create a new monitor to continuously check your API's health, run test suites, or validate critical workflows. When creating a monitor, you select a collection with the requests you want to run and set a schedule for how often Postman runs the collection. ## Create a monitor You can create a new monitor from the sidebar or select a collection to monitor. To create a new monitor from the sidebar, do the following: 1. Click **Monitors** in the sidebar. 2. Click **Create new monitor**. 3. [Configure](#configure-a-monitor) your new monitor. To create a monitor from a collection, do the following: 1. Click **Collections** in the sidebar. 2. Click **Create new collection**. 3. In the **Create a new collection from API gateway** popup window, enter the following information: - Select an API from the gateway. - Select the stage on which the API is deployed. - Create an environment (optional). This creates a new environment on Postman for the API variables from the gateway. 4. Click **Create collection**. Postman adds a new collection file to your team's component library in the OpenAPI specification format you chose. [Add your own components to the file](#edit-a-component-file) so your team can reuse them in their specifications. ## Edit a component file Add reusable components to new and existing component files. Define reusable components you'd like to standardize in your team's specifications, making the component file the single source of truth. You can edit only the draft version of a component file. 1. Click **Docs** in the sidebar, then open a specification. 2. Click **Components** in the lower right of the specification. 3. Click **Open Component Library**. 4. Click a component file in the left sidebar. 5. Choose a published version of the component file using the version dropdown list. 6. In the left sidebar, click **Copy component link** next to a component. This copies the URL to the version of the component you select in the dropdown list. 7. Add the URL to a reference (`$ref`) in your specification. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. To view the live documentation, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. If a social channel is already subscribed to workspace updates, the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click **![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon)** ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Enable Local Secret Protection Postman's Local Secret Protection is available with [Postman Enterprise plans](https://www.postman.com/pricing/). With the Secret Scanner's Local Secret Protection, [Team Admins](/docs/administration/roles-and-permissions/#team-roles) can configure where Postman stores the team's exposed secrets in the workspaces or types of workspaces you've defined. When [enabled](#enable-local-secret-protection), Postman scans secrets in real time and takes action, storing exposed secrets, like API keys, JWT tokens, or auth tokens, in the [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/). The Postman Vault stores your exposed secrets securely on your device. The original secret value is replaced with a vault secret reference. This prevents your team's secrets from syncing to the Postman cloud and gives you greater control over your team's security posture and compliance requirements. Postman's Local Secret Protection actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values ### Local Secret Protection requires Postman version 11.71.3 or later. ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/), then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. ### Notes: * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![The Local Secret Protection interface](https://assets.postman.com/postman-docs/v11/local-secret-protection-interface-11-1.jpg) Postman's automatic secret protection policy offers the following options: * **No policy** - Ignores any secrets detected by the Secret Scanner and stores them in the Postman cloud. Secret Scanner performs no automated actions or notifications. Partner and internal workspaces use this policy by default. * **Move to vault** - Automatically moves detected secrets to the Postman Vault. Secrets stored in the Postman Vault aren't synced to the Postman cloud, and the original secret value is replaced with a [variable reference](/docs/sending-requests/postman-vault/manage-vault-secrets/#use-vault-secrets) to the vault secret. Public workspaces use this policy by default. Users are notified when Postman detects an exposed secret: * If the user's vault is unlocked, they'll receive a notification that their secrets were moved to and secured in their Postman Vault. Users can click **Got it** to dismiss the message, or request to override the policy. * If the user's vault is locked, they'll receive a notification to unlock their vault. They can review the detected secrets, then click **Unlock Vault** to move them to their vault. Or, users can click **Ignore** to dismiss the notification, but they'll be required to unlock their vault and move the detected secrets to their vault before they can save their secrets. Users can choose to request a policy override for a detected secret if they click **Override policy** in the notification. They must select a justification to submit to the Team Admin, then click **Override** to submit it. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can also use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). To set default policies by workspace types, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. By default, only the first 50 workspaces are listed. To select all workspaces or workspaces of the selected type, click **Select all workspaces within team**. The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click **Post Update**. If a social channel is already subscribed to workspace updates, the checkbox next to **Share on Slack (or Teams)** on the bottom right of the post will be checked. If not, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. Learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. Learn more about: * [Creating organization teams and workspaces](/docs/administration/organization/create/) * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- # Customize Postman settings Postman automatically chooses default values for some settings so you can get right to work. Make changes to settings at any time based on your use case or to customize your Postman experience. To change settings in Postman, click ![Image 1: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the header and then click **Settings**. In the Postman desktop app, you can also click **⌘+Comma (,)** or **Ctrl+Comma (,)**. ## General Use the settings on the **General** tab to configure how Postman sends requests or to customize the Postman user interface. ![General settings](https://assets.postman.com/postman-docs/v11/settings-detail-v11.74.png) ### Request * **HTTP Version** - Select the HTTP version to use when you send requests. This enables you to test and debug requests by HTTP version. You can also specify the HTTP version for an individual request. Learn more about [specifying an HTTP version](/docs/sending-requests/response-data/troubleshooting-api-requests/#debugging-by-http-version). * **Request Timeout** - Enter how long (in milliseconds) Postman will wait for a response before timing out. If you enter **0**, Postman will wait for a response forever. * **Max response size** - Enter the largest response size (in megabytes) that Postman will download. For responses that exceed this limit, Postman asks if you want to increase the size limit or download the response. If you enter **0**, Postman downloads responses of any size. Rendering large responses may affect Postman's performance. * **SSL certificate verification** - Turn this off to prevent Postman from checking the validity of SSL certificates when making requests. * **SSL/TLS key log** - Turn this on to enable SSL/TLS session key logging for debugging encrypted connections. You can export a SSLKEYLOGFILE and use it to decrypt secure traffic locally for inspection with tools like Wireshark. * **Disable cookies** - Turn this off to stop using the [Postman cookie jar](/docs/sending-requests/response-data/cookies/). * **Request validation** - When this is turned on, Postman automatically validates requests in collections linked to an API. Postman compares requests to the API definition and alerts you to any inconsistencies. Learn more about [validating requests and responses](/docs/design-apis/api-builder/develop-apis/validating-elements-against-schema/). * **Response format detection** - By default, Postman automatically detects the correct media type for the response body based on the `Content-Type` header. Select **JSON** to always use JSON rendering for the response body. ### Working directory When you send a form-data or binary file with a request body, Postman saves a path to the test file as part of the collection. The file path is relative to your working directory. On macOS and Linux, you can find the default working directory at `~/Postman/files`. On Windows, you can find the default working directory at `%userprofile%\\Postman\\files` (File Explorer and Command Prompt) or `~/Postman/files` (PowerShell). To use a different working directory, click **Choose** and then select the directory you want to use. Storing files in your working directory ensures that requests in shared collections always work. As long as you and your teammates use the same files and working directory location, shared requests will run across everyone's systems. Learn more about [sending body data](/docs/sending-requests/create-requests/parameters/). ![Working directory settings](https://assets.postman.com/postman-docs/v11/working-directory-web-v11.74.png) **To make collaboration easier, upload test data files to your Postman team.** You can used files uploaded to your team as form data or binary data when sending a request. If you share the request in a workspace, other team members can send the shared request without needing to copy the files to their local working directory. Learn more about [uploading files for shared requests](/docs/sending-requests/create-requests/test-data/). **You can't change the working directory in the Postman web app.** When you send a file with a request, the Postman web app creates a new folder with a random name in the `~/Postman/files` directory. Postman stores a copy of the file in the new folder so you can use it when sending requests. To automatically sync files from the Postman web app with your local working directory, make sure you are using the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent). If you choose a different working directory than `~/Postman/files` for the Postman desktop app, you will still be able to work between the Postman desktop app and the Postman web app by taking the following steps: * To access a file from the Postman desktop app using the web app, copy it from the desktop app's working directory into `~/Postman/files` so the web app has access to it. * To access a file from the Postman web app using the desktop app, find the file in `~/Postman/files`. When you add a file to a request using the web app, it creates a folder with a random name in `~/Postman/files`. Copy this folder into your desktop app's working directory so the desktop app has access to it. * If you're sharing a request with others, each team member must have the files present in the correct working directory. If one team member adds a file to a request using the Postman web app, they need to share the folder and file that's created with everyone who wants to use the request, and this folder must be copied to each team member's working directory. * Instead of copying files to your local system, you can upload test data files to your Postman team to make collaboration easier. All team members can use the uploaded files to send requests without needing to place the files in their working directory. Learn more about [uploading files for shared requests](/docs/sending-requests/create-requests/test-data/). **The working directory is also used by Newman.** Store files you want to use with Newman in the working directory path saved in the collection. Learn more about [file uploads in Newman](/docs/collections/using-newman-cli/newman-file-uploads/). **Use caution with files located outside your working directory.** To use files located outside your working directory when sending requests, turn on **Read files outside working directory**. This option gives third-party collections the ability to read any file on your system. Use caution, and make sure you trust all third-party collections you are using before enabling this option. ### Headers * **Send no-cache header** - (Recommended) Turn this on to send a `Cache-Control: no-cache` header with each request. The `no-cache` directive forces the server to revalidate each request and ensures you get an up-to-date (not stale) response. * **Send Postman Token header** - (Recommended) Turn this on to send a random Postman token with an XMLHttpRequest. Sending a random token ensures the receiving server handles one request at a time, even when the requests send with the same parameters. The token can also aid debugging and help you distinguish between requests on the server side. * **Retain headers when clicking on links** - When you click a link in a response, Postman creates a new `GET` request with the link URL. Turn this on to keep the headers from the earlier request in the new request. Retaining headers is useful if you mainly access protected resources. * **Automatically follow redirects** - Turn this off to prevent requests that return a 3xx series response from automatically redirecting. ### User interface * **Remove tabs** - _(Postman web app)_ Use tabs in your browser to navigate Postman instead of in-app tabs. For more information, see [Browser tabs in the Postman web app](/docs/getting-started/basics/navigating-postman/#browser-tabs-in-the-postman-web-app). * **Always open sidebar item in new tab** - By default, when you click a sidebar item, Postman opens it in the preview tab. Turn this on to always open sidebar items in a new tab. * **Always ask when closing unsaved tabs** - By default, Postman asks if you want to save any unsaved changes when closing a tab. Turn this off to always discard unsaved changes when closing a tab. * **Show icons with tab names** - Turn this off to hide the icons that appear next to tab names. * **Two-pane view** - By default, Postman displays responses below requests. Turn this on to display the response and request panes side by side. * **Variable autocomplete** - Turn this on to enable autocomplete when typing variable names. * **Default documentation editor** - Select the default editor you want to use for [editing documentation descriptions](/docs/publishing-your-api/authoring-your-documentation/) in Postman (**Postman editor** or **Markdown editor**). ### Editor settings **Editor** settings affect code-related text such as request and response bodies, pre-request scripts, and tests. To revert to default text settings, click **Reset**. * **Font family** - Enter one or more font family names separated by commas. Postman uses the first available font family to display code text. * **Font size** - Enter the font size in pixels to use for code text. * **Indentation count** - Enter the number of indentation characters to use for each code level. * **Indentation type** - Select the indentation character type to use (**Space** or **Tab**). * **Auto close brackets** - Turn this on to automatically add a closing bracket when you enter an opening bracket. * **Auto close quotes** - Turn this on to automatically add a closing quotation mark when you enter an opening quotation mark. ### Application * **Open in desktop app** - Automatically open workspace-related links in the Postman desktop app. If not turned on, links open in the browser. * **Language** - Select your preferred language for the Postman app and email notifications. * **Autosave** - Turn this on to automatically save your changes to requests. Turn this off to manually save your changes. * **Send anonymous usage data to Postman** - Postman gathers basic, anonymous usage data to help with product improvement. Turn this off to stop sending anonymous usage data to Postman. ## Themes Postman enables you to adapt Postman to your visual preferences in two ways. You can set the theme manually or sync it with the operating system's appearance settings. Themes auto-sync by default. ![Image 2: Manually select a theme](https://assets.postman.com/postman-docs/v11/settings-theme-v11.74.png) You can select a single theme to be applied in light or dark mode at all times. ![Image 3: Manually select a theme](https://assets.postman.com/postman-docs/v11/settings-theme-v11.74.png) You can also switch the themes based on your system settings, and have a different theme for day and night, respectively. ![Image 4: Manually select a theme](https://assets.postman.com/postman-docs/v11/settings-theme-v11.74.png) Not all themes have a light/dark counterpart. ## Shortcuts The **Shortcuts** tab displays all the keyboard shortcuts available in Postman. You can use the default shortcuts, or customize them if you're using the Postman desktop app. To customize a shortcut, click it and then enter your preferred shortcut. Custom shortcuts must meet the following requirements: * Shortcuts can't overlap with system shortcuts. * Shortcuts can't overlap with existing Postman shortcuts. * _(macOS)_ Shortcuts must include the **Control** (**⌃**), **Option** (**⌥**), **Shift** (**⇧**), or **Command** (**⌘**) key. * _(Windows)_ Shortcuts must include the **Ctrl**, **Alt**, or **Shift** key. You can revert to the default shortcuts by clicking **Restore Defaults**. To turn off keyboard shortcuts entirely, turn off the **Keyboard shortcuts** toggle. ![Image 5: Keyboard shortcuts](https://assets.postman.com/postman-docs/v11/shortcuts-v11.74.png) Some shortcuts aren't available in the Postman web app. Also, shortcut modifier keys in Postman may differ depending on your operating system. For example, to open a new tab click **⌘+T** on macOS or **Ctrl+T** on Windows or Linux. ## AI You can control AI-powered features in the **AI** tab. Toggle on **AI** to use AI in Postman. To use AI, you need to agree to Postman AI terms. ### Agent Mode [Agent Mode](/docs/agent-mode/overview/) turns your words into action across the API lifecycle, enabling you to use natural language to send requests, fix errors, update tests, and more. To open Agent Mode on startup, toggle on **Open on startup**. If you purchased Postbot on a Free, Basic, or Professional plans before December 1, it'll continue to work for you. Otherwise, it's available as an add-on in Enterprise plans. To turn it on or off, toggle **Keep using legacy chat**. ### Code editing assistance You can configure AI assistance when editing scripts, JSON payloads, or example responses in Postman. * To show autocomplete suggestions while working with scripts, toggle on **Code Autocomplete**. * To display an AI icon when selecting parts of scripts or payloads, toggle on **Inline Selection Icon**. ## Data Use the **Data** tab to import data. To begin the import process, click **Import Data File** and select a Postman data dump file in ZIP format. Importing a dump file may overwrite your existing collections and environments, so use caution. Always make a backup before importing files. Learn more about [importing and exporting data](/docs/getting-started/importing-and-exporting/importing-and-exporting-overview/). ## Add-ons Download add-ons to enhance your Postman experience: * **Postman CLI** - Run collections, automate tests, and integrate with CI/CD workflows from your command line. Click **Download from npm** to go to the npm website and install the Postman CLI. To learn more about the Postman CLI, see [Explore Postman's command-line companion](/docs/postman-cli/postman-cli-overview/). * **Postman VS Code Extension** - Send requests, test APIs, and manage collections, all from within your code editor. The Postman VS Code Extension is also available for Cursor, Windsurf, and other compatible editors. Click **Install on VS Code** to learn more. * **Postman Interceptor** - Capture and sync cookies and requests directly from your browser to Postman. Use Postman Interceptor to test authenticated APIs and debug browser-based workflows seamlessly. Click **Install on Chrome** to go to the Google Chrome Web Store and install Postman Interceptor. To learn more, see [Capture traffic from a web browser using Postman Interceptor](/docs/sending-requests/capturing-request-data/interceptor/). ## Certificates Use the **Certificates** tab to add and manage CA certificates and client certificates in Postman. Learn more about [managing certificates](/docs/sending-requests/authorization/certificates/). ## Connected accounts You can use the **Connected accounts** tab to manage the accounts and tokens used to authorize Postman with third-party services. For example, when you [connect an API in the Postman API Builder to a Git repository](/docs/design-apis/api-builder/versioning-an-api/overview/), Postman stores your authorization details. You can then use the connected account to add other integrations to the same service. You can manage your saved accounts and tokens on the **Connected accounts** tab: * To view a saved token, click ![Image 6: View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke-small.svg#icon). * To edit a saved token, click ![Image 7: Edit icon](https://assets.postman.com/postman-docs/aether-icons/action-edit-stroke.svg#icon). For example, if a token expired, you can edit it and enter a new valid token. * To remove a saved account or token, click ![Image 8: Delete icon](https://assets.postman.com/postman-docs/aether-icons/action-delete-stroke-small.svg#icon) **Delete authentication**. Any integrations that use the account or token will stop working until you reauthorize them. ![Connected accounts](https://assets.postman.com/postman-docs/v10/settings-connected-accounts-v10-16a.jpg) If you don't have any connected accounts, this tab doesn't appear in the Postman settings. ## Proxy Use the **Proxy** tab to configure proxy settings for connecting to online services and sending API requests. Learn more about [configuring a proxy](/docs/getting-started/installation/proxy/). ## Feature previews Use the **Feature previews** tab to preview early iterations of features and turn them on and off at the user level. Be aware that these features are designed for early adopters and may not always work as expected. ## App updates Use the **Update** tab to check for updates to the Postman desktop app or to enable automatic updating. Learn more about [updating Postman](/docs/getting-started/installation/installation-and-updates/#update-postman). ## About The **About** tab displays the current version of Postman, along with links to helpful information and support. --- # Sign up for Postman Before you sign up for a Postman account, download the Postman desktop app or access Postman on the web. To learn more, go to [Get the Postman app](/docs/getting-started/first-steps/get-postman/). If you're using the [Postman desktop app](/docs/getting-started/first-steps/get-postman/) and not signed in, you're in the [lightweight Postman API Client](/docs/getting-started/basics/using-api-client/), which is a space where you can build and send requests. If you want to sync your work, organize requests into collections, collaborate with others, or use other features, sign up for a free account and [sign in](#sign-in-to-postman) to Postman. ## Sign up for Postman To create an account, do the following: 1. Click **Create Account** in the upper-right corner of your desktop app, or click **Sign up for free** from the [Postman website](https://go.postman.co/home/). 2. Begin your sign-up using one of the following options: - **Email** - Enter your email address and create a username and password, then click **Create Free Account**. You'll be asked to verify your account before you can use Postman. Enter the 6-digit verification sent to your email and click **Verify Account**. If you haven't received a verification code, you can click **Resend verification code**. - **GitHub** - Click **Sign up with GitHub** to be redirected to the GitHub authorization page, where you can select an email associated with your GitHub account. - **Google account** - Click **Sign Up with Google** and follow the instructions. - **SSO** - Click **Sign In with SSO** if your organization has a team set up with single sign-on (SSO). 3. Select **Stay signed in** if you want to remain signed in for 30 days. See [Sign in to Postman](#sign-in-to-postman) for more information. 4. Click **Create free account**. 5. Add your name and role and let us how you'd like to use Postman, to help us customize your Postman experience. Click **Continue**. 6. Join your first team or click **Skip**. If you sign up with your company email and your company has a Postman account with team discovery enabled, you'll get a list of [teams you can join](/docs/collaborating-in-postman/use-teams/#find-teams-within-your-organization). 7. Select a plan or click **Continue with Free Plan**. 8. Set up a team. Update your team name and optionally invite others using a share link or email. Then, click **Continue**. If you're a professional domain user, note the following: - Your team is discoverable by default. You can allow anyone with the same `@company.com` domain to automatically join your team through [links](/docs/administration/managing-your-team/team-settings/) and [automatically join from team discovery](/docs/administration/managing-your-team/team-settings/) in that team setting page toggle. - You can update these settings at any time in [configure team settings](/docs/administration/managing-your-team/team-settings/). 9. Respond to the Postman usage prompt and click **Let's Go** or click **Skip**. If you type or select a built-in prompt, a tailored test workspace will be created for you. Your new Postman profile will be visible to collaborators and anyone with access to the resources you share or publish. To learn more about your Postman profile and how to customize it, see [Customize your Postman profile](/docs/getting-started/installation/postman-profile/). You can [sync](/docs/getting-started/basics/syncing/) your work so that you can access it from different machines. You can also learn more about [Postman account settings](/docs/getting-started/account/settings/). ## Sign in to Postman You can sign in to the Postman desktop app by clicking **Sign In** in the upper-right corner. You can also go to [Postman's website](https://www.postman.com/) and click **Sign In** in the upper-right corner of the page. This enables you to carry out many of your API development and testing tasks in your browser. When you sign in using the Postman desktop app, the app will open a new screen that directs you to _Sign in from your browser to continue_. Your default browser will automatically open a webpage asking you to sign in to Postman. If your browser doesn't open within a few seconds, click either **open it manually** or **copy the URL**. You can opt out of the sign-in process by clicking **Skip and take me to Postman Desktop App**. Sign in to Postman in your browser by entering your account credentials or signing in with Google. If you're signing in to a Postman Enterprise team with single-sign on (SSO) enabled, opt to **Sign in with SSO**. To learn more, see [Sign in to an SSO team](/docs/administration/sso/user-sso/). If this is your first time signing in to Postman with SSO, you might need to [link your account to Postman](/docs/getting-started/account/manage/#link-your-account-to-postman). Select **Stay signed in** if you want to remain signed in until you are inactive for 30 days before being asked to reauthenticate. Clear this checkbox if you don't want to remain signed in on the computer you're working on. Note that Postman will prompt you to sign in again after 30 minutes. Your team may have set up a maximum session duration for all team members. In that case, sessions will be revoked based on the team setting. If you've set up [two-factor authentication](/docs/getting-started/account/settings/#set-up-two-factor-authentication) (2FA), Postman will prompt you to enter the verification code from your authenticator app and click **Verify**. If you've lost access to your device and can't access your authenticator app, click **Use a recovery code**. If you've lost your recovery codes, [email Postman support](mailto:help@postman.com) from a registered email address for help. After you sign in, you will be redirected back to the Postman desktop app. If you're a member of multiple Postman teams with varying authentication methods, you must sign in to those teams separately. To do so, click your avatar in the Postman header, then select the team to proceed. You must complete the process of signing in within five minutes once you begin the process in the Postman desktop app. If you go beyond this time, you must return to the Postman desktop app and restart the sign-in process. --- # The Start block ![Start block](https://assets.postman.com/postman-docs/v11/flows-reference-blocks-start-v11.54.6.jpg) The **Start** block is automatically added to every new flow module. You can add inputs that receive data from [scenarios](/docs/postman-flows/build-flows/configure/scenarios/). Also, if you bring the flow into another flow, or into an [action](/docs/postman-flows/build-flows/structure/actions/), the **Start** block's inputs in the original flow become the [**Flow Module**](/docs/postman-flows/reference/blocks/flow-module/) block's inputs in the new one. ## Inputs By default, the **Start** block has no input ports. You can [add inputs](#receive-data-with-inputs) as desired. ## Output By default, the **Start** block has a single output port that will be connected to the first block you add by clicking buttons during [setup](#setup). Otherwise, the output port sends the data provided by the first [input you add](#receive-data-with-inputs). You can also leave the **Start** block as is, without inputs or connected blocks - in that case, the output won't send any data. ## Setup The **Start** block appears automatically on every new flow's canvas. A new **Start** block is connected to three buttons you can click to do the following: - Add an [**HTTP Request**](/docs/postman-flows/reference/blocks/http-request/) block to your canvas. - Open the [blocks list](/docs/postman-flows/build-flows/create/create-blocks/) to add a block. - Explore the [Flows Catalog](/docs/postman-flows/get-started/flows-catalog/). ### Receive data with inputs You can add inputs to the **Start** block. Each input will appear as an inline [data block](/docs/postman-flows/reference/overview-data-blocks/). You must also create a [scenario](/docs/postman-flows/build-flows/configure/scenarios/) to send data to all the inputs. For each input you add, Postman adds an output to the **Start** block. When you run the flow, the **Start** block sends data through the outputs to any connected blocks. To add an input to the **Start** block, do the following: 1. In the **Start** block, click \[![Add input](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon)\] **Add input**. A **String** block is inserted into the **Start** block. 2. (Optional) Click the dropdown list if you want to select a data block other than **String**. Use \[![Locked icon](https://assets.postman.com/postman-docs/aether-icons/state-locked-stroke.svg#icon)\] **Secret** for sensitive string values like API keys. To learn how secret inputs work, see [Secrets in scenarios](/docs/postman-flows/build-flows/configure/scenarios/#secrets-in-scenarios). 3. Enter a name for the input. 4. Create a scenario to send data to the input. If you run the flow without creating the scenario first, Postman will automatically create a scenario for you, using minimal or empty values like `0` for a **Number** block, `[]` for a **List** block, or the empty string for a **String** block. ### Specify inputs for a flow module When a [**Flow Module** block](/docs/postman-flows/reference/blocks/flow-module/) references a flow whose **Start** block has inputs, those inputs appear as named input ports in the **Flow Module** block. When other blocks send data to these ports, the **Flow Module** block will send that data to the corresponding inputs in the referenced flow's **Start** block. The values that the referenced flow produces will then be available through the **Flow Module** block's outputs. To learn more, see [Build a "Hello, world" flow module](/docs/postman-flows/get-started/build-your-first-flow/). The scenarios you created to provide data to the inputs in the referenced flow's **Start** block won't be available to the **Flow Module** block. This means that in the flow or action containing the **Flow Module** block, you need to add blocks or scenarios to supply data to the inputs. ## Example Suppose you make the following flow into a module, with the idea of referencing it in an action: ![HTTP Request block with variables](https://assets.postman.com/postman-docs/v11/flows-reference-blocks-http-start-ex1-v11-56.0.jpg) You name the flow **Module to build wx message** and use a **Flow Module** block to reference it in an action. Encapsulating all the original flow's blocks in a single module makes your action simpler and easier to grasp. Providing data to the **Flow Module** block's inputs is required. When testing the action, you create a scenario to provide the data. The result looks like this: ![HTTP Request block with variables](https://assets.postman.com/postman-docs/v11/flows-reference-blocks-http-start-ex4-v11-56.0.jpg) ## Related blocks Upon creation, every flow module has a **Start** block with a connected [**HTTP Request**](/docs/postman-flows/reference/blocks/http-request/) block. If you add inputs to a **Start** block, they will become inputs in any [**Flow Module**](/docs/postman-flows/reference/blocks/flow-module/) block referencing the flow that contains the **Start** block. --- # Sync cookies using Postman Interceptor and the Postman proxy Postman enables you to capture and sync cookies from a web browser or another client application to the [Postman cookie jar](/docs/sending-requests/response-data/cookies/). You can sync cookies using either the Postman proxy or Postman Interceptor at any time, without having to start a [proxy or Interceptor session](/docs/sending-requests/capturing-request-data/capture-overview/). Once configured, Postman continuously captures cookies from the browser or client applications. For the domains you specify, captured cookies are automatically synced to the Postman cookie jar. You can then [use the cookies](/docs/sending-requests/response-data/cookies/) when sending requests from Postman. You can also capture requests and cookies during a proxy or Interceptor session. Learn more about capturing requests and cookies with the [Postman proxy](/docs/sending-requests/capturing-request-data/capturing-http-requests/) or [Postman Interceptor](/docs/sending-requests/capturing-request-data/interceptor/). ## Sync cookies with Postman Interceptor Postman Interceptor is a browser extension that captures network requests from a web browser and saves them to Postman. You can use Interceptor to continuously sync the cookies in your browser to the Postman cookie jar. This option works with either the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) or the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app). The Postman cookie jar always has the latest value for a given cookie. If you need to observe how cookie values change during a request flow, start an [Interceptor session](/docs/sending-requests/capturing-request-data/interceptor/). To sync cookies using Postman Interceptor, do the following: 1. Install the Postman Interceptor extension by following the steps in [Install Interceptor](/docs/sending-requests/capturing-request-data/interceptor/#install-interceptor). 2. Click ![Image 1: Cookie icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-cookie-stroke-small.svg#icon) **Cookies** in the Postman footer. 3. In the **Cookies** window, click **Sync Cookies**. If you're using the Postman desktop app, click **Interceptor**. If you get the message "No connection to Interceptor", make sure your browser is open and the [Interceptor extension is installed](/docs/sending-requests/capturing-request-data/interceptor/#install-interceptor). If you're using the Postman desktop app, try closing any browser tabs where the Postman web app is open. 4. Enter one or more **Domains**. Postman will sync cookies for the specified domains to the Postman cookie jar. > Adding a domain automatically syncs cookies for its subdomains as well. For example, adding the domain `postman-echo.com` will also sync cookies from `docs.postman-echo.com`. To sync cookies for the domain only, you can add `https://` in front of the domain, such as `https://postman-echo.com`. 5. Click **Start Syncing**. Cookies for the domains you specified are automatically synced from your browser to Postman. * To stop syncing cookies for a domain, click ![Image 2: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) next to the domain name. * To stop capturing and syncing all cookies, click **Stop Syncing**. ![Image 3: Sync cookies with Interceptor](https://assets.postman.com/postman-docs/v11/cookies-interceptor-capture-v11.png) ## Sync cookies from the Interceptor extension You can use the Postman Interceptor extension to sync cookies from your browser to the Postman cookie jar, without starting an Interceptor session. This option works with either the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) or the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app). To sync cookies from the Interceptor extension: 1. Install the Postman Interceptor extension by following the steps in [Install Interceptor](/docs/sending-requests/capturing-request-data/interceptor/#install-interceptor). 2. Open the Interceptor extension by clicking the Interceptor icon in your browser's toolbar. 3. Click ![Image 4: Cookie icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-cookie-stroke.svg#icon) **Sync Cookies**. Make sure the message **Ready to sync** appears at the bottom of the Interceptor window. If the message **Interceptor disconnected** appears, make sure either the Postman desktop app is running or the Postman web app is open in your browser. 4. Enter one or more **Domains**. Postman will sync cookies for the specified domains to the Postman cookie jar. > Adding a domain automatically syncs cookies for its subdomains as well. For example, adding the domain `postman-echo.com` will also sync cookies from `docs.postman-echo.com`. To sync cookies for the domain only, you can add `https://` in front of the domain, such as `https://postman-echo.com`. 5. Click **Sync Cookies**. Cookies for the domains you specified are automatically synced from your browser to Postman. * To stop syncing cookies for a domain, click ![Image 5: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) next to the domain name. * To stop capturing and syncing all cookies, click **Stop Syncing**. ![Image 6: Sync cookies with the Interceptor extension](https://assets.postman.com/postman-docs/v11/interceptor-sync-cookies-v11.png) ## Sync cookies with the Postman proxy A proxy acts as an intermediary between a client application (like a mobile app) and a server (like an API). You can use Postman's built-in proxy to capture any cookies passing between a client and a server. The captured cookies are synced to the Postman cookie jar for later use. This option doesn't work with the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app), so make sure to use the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/). The Postman cookie jar always has the latest value for a given cookie. If you need to observe how cookie values change during a request flow, start a [proxy session](/docs/sending-requests/capturing-request-data/capturing-http-requests/). To sync cookies using the Postman proxy, do the following: 1. Open the Postman desktop app and click ![Image 7: Cookie icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-cookie-stroke-small.svg#icon) **Cookies** in the Postman footer. 2. In the **Cookies** window, click **Sync Cookies** and click **Proxy**. 3. Enter a **Port** number. The default value is `5559`. You will use this port number when configuring clients. > You can't change the port number while the proxy is enabled. 4. Turn on **Enable Postman as a proxy**. 5. Enter one or more **Domains**. Postman will sync cookies for the specified domains to the Postman cookie jar. > Adding a domain automatically syncs cookies for its subdomains as well. For example, adding the domain `postman-echo.com` will also sync cookies from `docs.postman-echo.com`. To sync cookies for the domain only, you can add `https://` in front of the domain, such as `https://postman-echo.com`. 6. Click **Start Syncing**. * To start syncing cookies, configure one or more clients to use the Postman proxy. Learn more about [configuring the proxy on a client device](/docs/sending-requests/capturing-request-data/capturing-http-requests/#step-3-configure-the-proxy-on-a-client-device). * To stop syncing cookies for a domain, click ![Image 8: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) next to the domain name. * To stop capturing and syncing all cookies, click **Stop Syncing**. ![Image 9: Capture cookies with the proxy](https://assets.postman.com/postman-docs/v11/cookies-proxy-capture-v11.png) --- # Prepare your internal workspace for team collaboration You can use an internal workspace to draft and organize your work, and [collaborate with your team](/docs/collaborating-in-postman/collaborate-in-postman-overview/). To prepare your internal workspace, you'll fork [your public collections](/docs/postman-api-network/showcase/prepare/public-collections/) from [your public workspace](/docs/postman-api-network/showcase/prepare/public-workspace/) to your internal workspace. When your public API's next iteration is ready to publish, you can [create a pull request](/docs/postman-api-network/showcase/publish/maintain-public-apis/#create-a-pull-request-to-merge-to-your-public-collection) and [merge your changes](/docs/postman-api-network/showcase/publish/maintain-public-apis/#review-approve-and-merge-the-pull-request-to-your-public-collection) to [your public workspace](/docs/postman-api-network/showcase/prepare/public-workspace/). This makes your latest changes available to your API consumers on the Postman API Network. If you prefer to use one workspace to manage your public APIs, you can skip the following sections and [publish your public APIs to the Postman API Network](/docs/postman-api-network/showcase/publish/public-apis/). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 1: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 2: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 3: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 4: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 5: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 6: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 7: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 8: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 9: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 10: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 11: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 12: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 13: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 14: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 15: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 16: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 17: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 18: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 19: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 20: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 21: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 22: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 23: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 24: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 25: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 26: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 27: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 28: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 29: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 30: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 31: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 32: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 33: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 34: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 35: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 36: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 37: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 38: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 39: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 40: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 41: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 42: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 43: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 44: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 45: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 46: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 47: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members. 3. Choose a role for each team member. 4. Click **Invite**. You can continue to invite team members as your workspace, its collections, and your public APIs evolve. To learn more, see [Share workspace](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). ## Edit your workspace details To edit your workspace details, do the following: 1. If your workspace's ![Image 48: Overview icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-overview-stroke.svg#icon) **Overview** tab isn't open, from the Postman sidebar, click your workspace's name. 2. Under **Workspace description**, add a description. 3. Under **About**, add a summary. 4. If you're on the Postman Enterprise plan, under **Tags**, add [tags](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/use-workspaces/#tag-a-workspace). You can continue to edit your workspace details as your workspace, its collections, and your public APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Fork your public collections from your public workspace To fork your public collections from your public workspace, do the following: 1. Open your public workspace. 2. From the Postman sidebar, click ![Image 49: Collection icon](https://assets.postman.com/postman-docs/aether-icons/entity-collection-stroke.svg#icon) **Collections**. 3. Next to your collection, click ![Image 50: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions**. Then, select **Create a fork**. 4. Select your team workspace. Then, click **Fork Collection**. 5. Repeat these steps for each of your public collections. Your team workspace is ready to serve as your public API's source of truth. To learn more, see [Create a fork](/docs/collaborating-in-postman/using-version-control/forking-elements/#create-a-fork). ## Create your internal workspace Depending on your team's workflow, you can create a workspace that's visible only to you and specific people or your entire team. To create your private or team workspace, do the following: 1. From the Postman header, click **Workspaces** > **Create Workspace**. 2. If you want to use a [workspace template](/docs/collaborating-in-postman/using-workspaces/create-workspaces/#apply-a-template-to-a-workspace), select one. 3. Click **Next**. 4. Name your workspace. 5. Click ![Image 51: Team icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-team-stroke.svg#icon) **Internal**. Then, click **Everyone in *team*** or **Only you and invited people**. 6. Click **Create**. To learn more, see [Create a workspace in Postman](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). ## Invite team members to your workspace To invite team members to your workspace, do the following: 1. From the Postman header, click ![Image 52: Invite icon](https://assets.postman.com/postman-docs/aether-icons/action-invite-stroke.svg#icon) **Invite**. 2. Use the available options, such as email, to invite your team members --- # Test API functionality and performance in Postman Testing is a critical part of the API development lifecycle. Testing confirms that API endpoints, methods, and integrations work as expected and that your API can meet the expected load. Here are some of the essential types of API testing you can perform in Postman: * **Integration testing** - Observe data flow and test compatibility between the various components in your application. You can also test how your application interacts with other systems. Learn more at [Test API integrations and data flow in Postman](/docs/tests-and-scripts/test-apis/integration-testing/). * **End-to-end testing** - Simulate complex user operations from start to finish to test real-world workflows. End-to-ending testing makes sure the entire system works as expected and helps identify problems with user experience. Learn more at [Test end-to-end API workflows in Postman](/docs/tests-and-scripts/test-apis/end-to-end-testing/). * **Regression testing** - Make sure updates and improvements to your application don't introduce any new defects or issues. Regression testing supports the overall quality of your API by ensuring code changes are backwards compatible. Learn more at [Test your APIs for regressions in Postman](/docs/tests-and-scripts/test-apis/regression-testing/). * **Performance testing** - Simulate real-world traffic to your application with virtual users. Each virtual user sends a series of requests to your API, so you can observe how your API behaves under load. Learn more at [Test your API's performance in Postman](/docs/tests-and-scripts/test-apis/performance-testing/). To explore recommended testing types across different API patterns, see [best practices for API test automation in Postman](https://www.postman.com/postman-best-practices/api-test-automation/). ## Postman Vault integrations Integrate your Postman Vault with Postman Flows to enable you to link vault secrets with secrets that are stored in an external vault. You can then reference vault secrets in your Postman team, and retrieve the value of external vault secrets using end-to-end encryption when you send HTTP requests. Postman supports the following Postman Vault integrations: * [1Password](/docs/sending-requests/postman-vault/1password/) * [AWS Secrets Manager](/docs/sending-requests/postman-vault/aws-secrets-manager/) * [Azure Key Vault](/docs/sending-requests/postman-vault/azure-key-vault/) * [HashiCorp Vault](/docs/sending-requests/postman-vault/hashicorp-vault/) You can create Postman Vault integrations from the Postman desktop app, and you can also create an integration from the Postman web app. ## Feature availability The following features require the Postman desktop app: * **Open Postman Vault from public workspaces** - You must use the Postman desktop app to open your Postman Vault from a public workspace. If you're using the Postman web app, you must add new vault secrets to your Postman Vault if you're opening it from a public workspace. * **Create and manage Postman Vault integrations** ([Enterprise teams only](https://www.postman.com/pricing/)) ## Troubleshoot vault secrets Postman's Secret Scanner scans public workspaces and published documentation to detect exposed secrets on all Postman plans. Postman's Secret Scanner actively scans for secrets in the following Postman elements when changes are made: * HTTP collections * Environments variable values * Global variable values Postman's Secret Scanner scans public workspaces and published documentation to detect exposed secrets on all Postman plans. Postman also identifies governance issues for components, but only once they're [referenced in your specification](#reference-a-component-in-a-specification). ## Version and publish a component file Publish a version of a component file to share the latest changes to your reusable components with your team. Versioning component files is useful for publishing a new version of your reusable components, while still supporting earlier versions. You can't edit versions once they're published. You can't delete published versions of component files. ## Reference a component in a specification Reference reusable components in your OpenAPI specifications using the URL to the component and its version. A component file must have a [published version](#version-and-publish-a-component-file) before you can reference its components in your specifications. To learn more, see [Edit workspace details](/docs/administration/managing-your-team/secret-scanner/local-secret-protection/#edit-workspace-details). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation as you edit your component file. To show the documentation preview, click [![Image 1: Docs icon](https://assets.postman.com/postman-docs/aether-icons/state-info-stroke.svg#icon)](#view-live-documentation) **Live preview** in the right sidebar. Click [![Image 2: Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon)](#close) to hide the documentation preview. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance/api-governance-overview/) rules configured for your team. Learn more about [viewing rule violations in your specification](/docs/design-apis/specifications/validate-a-specification/#view-rule-violations-in-your-specification). ## Sync components between collections and specifications Consider the following behavior when syncing changes to reusable components between collections and OpenAPI specifications. * When you [generate a collection from a specification](/docs/design-apis/specifications/generate-collections/), Postman uses referenced components from your team's component library to populate relevant parts of the collection. * When you [sync changes](/docs/design-apis/specifications/generate-collections/#sync-changes-to-a-specification) from the collection back to the specification, Postman preserves the original reference URL if the values are unchanged. If you change values in the collection that originated from a referenced component, syncing those updates causes Postman to replace the reference URL with the updated inline values. ## View live documentation Postman displays a live preview of your API's documentation if you're editing an OpenAPI 3.0 or AsyncAPI 2.0 specification. ## Validate a component file Postman identifies syntax errors as you edit your component file. Syntax errors can include missing fields, malformed field names, wrong data types, wrong nesting, or other issues. Postman also identifies governance issues for components referenced in your specification. Governance issues are violations of the [Postman API Governance](/docs/api-governance --- # Write scripts to test API response data in Postman You can use post-response scripts in Postman to run JavaScript after a request runs. By including code in the **Scripts > Post-response** tab for a request, collection, or folder, you can write and validate API tests. You can also use post-response scripts for debugging your tests. ## Testing in Postman Some of the most common approaches to [API testing](https://www.postman.com/api-platform/api-testing/) are contract testing, unit testing, end-to-end testing, and load testing. Tests confirm that your API is working as expected, that integrations between services function reliably, and that any changes haven't broken existing functionality. You can write tests for your Postman API requests in JavaScript in the **Post-response** tab. You can also use test code to aid the debugging process when something goes wrong with your API project. For example, you might write a test to validate your API's error handling by sending a request with incomplete data or wrong parameters. The **Pre-request** and **Post-response** tabs use the Postman Sandbox, a runtime based on Node.js that enables you to add dynamic behavior to requests and collections. * The **Scripts > Pre-request** tab enables you to do any processing needed before sending a request, like setting variable values. Any code here runs before the request is sent. To learn more, see [Write pre-request scripts to add dynamic behavior in Postman](/docs/tests-and-scripts/write-scripts/pre-request-scripts/). * The **Scripts > Post-response** tab provides for any post-processing after a request is sent and includes the ability to write tests for assessing response data. The **Post-response** tab has the [Chai.js](https://www.chaijs.com/api/bdd/) library built in, so you can use Chai's behavior-driven development (BDD) syntax to create readable test assertions. Select ![Image 1: Code icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-code-stroke.svg#icon) **Snippets** at the lower right of the code editor to view a list of test snippets. You can search for and select snippets to inject pre-written blocks of code. Some will help you retrieve data from variables, some are boilerplate tests, and some perform common utility functions. You can also ask Postman's AI assistant Postbot to [write tests for you](#write-tests-using-postbot). ## Add a post-response test You can add tests to [requests](/docs/sending-requests/create-requests/create-requests/), [collections](/docs/sending-requests/create-requests/intro-to-collections/), and folders in a collection. Postman includes code snippets you add and then change to suit your test logic. To add a test, open the request, collection, or folder and enter your code in the **Scripts > Post-response** tab. You can write your own JavaScript. You can also select ![Image 2: Code icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-code-stroke.svg#icon) **Snippets** at the lower right of the code editor and select a snippet. To make your code more readable, you can select ![Image 3: Pretty icon](https://assets.postman.com/postman-docs/aether-icons/action-pretty-stroke.svg#icon) **Beautify** in the lower right of the code editor. Post-response scripts can use dynamic variables, carry out test assertions on response data, and pass data between requests. Tests run after the request runs and a response is received from the API. The output appears in the response's **Test Results** tab. In the **Test Results** tab, you can click ![Image 4: Refresh icon](https://assets.postman.com/postman-docs/aether-icons/action-refresh-stroke.svg#icon) **Refresh results** in the upper right of the response pane to refresh your test results. This gives you the option to refresh your test results without re-sending the request. ![Request Test Tab](https://assets.postman.com/postman-docs/v11/request-test-tab-v11.45.1.jpg) Your scripts can include as many tests as you need and will be saved along with the request details when you select ![Image 5: Save icon](https://assets.postman.com/postman-docs/aether-icons/action-save-stroke.svg#icon) **Save**. If you share a collection, publish documentation, or use the **Run in Postman** button, your test code will be included for anyone who views or imports your collection. ### Add a test to a gRPC request You can add tests to a gRPC request before invoke, when the client receives a message, or after response. All hooks are available for all gRPC requests regardless of the method type (unary, client streaming, server streaming, or bidirectional streaming). To add a test to a gRPC request, do the following: 1. Go to the **Scripts** tab in your gRPC request. 2. Select the hook (**Before invoke**, **On message**, or **After response**) you want to add a test to. 3. Select ![Image 6: Code icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-code-stroke.svg#icon) **Snippets** at the lower right of the code editor to add a test. You can also write a custom assertion. When you select **Invoke**, tests run before, during, or after the request is invoked. Once you invoke your gRPC request, updates to scripts in the **On message** tab won't take effect until the next time you invoke the request. If you select **Cancel**, the request and any further script runs are stopped. If there are any errors in your **Before invoke** script, the request will stop. ## Validate responses To validate the data returned by a request, you can use the `pm.response` object in a test. Define tests using the `pm.test` function. Provide a name and function that returns a boolean (`true` or `false`) value to indicate if the test passed or failed. Use Chai.js BDD syntax and `pm.expect` in your assertions to test the response detail. The first parameter for the `.test` function is a text string that appears in the test result output. Use this to identify your tests and communicate the purpose of a test to anyone viewing the results. For example, enter the following in the **Post-response** tab of a request to test if the response status code is `200`: ```js pm.test("Status test", function () { pm.response.to.have.status(200); }); ``` Select **Send** to run your request, then select the **Test Results** tab in the response. The tab header displays how many tests passed and how many ran in total. You can also select the **Filter Results** dropdown list to view the test results by type: **Passed**, **Skipped**, and **Failed**. If the request returned a `200` status code, the test passes. To find out what happens with a different status code, change the expected status code in your post-response script and run the request again. ## Format test result messages using pm.expect Using the `pm.expect` syntax gives your test result messages a different format. Experiment with the options to get the output you find most useful. Fork the [Intro to writing tests collection](https://www.postman.com/postman/postman-team-collections/collection/9fqcfpk/intro-to-writing-tests-with-examples?action=share&creator=16724969) to import templates containing some example post-response scripts into Postman and experiment with the code. Your code can test the request [environment](/docs/sending-requests/variables/managing-environments/), as in the following example: ```js pm.test("environment to be production", function () { pm.expect(pm.environment.get("env")).to.equal("production"); }); ``` You can use different syntax variations to write your tests in a way that you find readable, and that suits your application and testing logic. For example: ```js pm.test("response should be okay to process", function () { pm.response.to.not.be.error; pm.response.to.have.jsonBody(""); pm.response.to.not.have.jsonBody("error"); }); ``` Your tests can validate request responses using syntax that you tailor to the response data format. For example: ```js pm.test("response must be valid and have a body", function () { pm.response.to.be.ok; pm.response.to.be.withBody; pm.response.to.be.json; }); ``` ## Test collections and folders You can add post-response scripts to a collection, a folder, or a single request within a collection. A post-response script associated with a collection will run after every request in the collection. A post-response script associated with a folder will run after every direct child request in the folder. This enables you to reuse commonly run tests after requests. The run order for each request will be collection tests, folder tests and then request tests. You can also [store post-response scripts in the Postman Package Library](/docs/tests-and-scripts/write-scripts/packages/package-library/). This enables you to maintain commonly used scripts and tests in a single location, share them with your team, and reuse them in your internal workspaces. Adding scripts to collections and folders enables you to test the workflows in your API project. This helps to ensure that your requests cover typical scenarios, providing a reliable experience for application users. To add or edit collection and folder tests, select a collection or folder in the sidebar, then select the **Scripts > Post-response** tab. When you [run a collection](/docs/collections/running-collections/intro-to-collection-runs/), the collection runner displays the results for all tests. The test results include the response time in milliseconds and details about whether a specific request in the collection passed or failed its tests. ![Collection Tests](https://assets.postman.com/postman-docs/v11/collection-tests-run-v11.45.1.jpg) You can write scripts to control the order in which your requests run using [branching and looping](/docs/collections/running-collections/building-workflows/). ## Write tests using Postbot You can use Postman's AI assistant [Postbot](/docs/getting-started/basics/about-postbot/) to write tests for your requests. Tell Postbot what to do in natural language, and Postbot generates post-response scripts for you. Use Postbot to add a new set of tests, visualize responses, save a field from a response, or fix your existing tests. To write tests with Postbot, do the following: 1. Open a request and select **Send** so it has a response. 2. Select the **Scripts > Post response** tab. 3. (Optional) Select code you'd like Postbot to help with. 4. Select ![Image 7: Postbot icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-postbot-stroke.svg#icon) **Open Postbot** in the code editor. You can also select **Control+Option+P** or **Ctrl+Alt+P** to open Postbot. 5. Tell Postbot what you want to do and select **Enter**. ![Write tests with Postbot](https://assets.postman.com/postman-docs/v11/postbot-write-tests-v11-41.jpg) You can also work with Postbot in the following ways: * Postbot can offer suggestions based on your request and the response data. Select the down arrow (↓) on your keyboard and select one of Postbot's suggestions. ![Get test suggestions from Postbot](https://assets.postman.com/postman-docs/v11/postbot-test-suggestions-v11-41.jpg) * Postbot understands context. Select part of a script or the response body, then tell Postbot what you want to do or change based on the selection. ![Postbot understands context](https://assets.postman.com/postman-docs/v11/postbot-test-context-v11-41.jpg) * You can also select part of a JSON response, right-click, then select ![Image 8: Postbot icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-postbot-stroke.svg#icon) **Use Postbot**. You can tell Postman to generate tests based on the selection. For example, go to a response, select a property, and ask Postbot to generate a test to verify that it exists. Or select specific values in a response and ask Postbot to visualize only that data. ![Postbot understands context](https://assets.postman.com/postman-docs/v11/postbot-inline-response-v11.45.1.jpg) * Postbot also powers autocomplete in the post-response script editor. If you’ve [enabled Postbot](/docs/getting-started/basics/about-postbot/#get-started-with-postbot), you’ll see code suggestions as you type. Select the **Tab** key to accept the suggestion. If you’ve already paid for Postbot, you get unlimited suggestions and acceptances. For everyone else, feature usage is capped at 200 suggestion acceptance events per month. To learn more about what you can do with Postbot, go to [About Postbot](/docs/getting-started/basics/about-postbot/). ## Add documentation to post-response scripts Postman supports JSDoc for documenting JavaScript functions in your post-response scripts. Documentation added to your functions using JSDoc will display in a popup window when you call your functions. You can use the official [JSDoc documentation](https://jsdoc.app/) to learn how to add documentation to your post-response scripts. The following example has documentation for the `logger` function using JSDoc. The documentation explains what the function does, and defines what the `data` parameter is used for and that it accepts a string data type. ```js /** * This function prints a string to the Postman Console. * @param {string} data - The text to print to the Postman Console. */ function logger(data) { console.log(`Logging information to the console, ${data}`) } ``` ## Debug your tests If you're having trouble with your tests, do the following: * Check if there are any errors in your scripts. A red underline will highlight possible errors. Hover over the error and select **View Problem** to get help. You can also check the response viewer for specific errors. * Debug your tests using [log statements](/docs/sending-requests/response-data/troubleshooting-api-requests/#using-log-statements) to ensure that you are asserting on correct data. ## Next steps After writing your first tests in Postman, you can write more complex tests and use them with other Postman tools. * For more information about what you can do with the `pm` object, check out some post-response script [examples](/docs/tests-and-scripts/write-scripts/test-examples/) and visit the [Postman Sandbox API reference](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/). * To learn how to use tests with Postman Monitors and check the health and performance of your API, go to [Monitor health and performance of your APIs in Postman](/docs/monitoring-your-api/intro-monitors/). * To learn how to [automate your testing](https://www.postman.com/api-platform/api-test-automation/) by integrating collection runs within your CI/CD configuration, go to [Integrate CI tools in Postman](/docs/integrations/ci-integrations/). * For more information about storing and reusing commonly used scripts and tests, learn about [the package library](/docs/tests-and-scripts/write-scripts/packages/package-library/) in Postman. --- # Debug API requests in Postman If an API request isn’t behaving as expected, there can be many possible reasons. You can ask Postbot to help you find out what the problem is, or use the Postman Console to troubleshoot the request. This guide also lists some common issues and their causes. ## Troubleshooting your requests Postman indicates any whitespace or invalid characters in parts of your request that may not function as expected so that you can fix your values. Invalid characters are highlighted in the request method, URL (including the path), parameters, headers (including your key names), and body. ![Invalid Characters](https://assets.postman.com/postman-docs/v11/invalid-character-message-v11.jpg) If Postman isn’t able to send your request or doesn’t receive a response, you’ll get a message with details about the error. Select **View in Console** to get an overview of your request and to help identify the source of the issue. ## Debugging requests with Postbot If you get an unexpected error when you send a request, you can ask Postbot for help. Click **What’s wrong?** in the error message. Postbot tells you about any problems it can identify, and offers possible solutions for fixing the issue. For more information on Postbot, see [About Postbot](/docs/getting-started/basics/about-postbot/). ![Debug a request with Postbot](https://assets.postman.com/postman-docs/v11/postbot-debug-request-v11.jpg) ## Debugging in the Console Console logs are stored locally in the Postman Console and aren’t synced to the cloud. Every request sent by Postman is logged in the Postman Console, so you can view the detail of what happened when you sent a request. This means you can use the Console to help debug your requests when an API isn’t behaving as you expect. Keeping the Console open while you work increases the visibility of your network calls and log messages while debugging. The Postman Console logs the following information: - The primary request that was sent, including all underlying request headers, variable values, and redirects. - The proxy configuration and certificates used for the request. - Network information, such as IP addresses, ciphers, and protocols used. - Log statements and asynchronous requests from pre-request or post-request scripts. - The raw response sent by the server before it’s processed by Postman. Monitor results are logged to a separate console. For more information on how to view logs from a monitor run, see [View monitor results](/docs/monitoring-your-api/viewing-monitor-results/#console-log). ### Opening the Console Click **Console** in the Postman footer to open the Console. In the Postman desktop app, use **⌘+Option+C** or **Ctrl+Alt+C** to open the Postman Console in a new window. ### Viewing request errors from the Console You’ll get an error message if Postman isn’t able to send your request or doesn’t receive a response from the API you sent the request to. This message includes an overview of the issue and a link to the Console. There you can access detailed information about the request. Select **View in Console** to inspect the request details in the Console and find out more about what went wrong. ![Error in Console](https://assets.postman.com/postman-docs/v10/console-pane-opened-from-response-v10-22.jpg) ### Navigating the Console The Postman Console displays network information and the request and response headers and body for each request, together with any Console output messages coming from your scripts. Filter by log message type under **All Logs**. Click **Options** to turn timestamps and network information on or off. ![Console options](https://assets.postman.com/postman-docs/v11/console-pane-log-options-v11.jpg) The Console logs the last 5,000 messages and 24 hours by default. Select **Clear** to empty the list. ### Using log statements Using log statements at appropriate locations in your post-response scripts can help you debug your requests. Postman accepts the following log statements: - `console.log()` - `console.info()` - `console.warn()` - `console.error()` - `console.clear()` ## Debugging by HTTP version You can specify the HTTP version to use for requests. Postman supports HTTP versions 1.0, 1.1, and 2.0. The HTTP version you select is the default version you’ll use globally to send HTTP requests. You can override the default version for an individual request. It’s useful to specify an HTTP version when debugging API requests so you can test requests by version. It’s also useful for verifying if API requests support the expected HTTP version. If the API supports HTTP version 2.0, make sure the request URL uses the `https` scheme. If you’re using the Postman web app, also make sure you send requests with the [Postman Desktop Agent](/docs/getting-started/basics/about-postman-agent/#postman-desktop-agent). The supported 1.x HTTP version is used in the following scenarios: - The request URL uses the `http` scheme. - The request is sent with the [Postman Cloud Agent](/docs/getting-started/basics/about-postman-agent/#postman-cloud-agent). - You’ve configured Postman to use a [proxy server](/docs/getting-started/installation/proxy/). Postman recommends you [use the latest version](/docs/getting-started/basics/about-postman-agent/#update-the-postman-desktop-agent) of the Postman Desktop Agent to receive recent changes and improvements. To specify an HTTP version for your requests, do the following: 1. Click **Settings** in the header, then click **Settings** to specify an HTTP version globally. You can also specify the version for an individual HTTP request by opening it, then clicking the **Settings** tab. 2. Select the HTTP version dropdown list next to **HTTP Version**. 3. If you specify an HTTP version for an individual request, you can select **Restore Default**. This changes the HTTP version to the default version specified globally. 4. Select one of the following options: - **Auto** - Postman automatically selects HTTP version 1.0, 1.1, or 2.0, depending on which version the API supports and prefers. - **HTTP/1.x** - Send the request using HTTP version 1.0 or 1.1. - **HTTP/2** - Send the request using HTTP version 2.0. If the API doesn’t support the HTTP version you selected, an error displays in the response area. For example, the error will display if you select **HTTP/2** and the API doesn’t support HTTP version 2.0. After you send a request, you can verify the HTTP version in the response pane. Hover over **Network** to view information about the HTTP version that was used to send the request. ![Hover over the network icon for network information](https://assets.postman.com/postman-docs/v11/https-network-info-response-v11.23.jpg) ## Comparing your request's history If your HTTP request isn’t behaving as expected, you can view a previous configuration from the request’s history to help you troubleshoot. You can only view the response for a previous request configuration if [saving response history](/docs/getting-started/basics/navigating-postman/#saving-responses-in-history) was turned on when you sent the request. You can also delete a response from your request’s history. The HTTP request must be in an internal or Partner Workspace. Postman doesn’t support viewing an earlier configuration of a request and its response from public workspaces. Also, partners in [Partner Workspaces with multi-partner mode enabled](/docs/collaborating-in-postman/using-workspaces/partner-workspaces/multipartner-workspaces/) can’t view an earlier configuration of a request and its response. To view a previous request configuration and its response, do the following: 1. Click **Collections** in the sidebar and open an HTTP request. 2. Click **History** in the response area. This displays a list of the sent request’s timestamps and the status code the system returned. When you select a previous response from the **History** dropdown list, the date and time you sent the request displays in the response area. Select the date and time to display the dropdown list again, then choose a different response. You can select **Current** to return to the latest version of the request configuration. ![Select a request and response from your history](https://assets.postman.com/postman-docs/v11/select-request-from-history-v11-18.jpg) 1. Select a response from the dropdown list to view it and the request configuration. To delete a request and its response from your history, do the following: 1. Select **Collections** in the sidebar and open an HTTP request. 2. In the response area, click **History**. 3. Next to a response in the dropdown list, click **Options** > **Delete**. You can also [share a link](/docs/collaborating-in-postman/sharing/#share-a-request-with-its-response) to an HTTP request and its response with your team members or external partners. Share a link to the current response or a previous response from the request’s history, along with the request configuration. ## Common issues If your issue with sending a request isn’t listed here, see [Getting help](#getting-help) for information on how to contact Postman support. | Issue | Resolving the issue | | --- | --- | | **Connectivity** | If Postman fails to send your request, you may be experiencing connectivity issues. Check your connection by attempting to open a page in your web browser. | | **Firewalls** | Some firewalls may be configured to block non-browser connections. If this happens, you’ll need to contact your network administrators for Postman to work. | | **Proxy configuration** | If you’re using a proxy server to make requests, check your configuration. By default, Postman uses the proxy settings configured in your operating system’s network settings. The [Postman Console](#debugging-in-the-console) provides debugging information regarding proxy servers. | | **SSL certificates** | You may experience issues using HTTPS connections. You can turn off **SSL certificate verification** in [Settings](/docs/getting-started/installation/settings/) by clicking **Settings** in the header, then **Settings > General**. If that doesn’t help, your server might be using a client-side SSL connection, which you can configure by clicking **Settings** in the header, then **Settings > Certificates**. Use the [Postman Console](#debugging-in-the-console) to ensure that the correct SSL certificate is being sent to the server. Learn more about [working with certificates](/docs/sending-requests/authorization/certificates/). | | **Client certificates** | Client certificates may be required for your API server. You can [add a client certificate](/docs/sending-requests/authorization/certificates/) in [Settings](/docs/getting-started/installation/settings/) by clicking **Settings** in the header, then **Settings > Certificates**. | | **Wrong request URLs** | If you’re using variables or path parameters with your request, make sure the final address is correct by opening the [Postman Console](#debugging-in-the-console), which displays the URL your request was sent to when it runs. Unresolved request variables can result in invalid server addresses. | | **Wrong protocol** | Check if you’re using “https://” instead of “http://” in your URL (or the opposite). | | **Short timeouts** | If you configure a short timeout in Postman, the request could be timing out before completion, resulting in an error. To avoid this issue, increase the **Request timeout** in [Settings](/docs/getting-started/installation/settings/) by clicking **Settings** in the header, then **Settings > General**. | | **Invalid responses** | If your server sends the wrong response encoding errors, or invalid headers, Postman may fail to interpret the response. | | **TLS version** | Postman supports TLS version 1.2 and higher, which [may not be supported if you’re using an older browser or operating system](https://support.postman.com/hc/en-us/articles/360041392573-Deprecating-TLS-1-0-and-TLS-1-1). | | **Postman errors** | It’s possible that Postman might be making invalid requests to your API server. You can confirm this by checking your server logs, if available. If you believe this is happening, contact the Postman team using the [GitHub issue tracker](https://github.com/postmanlabs/postman-app-support/issues). | | **Empty variables** | An empty variable is a variable that doesn’t have a value and is referenced in a request. For more information on why this happens and how to solve the problem, see [Fixing empty variables](/docs/sending-requests/variables/variables/#fixing-empty-variables). | | **CORS** | If the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app) fails to send your request, you may be experiencing a cross-origin resource sharing (CORS) error. Make sure you’re using the best [Postman Agent](/docs/getting-started/basics/about-postman-agent/) for your request. | ## Getting help If you’re still having problems with your request, there are options for you to get help: - Ask for community help in the [Postman forum](https://community.postman.com/). - If you think the problem is with Postman itself, search the [issue tracker](https://github.com/postmanlabs/postman-app-support/issues) on GitHub to check if someone has already reported the issue and whether there is a known solution. - If you need to include confidential data, file a support ticket with [Postman support](https://support.postman.com/hc/en-us), including your Console logs. --- # use-collections-overview Create and manage request collections in Postman ----------------------------------------------- A collection is one of the fundamental elements in Postman. Use collections to save all your API requests, keep them organized, and find them when you need them. When you're ready, you can share your collections with other members of your team–or anyone in the world. ## Create new collections Create a new Postman Collection to save requests you use often, or to group requests for a specific purpose, such as testing APIs or simulating workflows. You can create a collection from scratch or from one of Postman's predefined templates. To learn more, go to [Create collections of API requests in Postman](/docs/collections/use-collections/create-collections/). ## Add API requests You can save new API requests to a collection, or move existing requests into a collection. A collection can contain HTTP requests, or you can create a multi-protocol collection with other types of requests, such as GraphQL or gRPC. To learn more, go to [Add API requests to Postman Collections](/docs/collections/use-collections/add-requests-to-collections/). ## Keep your collections organized You can arrange the API requests in a collection in any order you choose, or add folders to group requests together. If you make a change you don't like, or delete a collection by mistake, you can restore it back to an earlier state. To learn more, go to [Manage and organize Postman Collections](/docs/collections/use-collections/manage-collections/). ## Collaborate with others You can share collections to invite others to collaborate with you, or watch a collection to get notified about changes. Tag collections to make them easier for others to find, and add comments to a collection to let others know what you're thinking. You can also apply status tags to a collection to show its lifecycle status. To learn more, go to [Share and collaborate on Postman Collections](/docs/collections/use-collections/collaborate-with-collections/). ## Create Organization Teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then select [Teams](https://go.postman.co/settings/team/teams). 2. Click **Create Team**. 3. Name your team. The team will be taggable in the mentions using `@`, for example, `@api-developers`. 4. Click **Add Members**. To be added, members need to be part of the organization. 5. Determine how restricted the Team access should be. All Organization Teams have two [settings](/docs/administration/organization/settings/): * **Allow anyone from the Organization to join as a Member, or require Team Manager approval to join** – Turn on if you want to strictly control access to Teams and tightly control the team's membership. Environments open to collaboration don't necessarily require this level of control. * **Allow anyone on the Team to share content with the larger Organization, or require Team Manager approval to share outside the Team** – Turn on if your Postman Organization belongs to a highly regulated industry, or you have teams working on sensitive content where the sharing of content must be strictly controlled. 6. Populate the team with the members who are responsible for the team’s contents. 7. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 8. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 9. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default-policy-11-1.jpg) To reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Click **Reset Workspaces**. 3. Review the listed changes to each workspace type (**Public**, **Partner**, and **Internal**). 4. Click **Apply to all** to confirm your changes. This resets all workspaces to use the default policy for the displayed workspace types and removes any custom overrides. ### Update secret protection policies To update a workspace's secret protection policy, do one of the following: * To update the policy of a single workspace, select a policy from the **Policy** dropdown list next to the workspace. * To update the policy of multiple workspaces, select the workspaces or select the checkbox next to the **Workspace** column, then select a policy from **Select policy** dropdown list. * The policy you select is automatically applied to the selected workspaces. ## View secret scan metrics The **Local Protection** report in the Secret Scanner's **Reports** dashboard enables your Team Admins to view Local Secret Protection metrics. This includes automatic resolutions and user-requested overrides. To access the report, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Reports** tab. 3. The report provides metrics about the Secret Scanner's real-time secret management in a given period of time, such as: * The total number of detected secrets automatically moved to the Postman Vault. * The total number of user Secret Scanner policy overrides. Team Admins can click the number of overrides in the **Secrets Count** column to view details about override justifications created by users. Learn more about: [the Secret Scanner dashboard](/docs/reports/secret-scanner-reports/). ## Enable Local Secret Protection To enable Local Secret Protection in Postman, do the following: 1. Click **Team > Team Settings** in the Postman header, then click **Secret Scanner** in the left sidebar. 2. In **Secret Scanner**, select the **Local Protection** tab. 3. Turn on **Local secret protection**. Once enabled, you can configure how Postman stores exposed secrets in your team's workspaces. By default, all workspaces use the **No policy** option and store detected secrets in the Postman cloud. However, Team Admins can change the [default storage behavior](#set-default-protection-policies-for-new-workspaces). Users can't turn off secret policies, but can submit justifications to Team Admins to override any detected secrets. ### Set default protection policies for new workspaces You can customize how Local Secret Protection manages exposed secrets in your team's workspaces. Define a policy for specific types of workspaces, and all new workspaces automatically inherit the policy you choose. You can reset the policy for workspaces to their default, do the following: 1. Click **Set default policies**. 2. Select **No policy** or the **Move to vault** policy for the **Public**, **Partner**, and **Internal** workspace types. 3. Click **Save**. ![Set default detection policies for workspace types](https://assets.postman.com/postman-docs/v11/local-secret-detection-set-default --- # Collaborate with your team in Postman Collaborate with others in Postman using internal workspaces. You can [find a team](#find-teams-within-your-organization) within your organization or [join by other means](#join-a-team) enabled by your organization. If you sign up for a Postman free plan as an individual user, you can create a team during Postman onboarding or later, where up to three users can work together at no cost. When you join a team in Postman, you can either move your workspaces and transfer ownership to the team or keep your workspaces separate and maintain ownership in your account. The decision to join a team affects your account in the following ways: - When you move your workspaces to a team, your account will no longer exist. You'll have the option to switch between teams, rather than work in an account. - When you keep your workspaces, you'll retain your account. You can switch between the team and your account at any time. In certain cases, your workspaces and the data within them automatically transfer when you join a team. For more information, see [Join a team](#join-a-team). When you [leave a team](#leave-a-team), a [Postman account](/docs/getting-started/account/overview/) is created for you, if you don't already have one. If you're deactivated through [SCIM (System for Cross-domain Identity Management)](/docs/administration/scim-provisioning/scim-provisioning-overview/) but are a member of other teams, you'll keep access to your account and other teams to which you belong. If you aren't a member of any other team and don't have an account, you won't be able to authenticate and will need to [contact support](https://www.postman.com/support/). ## Find teams within your organization When you first join Postman using your company email address on a Free, Basic, or Professional plan, Postman lists the teams you can join within your organization. Select **Show More** to see the full list of teams. ![Join a team from your organization](https://assets.postman.com/postman-docs/v10/join-team-discovery-v10.15.jpg) Thereafter, your Postman homepage will show discoverable teams you can join. Select **View all teams** to see the full list of teams. ![Join a team from your homepage](https://assets.postman.com/postman-docs/v11/join-team-discovery-homepage-v11.28.jpg) You can also view all discoverable teams from your profile settings, under **Teams**. ![Discover teams in your profile settings](https://assets.postman.com/postman-docs/v11/discoverable-teams-v11.28.jpg) Select **Join** next to a team. If a Team Admin has set a mandatory question, answer the question and select **Submit**. ![Request to join team](https://assets.postman.com/postman-docs/v11/request-to-join-team-team-discovery-v11.28.jpg) When the Team Admins approve your request, you'll be able to access the team and collaborate on API projects within it. ## Join a team There are several ways you can join a Postman team: - **Email invite** - Select **Join Team** in the email invite. Create a new Postman account or sign in to an existing one. After signing in, you'll be redirected to your new team. - **Invite link** - Open the link and select **Accept Invite**. Create a new Postman account or sign in to an existing one. After signing in, you'll be redirected to your new team. - **Team discovery** - You can [find teams to join within your organization](#find-teams-within-your-organization). - **Team Request for Access (RFA)** - If you access a link to a resource (for example, a collection or request) from a team you aren't a member of, you can select to request access to that team. An Admin will need to approve your request. If enabled in the team settings on Free, Basic, and Professional plans, you can automatically join a team using a shared link. For more information, see [Manage team access through shared resources](/docs/collaborating-in-postman/requesting-access-to-elements/#manage-team-access-through-shared-resources). - **SSO automatic provisioning** - If a team in your organization has [automatic provisioning](/docs/administration/sso/admin-sso/#automatically-add-new-users) enabled in their SSO configuration, you can join the team by [signing in to Postman with SSO](/docs/administration/sso/user-sso/). - **SCIM provisioning** - If your organization has enabled [SCIM provisioning](/docs/administration/scim-provisioning/scim-provisioning-overview/), you may be added to your organization's Postman team and receive an email invite. Select **Join Team** in the email and [sign in to Postman with SSO](/docs/administration/sso/user-sso/). - **Domain capture** - If your organization has configured [domain capture](/docs/administration/domain-verification-and-capture/domain-capture-overview/) and you use or create an account associated with a verified domain, Postman will [notify](/docs/administration/domain-verification-and-capture/enable-domain-capture/#user-experience) you when you next sign in that your account is managed by your organization. You can be a member of up to ten Postman teams, regardless of whether they're on the free, Basic, Professional, or Enterprise plan. However, if an Enterprise team within your organization implements domain capture, you won't be able to remain on or join extra Postman teams with your captured accounts. If you have an account and join a team, you can choose to transfer your workspaces and the data within them to the team or keep them separate. In the following cases, your workspaces and the data within them automatically transfer when you join a team: - If you [request to join a team](/docs/collaborating-in-postman/use-teams/#join-a-team) and are approved by a Team Admin. - If the team has [SCIM provisioning](/docs/administration/scim-provisioning/scim-provisioning-overview/) enabled. - If the team has [domain capture](/docs/administration/domain-verification-and-capture/domain-capture-overview/) enabled. When you join an Enterprise team, [Super Admins](/docs/administration/roles-and-permissions/#team-roles) have access to all workspaces you transfer over and any you create within the team moving forward. When you leave a team, your workspaces within the team and their data will remain with the team and no longer be available to you in some situations. See [Leave a team](#leave-a-team) for details. Workspaces in a team refers to workspace visibility and not data ownership. ## Switch between teams If you belong to multiple teams, you can sign in to them at the same time with your Postman account. To switch between teams, select your avatar in the top right. Select a team to open. ![Switch teams](https://assets.postman.com/postman-docs/v11/team-account-switcher-v11.jpg) If you're a member of two or more teams, you can also select \[img alt="Add icon" src="https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon"\] **Create Team** to create a new team. If you have an account, switch to it by selecting your avatar in the top right. Then select your avatar and username labeled **Individual**. ![Switch accounts](https://assets.postman.com/postman-docs/v11/individual-account-switcher-v11.jpg) ## Leave a team You can leave a Postman team by selecting your avatar in the top right, then **Settings**. Select **Teams** on the left. Select **Leave** to the right of a team to leave it. If you're a member of an Enterprise team that has [SCIM configured](/docs/administration/scim-provisioning/scim-provisioning-overview/), you must contact a Team Admin to remove you from the team. ![Leave team](https://assets.postman.com/postman-docs/v11/dashboard-teams-leave-team-v11.67.png) When you leave a team, you no longer have access to the team's workspaces or any of the elements in them. However, you can keep any workspaces you created for your access only in a new team that'll be created for you. If you don't have an individual non-team account, then an individual non-team account is created for you. ![Keep personal workspaces after you leave team](https://assets.postman.com/postman-docs/v11/leave-team-personal-v11.67.png) If you're a member of an Enterprise team, you must reassign your team workspaces to a remaining team member before leaving. ![Leave team and keep personal data](https://assets.postman.com/postman-docs/v11/leave-team-keep-personal-data-confirmation-v11.67.png) If you were on a Free, Basic, or Professional team, and you don't have an account, when you leave a team, you can choose to move your workspaces and the associated data to a new account. ![Leave team and keep personal data](https://assets.postman.com/postman-docs/v11/leave-team-keep-personal-data-confirmation-v11.67.png) If you're the last member to leave a team, the team will be deleted. You'll no longer have access to the team's workspaces, including workspaces set to be accessed by you only, or any elements in them. Team Admins or Super Admins can [export a data dump](/docs/getting-started/importing-and-exporting/exporting-data/) prior to leaving the team to retain the data. --- # Use Postman workspaces When you first open Postman, you'll land in your default internal workspace. You can [create more workspaces](/docs/collaborating-in-postman/using-workspaces/create-workspaces/) for your use and to work with teammates. To create more workspaces, you need to sign in to your [Postman account](/docs/getting-started/account/overview/). After you access your workspace, you can [tag](#tag-a-workspace), [favorite](#favorite-and-discover-a-workspace), and [connect](#connect-your-workspace-to-internal-team-channels) your workspace to team channels. You can also select to [watch](#watch-a-workspace) a workspace, [pin collections](#pin-collections-to-workspaces), check your [workspace activity](#view-workspace-activity), and more. ## Access a workspace To open a workspace, select **Workspaces** in the Postman header. Select a workspace to open it, or select **View all workspaces** for a list of all available workspaces. This will only display workspaces that you have access to, based on the [workspace visibility](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#change-workspace-visibility) and your [workspace role](/docs/administration/roles-and-permissions/#workspace-roles). ![New Workspace](https://assets.postman.com/postman-docs/v11/view-workspaces-v11.74.png) The workspace's **Overview** tab displays a description and summary of the workspace, and any [pinned](#pin-collections-to-workspaces) collections. On the right, you'll find a list of workspace contributors and the option to [view workspace activity](#view-workspace-activity). If you decide to make your workspace public, you can add [featured](/docs/collaborating-in-postman/using-workspaces/public-workspaces/#feature-collections-in-public-workspaces) collections. ![Workspace overview](https://assets.postman.com/postman-docs/v11/workspace-overview-v11-19.jpg) To learn more about access management, go to [Request and approve access to Postman resources](/docs/collaborating-in-postman/requesting-access-to-elements/). ## Tag a workspace Tagging workspaces is available with [Postman Enterprise plans](https://www.postman.com/pricing/). You can apply shared tags to workspaces, collections, and APIs. Tags must be between two and 64 alphanumeric characters, starting with an alphabetical character, and contain only dashes and no spaces. You can add up to five tags. Adding shared tags to workspaces enables you to organize and search for workspaces. Once you add tags to the workspace, you can select a tag to open search results associated with the tag in a new tab. To learn more about searching using tag names in Postman, see [Search Postman](/docs/getting-started/basics/navigating-postman/#search-postman). You can use tags when searching [elements in your Private API Network](/docs/collaborating-in-postman/private-api-network/use-private-network/#search-filter-and-sort). You can also use tags to search for [elements to add](/docs/collaborating-in-postman/private-api-network/organizing-private-network/#add-elements-in-your-private-api-network) and [elements to request to add](/docs/collaborating-in-postman/private-api-network/private-network-requests/#request-to-add-elements-in-your-private-api-network) to your Private API Network. To add tags to a workspace, do the following: 1. Select **Workspaces** in the Postman header, and then select a workspace. 2. On the workspace's **Overview** tab, select the **Tags** field to edit it. ![Add tags to a workspace](https://assets.postman.com/postman-docs/v11/add-tags-workspace-v11.19.png) 3. Select an existing tag or enter a new tag. If you're adding a new tag, enter the new tag name and press **Return** or **Enter**. ![Add new tags to a workspace](https://assets.postman.com/postman-docs/v11/create-new-tags-workspace-v11.19.png) Repeat these steps to add more tags. To remove tags from a collection, do the following: 1. Select **Workspaces** in the Postman header, and then select a workspace. 2. On the workspace's **Overview** tab, select the **Tags** field to edit it. 3. Select ![Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) on the tag. ![Remove tags from a workspace](https://assets.postman.com/postman-docs/v11/remove-tags-workspace-v11.19.png) 4. Select the area outside the **Tags** field to save your changes. ## Favorite and discover a workspace Postman enables you to star and discover workspaces you care about the most. You can preview each workspace from the workspaces dropdown and get the following metadata and options: * Author name, owner, and elapsed activity time * Ability to copy workspace ID, get the workspace link, and star the workspace for easier discovery ![Discover a workspace](https://assets.postman.com/postman-docs/v11/workspace-discoverability-v11.74.png) You can star the workspace from the workspace preview, the top right of the workspace, and the [Workspaces dashboard](https://app.getpostman.com/dashboard). Starred workspaces appear in the top of the list of workspaces in the sidebar and workspace dropdown. ## Connect your workspace to internal team channels Postman integrations for [Slack](/docs/integrations/available-integrations/slack/) and [Microsoft Teams](/docs/integrations/available-integrations/microsoft-teams/) enable you to bring your API development workflow into your team channels. Learn how to connect a Postman workspace to [Slack](/docs/integrations/available-integrations/slack/slack-app/#connect-a-postman-workspace-to-slack) or [Teams](/docs/integrations/available-integrations/teams/teams-app/#connect-a-postman-workspace-to-teams). To subscribe to a channel, click ![Slack icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon) ![Teams icon](https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon) **Connect** in the workspace overview. ## Watch a workspace Watch a workspace to receive an email or in-app notification when a team member modifies the workspace. This includes changing the workspace visibility or updating an element in the workspace. To start watching a workspace, select ![View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon) **Watch** in the workspace's **Overview** tab. Select the count next to **Watch** to access the list of people who are watching the workspace. To access your notifications, select ![Notification icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-notification-stroke.svg#icon) **Notifications** in the Postman header. The notification list shows details about changes to workspaces you are watching. You will also receive an email with information about the change, who made it, and when. To stop watching a workspace, select **Unwatch** in the workspace's **Overview** tab. By default, you are a watcher for any workspace you create. You won't receive notifications for changes you make to a workspace you're watching. You can also watch a [collection](/docs/collections/use-collections/collaborate-with-collections/#watch-a-collection) and an [API](/docs/design-apis/api-builder/managing-apis/#watching-apis) within a workspace to receive a notification when it's modified. ## Pin collections to workspaces You can pin collections to an internal or Partner Workspace for quick access on a workspace's **Overview** tab. If you don't have any collections pinned to your workspace, select ![Pin icon](https://assets.postman.com/postman-docs/aether-icons/action-pin-stroke.svg#icon) **Pin Collections**. Otherwise, select ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add** under **Pinned collections**. Then select the collection you'd like to pin. ![Pinned collection in a workspace](https://assets.postman.com/postman-docs/v11/pinned-collections-v11-12.jpg) You can choose an environment for each pinned collection you'd like to be active when it's opened from the **Overview** tab. The environment will be active in the [environment selector](/docs/sending-requests/variables/managing-environments/#switch-between-environments). If your workspace has pinned collections and you [convert the workspace to a public workspace](/docs/collaborating-in-postman/using-workspaces/public-workspaces/#convert-an-existing-workspace-to-a-public-workspace), the pinned collections will be publicly [featured](/docs/collaborating-in-postman/using-workspaces/public-workspaces/#feature-collections-in-public-workspaces) in the public workspace's **Overview** tab. To remove a pinned collection, hover over the collection and select ![Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon), then select **Remove**. ## Get the workspace ID Sometimes you'll need your workspace ID to perform different actions like copying a workspace or setting up an environment. To copy a workspace ID, do the following: 1. On the workspace's **Overview** tab, select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **Options** and then select **Workspace info**. 2. Select ![Copy icon](https://assets.postman.com/postman-docs/aether-icons/action-copy-stroke.svg#icon) **Copy workspace ID**. You can also view who created the workspace and when the workspace was last updated. ![Workspace ID](https://assets.postman.com/postman-docs/v11/find-workspace-id-v11.jpg) You can also hover over a workspace in the workspace dropdown and copy the workspace ID from the workspace preview. See [Favorite and discover your workspace](#favorite-and-discover-a-workspace) for more information. ## View workspace activity Postman maintains activity feeds for workspaces. You can use it to review create, update, transfer, and delete actions made by you and your team on private and shared elements. You can [access the activity feed in Postman](#access-the-activity-feed-from-postman). The activity feed shows information about who added or removed collections, environments, or elements from the workspace, and users that join or leave the workspace. You can [filter this information](#filter-the-activity-feed) directly within the activity feed. You can also [view who's active in your workspace](#view-who-is-in-your-workspace). You can programmatically access workspace activity feeds with the [Postman API](https://www.postman.com/postman/postman-public-workspace/request/qq0dqop/get-a-workspace-s-activity-feed). ### Access the activity feed from Postman To access the activity feed in Postman, select the workspace name in the upper left. On the right, select ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** \> **Activity log** to review the events that have occurred in the workspace. ### Filter the activity feed Filtering the activity feed enables you to display information directly instead of having to scroll through the feed. You can choose to filter by user or by the Postman element. Select **Reset filters** to clear the filters from the activity feed. * Filtering by a user displays the actions that user carried out. To filter by user, select **People** in the activity feed and select users. You can search for a specific user by entering their name in the search field. The user list only shows users that are part of the workspace, not all team members. * Filtering by element displays the actions carried out on the selected element type. The available elements are **Workspace**, **API**, **Collection**, **Environment**, **Monitor**, **Mock servers**, **Specification**, and **Flows**. To filter by element, select **Elements** at the top of the activity feed and select elements. You can search for an element by entering its name in the search field. ### Export team activity to other platforms With a Postman Basic, Professional, or Enterprise account, you can send team activity feeds to external communication channels: * [Slack](/docs/integrations/available-integrations/slack/) * [Microsoft Teams](/docs/integrations/available-integrations/microsoft-teams/) ## View who is in your workspace The list of avatars in the Postman header shows you who's active in your workspace. If you're in an internal workspace, this list includes all active team members. The list also includes all team members who are inactive, but have visited the workspace before. If you're in a public workspace, this list includes all active users with [public profiles](/docs/getting-started/installation/postman-profile/#make-your-profile-public). It also includes users who've chosen to remain anonymous by not enabling their public profile. ![Active users in public workspace](https://assets.postman.com/postman-docs/v11/presence-public-workspace-v11.jpg) --- # user-groups Organize users into Postman groups ================================== **[Groups are available with Postman Enterprise plans.](https://www.postman.com/pricing/)** With Postman groups, you can arrange users into groups that reflect your organizational structure. You can add users to a group, then assign that group roles and access to the resources they'll be using across Postman. You can also efficiently onboard new team members by adding them to existing groups in your organization, instantly giving them access to the elements they'll be working on. Groups enable you to control access from a single dashboard in Postman and manage it at scale across your Enterprise team. [Admins and Super Admins](/docs/administration/roles-and-permissions/#team-roles) can create, manage, and delete groups. [Developers](/docs/administration/roles-and-permissions/#team-roles) can also create, manage, and delete Developer-only groups. ## Creating a group To create a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left, then **Create Group**. ![Image 1: Create group](https://assets.postman.com/postman-docs/v10/team-dashboard-manage-groups-v10.15.jpg) Give your group a name and description, and add your group members. If you're an Admin or Super Admin, you'll also have the option to select the team roles you'd like to assign to the group. If you're a Developer, you'll only have the option to create Developer-only groups. ![Image 2: Create a group](https://assets.postman.com/postman-docs/v10/create-a-group-v10.15.jpg) When you're ready, select **Create Group**. Team members will receive an email and in-app notification when added to a group. If you add a user with a support-only role (Admin or Billing) to a group that gives them a Developer role, they will automatically take up an available paid seat on your Postman team. If no seats are available, you won't be able to grant access to the group with that user. ## Managing a group You can manage a group's members, roles, and access to Postman elements. ### Managing members of a group [Admins and Super Admins](/docs/administration/roles-and-permissions/#team-roles) can add and remove members for all groups, but [Developers](/docs/administration/roles-and-permissions/#team-roles) can only add and remove members if they're a [group manager](#managing-group-managers). To manage the members of a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left. Locate the group you'd like to update and select it to edit. ![Image 3: Manage group members](https://assets.postman.com/postman-docs/v10/edit-group-members-v10.15.jpg) Select \[img alt="Add icon" src="https://assets.postman.com/postman-docs/aether-icons/action-add-stroke-small.svg#icon"\] **Add** to add a user to the group. Select \[img alt="Close icon" src="https://assets.postman.com/postman-docs/aether-icons/action-close-stroke-small.svg#icon"\] **Remove member** next to a user to remove them from the group. Users will receive an email and in-app notification when added to or removed from a group. ### Managing group managers Groups that are only assigned the Developer role can have group managers. Group managers can edit the name, description, members, and managers for a group. When a Developer creates a group they're automatically assigned the role of group manager. Developers with the group manager role, Admins, and Super Admins can add and remove group managers. To edit the managers of a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left. Locate the group you'd like to update and select it to edit. ![Image 4: Manage developer group managers](https://assets.postman.com/postman-docs/v10/edit-group-managers-v10.15.jpg) Select \[img alt="Add icon" src="https://assets.postman.com/postman-docs/aether-icons/action-add-stroke-small.svg#icon"\] **Add** to add a manager to the group. Select \[img alt="Close icon" src="https://assets.postman.com/postman-docs/aether-icons/action-close-stroke-small.svg#icon"\] **Remove manager** next to a manager to remove them from the group. ### Managing access control for a group You can control a group's access at the team level, workspace level, and on individual collections, APIs, environments, mock servers, and monitors. Users will receive an in-app notification when roles are updated. #### Editing team roles for a group [Admins and Super Admins](/docs/administration/roles-and-permissions/#team-roles) can manage team roles for groups. To edit team roles for a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left. Locate the group you'd like to update and select it to edit. ![Image 5: Edit group team roles](https://assets.postman.com/postman-docs/v10/manage-roles-for-a-group-v10.15.jpg) Select the team roles you'd like to assign to the group, or deselect team roles you'd like to remove from the group, then select **Update Roles**. To learn more about roles and their permissions, see [Team Roles](/docs/administration/roles-and-permissions/#team-roles). #### Managing roles on workspaces and Postman elements You can control a group's access to individual workspaces, collections, APIs, environments, mock servers, and monitors. For more information on managing workspaces, see [Share workspaces](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#share-workspaces). You can use the Postman API to programmatically manage users and user groups for workspaces. For more information, see the [Postman API collection](https://api.postman.com/). For collections, APIs, environments, mock servers, and monitors, go to the element you'd like to edit roles for. In the sidebar, select \[img alt="Options icon" src="https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon"\] **View more actions**, then select **Share**. Use the search bar to add the group, then give the group **Editor** or **Viewer** permissions with the dropdown. To remove a group, select **Remove** in the dropdown menu next to the group. #### See [Defining roles](/docs/administration/roles-and-permissions/) for more information on access control at a team, workspace, API, and collection level. ### Editing details for a group [Admins, Super Admins](/docs/administration/roles-and-permissions/#team-roles), and [group managers](#managing-group-managers) can edit details for a group. To edit details for a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left. Locate the group you'd like to update and select it to edit. Select the group's name at the top of the page to edit it. To add a description, select **Add a description** under the group's name. To update an existing description, select it to edit. Changes are automatically saved. ## Deleting a group [Admins, Super Admins](/docs/administration/roles-and-permissions/#team-roles), and [group managers](#managing-group-managers) can delete a group. To delete a group, select **Team** in the Postman header, then select **Manage Team**. Select **Groups** on the left. Locate the group you'd like to delete and select it. Select **Delete Group** to delete the group, then **Delete Group** to confirm. ![Image 6: Delete group](https://assets.postman.com/postman-docs/v10/delete-group-v10.15.jpg) --- # Connect to a cloud-hosted Git repository in the Postman API Builder You can connect your API to a cloud-hosted Git repository to sync your API definition and collections between Postman and the repository. Postman supports connecting to [GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/), [GitLab SaaS](https://about.gitlab.com/), or [Azure DevOps](https://azure.microsoft.com/en-us/products/devops/) repositories. After connecting, you can push and pull changes between Postman and branches in the remote repository. When it’s time to release, you can publish an API version to make your changes available to consumers. The steps below are for connecting to the cloud-hosted versions of GitHub, Bitbucket, GitLab SaaS, or Azure DevOps. If you need to connect to an on-premises repository, go to [Connect to an on-premises Git repository](/docs/design-apis/api-builder/versioning-an-api/using-on-prem-git-repo/). ## Using a cloud-hosted repository overview You can connect an API in Postman to your cloud-hosted Git repository. This enables you to sync changes between the repository and Postman. Keep in mind the following when connecting to a cloud-hosted Git repository: * **The user account used for authentication requires full access to repositories.** To contribute to the API, each user must authenticate with their own account. * **For GitHub connections, there's a limit of ten auth tokens per user per application imposed by GitHub.** If you create more than ten connections with the same user, tokens beyond this limit will be revoked in the order that they were created. Teams can use other Postman accounts to create more than ten integrations. * **For Azure DevOps connections, make sure to enable third-party application access for your organization.** If you don’t enable third-party access, Postman won’t be able to connect to your repository. In Azure DevOps, go to your [organization settings](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/change-application-access-policies?view=azure-devops), select **Policies**, and turn on the toggle next to **Third-party application access via OAuth**. * **You can connect one or more APIs to a remote repository.** You can keep your APIs separate in the repository using files or branches. Learn more about [connecting more than one API to the same repository](/docs/design-apis/api-builder/versioning-an-api/connecting-multiple-apis/). * **You can create a new collection from a GitHub repository.** You can create a new collection from a GitHub repository by selecting the repository and clicking **Create Collection**. ## Connecting to a cloud-hosted repository You can connect your API to a GitHub, Bitbucket, GitLab SaaS, or Azure DevOps repository hosted in the cloud. 1. Click **APIs** in the sidebar and select an API. 2. Under **Connect repository**, click **Connect** and select the type of repository you want to connect to (GitHub, Bitbucket, GitLab SaaS, or Azure DevOps). 3. A browser tab opens asking you to sign in to your repository. Follow the onscreen instructions. When you’re finished, close the browser tab and return to Postman. 4. On the **Connect your repository** page, select the **Organization** or **Workspace** and the **Repository** where the API will be stored. (For GitLab, enter the **Group** and **Project** for your API.) 5. Select the **Initial branch** for the API. Any changes you make in Postman are stored in the initial active branch. (You can switch to another branch to make it the active branch at any time.) 6. (Optional) Select an **API schema file** to add to your API. If you’re working on a [multi-file API definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/#work-with-multi-file-api-definitions), make sure to select the [root definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#about-root-files) in your repository. The root file is the base file that references other files in the API definition. If you leave this field blank, no definition files are added to your API. You can [manually add a definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-an-api-definition-from-a-connected-repository) from your repository later. 7. Select a **Collection directory** where the collections linked to your API will be stored in the repository. If you leave this field blank, a `postman/collections` directory is created in the root of the repository. 8. Click **Connect Repository**. The root definition file you selected is added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the root definition file and automatically adds them to your API. You can also [manually add more definition files](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-files-from-a-connected-repository) from your repository as needed. Postman stores your authorized accounts so you can use them to connect to other repositories and services. Learn more about [managing connected accounts for remote repositories](#managing-connected-accounts-for-remote-repositories). ![Image 1: Connecting to a cloud-hosted repo](https://assets.postman.com/postman-docs/v10/api-builder-remote-repo-v10-18a.jpg) ## Managing connected accounts for remote repositories After you connect an API to a remote repository, other editors of the API must authenticate to be able to contribute to the API. Postman will prompt editors to authenticate the next time they open the API. Postman stores the accounts you’ve authorized with. After connecting to one repository, you can connect to other repositories that use the same Git provider without having to reauthenticate. To manage services you’ve authorized with, click ![Image 2: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the header, click **Settings**, and select the **Connected accounts** tab. Learn more about [managing connected accounts](/docs/getting-started/installation/settings/#connected-accounts). ## Disconnecting a cloud-hosted repository After you disconnect a remote repository, you can no longer sync changes between Postman and the repository. 1. Click **APIs** in the sidebar and select an API. 2. Click ![Image 3: Branch icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-branch-stroke.svg#icon) **Source Control** in the right sidebar. 3. In the **Source Control** pane, click ![Image 4: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) and select **Disconnect repository**. 4. Enter the name of the API to confirm, then click **Disconnect**. ## Next steps After you’ve connected a remote repository to your API, you can: * Work with branches, push and pull changes, and resolve conflicts. Learn more about [managing changes using Git](/docs/design-apis/api-builder/versioning-an-api/managing-git-changes/). * Publish an API version to a workspace or your team’s Private API Network. Learn more about [publishing an API version](/docs/design-apis/api-builder/versioning-an-api/api-versions/). --- ## Connect to a cloud-hosted Git repository in the Postman API Builder You can connect your API to a cloud-hosted Git repository to sync your API definition and collections between Postman and the repository. Postman supports connecting to [GitHub](https://github.com/), [Bitbucket](https://bitbucket.org/), [GitLab SaaS](https://about.gitlab.com/), or [Azure DevOps](https://azure.microsoft.com/en-us/products/devops/) repositories. After connecting, you can push and pull changes between Postman and branches in the remote repository. When it’s time to release, you can publish an API version to make your changes available to consumers. The steps below are for connecting to the cloud-hosted versions of GitHub, Bitbucket, GitLab SaaS, or Azure DevOps. If you need to connect to an on-premises repository, go to [Connect to an on-premises Git repository](/docs/design-apis/api-builder/versioning-an-api/using-on-prem-git-repo/). ## Using a cloud-hosted repository overview You can connect an API in Postman to your cloud-hosted Git repository. This enables you to sync changes between the repository and Postman. Keep in mind the following when connecting to a cloud-hosted Git repository: * **The user account used for authentication requires full access to repositories.** To contribute to the API, each user must authenticate with their own account. * **For GitHub connections, there's a limit of ten auth tokens per user per application imposed by GitHub.** If you create more than ten connections with the same user, tokens beyond this limit will be revoked in the order that they were created. Teams can use other Postman accounts to create more than ten integrations. * **For Azure DevOps connections, make sure to enable third-party application access for your organization.** If you don’t enable third-party access, Postman won’t be able to connect to your repository. In Azure DevOps, go to your [organization settings](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/change-application-access-policies?view=azure-devops), select **Policies**, and turn on the toggle next to **Third-party application access via OAuth**. * **You can connect one or more APIs to a remote repository.** You can keep your APIs separate in the repository using files or branches. Learn more about [connecting more than one API to the same repository](/docs/design-apis/api-builder/versioning-an-api/connecting-multiple-apis/). * **You can create a new collection from a GitHub repository.** You can create a new collection from a GitHub repository by selecting the repository and clicking **Create Collection**. ## Connecting to a cloud-hosted repository You can connect your API to a GitHub, Bitbucket, GitLab SaaS, or Azure DevOps repository hosted in the cloud. 1. Click **APIs** in the sidebar and select an API. 2. Under **Connect repository**, click **Connect** and select the type of repository you want to connect to (GitHub, Bitbucket, GitLab SaaS, or Azure DevOps). 3. A browser tab opens asking you to sign in to your repository. Follow the onscreen instructions. When you’re finished, close the browser tab and return to Postman. 4. On the **Connect your repository** page, select the **Organization** or **Workspace** and the **Repository** where the API will be stored. (For GitLab, enter the **Group** and **Project** for your API.) 5. Select the **Initial branch** for the API. Any changes you make in Postman are stored in the initial active branch. (You can switch to another branch to make it the active branch at any time.) 6. (Optional) Select an **API schema file** to add to your API. If you’re working on a [multi-file API definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/#work-with-multi-file-api-definitions), make sure to select the [root definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#about-root-files) in your repository. The root file is the base file that references other files in the API definition. If you leave this field blank, no definition files are added to your API. You can [manually add a definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-an-api-definition-from-a-connected-repository) from your repository later. 7. Select a **Collection directory** where the collections linked to your API will be stored in the repository. If you leave this field blank, a `postman/collections` directory is created in the root of the repository. 8. Click **Connect Repository**. The root definition file you selected is added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the root definition file and automatically adds them to your API. You can also [manually add more definition files](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-files-from-a-connected-repository) from your repository as needed. Postman stores your authorized accounts so you can use them to connect to other repositories and services. Learn more about [managing connected accounts for remote repositories](#managing-connected-accounts-for-remote-repositories). ![Image 5: Connecting to a cloud-hosted repo](https://assets.postman.com/postman-docs/v10/api-builder-remote-repo-v10-18a.jpg) ## Managing connected accounts for remote repositories After you connect an API to a remote repository, other editors of the API must authenticate to be able to contribute to the API. Postman will prompt editors to authenticate the next time they open the API. Postman stores the accounts you’ve authorized with. After connecting to one repository, you can connect to other repositories that use the same Git provider without having to reauthenticate. To manage services you’ve authorized with, click ![Image 6: Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** in the header, click **Settings**, and select the **Connected accounts** tab. Learn more about [managing connected accounts](/docs/getting-started/installation/settings/#connected-accounts). ## Disconnecting a cloud-hosted repository After you disconnect a remote repository, you can no longer sync changes between Postman and the repository. 1. Click **APIs** in the sidebar and select an API. 2. Click ![Image 7: Branch icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-branch-stroke.svg#icon) **Source Control** in the right sidebar. 3. In the **Source Control** pane, click ![Image 8: Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) and select **Disconnect repository**. 4. Enter the name of the API to confirm, then click **Disconnect**. ## Next steps After you’ve connected a remote repository to your API, you can: * Work with branches, push and pull changes, and resolve conflicts. Learn more about [managing changes using Git](/docs/design-apis/api-builder/versioning-an-api/managing-git-changes/). * Publish an API version to a workspace or your team’s Private API Network. Learn more about [publishing an API version](/docs/design-apis/api-builder/versioning-an-api/api-versions/). --- # Connect to an on-premises Git repository in the Postman API Builder **[GitHub Enterprise Server, GitLab Self-Managed, and Azure DevOps Server (hosted on-premises) integrations are available with Postman Enterprise plans with the API Builder add-on.](https://www.postman.com/pricing/)** You can connect your API to an on-premises Git repository to sync your API definition and collections between Postman and the repository. Postman supports connecting to GitHub Enterprise Server, GitLab Self-Managed, or Azure DevOps Server repositories. After connecting, you can push and pull changes between Postman and branches in the remote repository. When it's time to release, you can publish an API version to make your changes available to consumers. ## Using an on-premises repository overview If you are on a [Postman Enterprise plan with the API Builder add-on](https://www.postman.com/pricing/), you can connect an API in Postman to your on-premises Git repository. This enables you to sync changes between the repository and Postman. To connect to [GitHub Enterprise Server or GitLab Self-Managed](#connecting-to-github-enterprise-server-or-gitlab-self-managed), create a new installed app in Postman. To connect to [Azure DevOps server](#connecting-to-azure-devops-server), use a personal access token. Keep in mind the following when connecting to an on-premises repository: * **You must be on a [Postman Enterprise plan with the API Builder add-on](https://www.postman.com/pricing/) to connect to a repository hosted on-premises.** If you're not on a Postman Enterprise plan with the API Builder add-on, you won't be able to connect to GitHub Enterprise Server, GitLab Self-Managed, or Azure DevOps Server. You can still [connect to a cloud-hosted repository](/docs/design-apis/api-builder/versioning-an-api/using-cloud-git-repo/). * **You must use the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/) to connect to GitHub Enterprise Server, GitLab Self-Managed, or Azure DevOps Server.** You can't use the [Postman web app](/docs/getting-started/installation/installation-and-updates/#use-the-postman-web-app) to connect to an on-premises GitHub repository. * **All communication is between the Postman desktop app on your computer and the on-premises repository.** Your computer must be able to access the repository. No Git requests go through Postman's cloud servers. The Postman desktop app connects directly to your Git server, and you don't need to allow any Postman IP addresses for your repository. The repository will show the IP address of your computer as the source for all Git requests. * **You can connect one or more APIs to a remote repository.** You can keep your APIs separate in the repository using files or branches. Learn more about [connecting more than one API to the same repository](/docs/design-apis/api-builder/versioning-an-api/connecting-multiple-apis/). ## Connecting to GitHub Enterprise Server or GitLab Self-Managed To connect to a repository hosted in GitHub Enterprise Server or GitLab Self-Managed, [create an installed app](#creating-an-installed-app) in Postman. To complete this process, you'll also need to create an OAuth app in GitHub Enterprise Server or GitLab Self-Managed. You need to complete this process once for a domain URL. After you create the installed app, anyone on the team can use it to [connect to repositories using the same domain URL](#connecting-an-api-using-an-installed-app). ### Creating an installed app [Installed apps](/docs/integrations/installed-apps/) streamline the process of adding integrations by enabling all members of a team to use the same stored authorization details. To create an installed app, you must have the [Team Admin role](/docs/administration/roles-and-permissions/#team-roles). To create an installed app for GitHub Enterprise Server or GitLab Self-Managed, do the following: 1. In Postman, open [Team Settings](https://go.postman.co/settings/team/general) by selecting **Team \u003e Team Settings**. 2. Click **Installed apps**. 3. Select the repository provider you want to add an installed app for (**GitHub Enterprise Server** or **GitLab Self-Managed**). 4. Enter a **Name** to help you recognize the installed app later. 5. Enter the domain URL of your repository. Format the domain URL as follows: * **GitHub Enterprise Server** - Use the base URL of your Git server, for example: `https://my-github-server.example.com` * **GitLab Self-Managed** - Use the base URL of your Git server, for example: `https://gitlab.example.com` 6. Create an OAuth app by following the instructions for your Git provider ([GitHub Enterprise Server](https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/creating-an-oauth-app) or [GitLab Self-Managed](https://docs.gitlab.com/ee/integration/oauth_provider.html)). Use the following values: * **Homepage URL** - Enter the Postman homepage URL: `https://www.postman.com` * **Authorization callback URL** or **Redirect URI** - Enter the authorization callback URL provided in Postman: `https://integration-oauth.pstmn.io/v1/api-git-callback.html` * **Scopes** - Make sure to select the appropriate scopes when creating the OAuth app to enable Postman to read and write to your repository. For GitHub, select the `repo` and `user` scopes. For GitLab Self-Managed, select the `api` scope. 7. After registering the OAuth app, copy the app's **Client ID** and **Client secret** and enter them in Postman. 8. Click **Save** to finish creating the installed app. ![Image 1: Creating an installed app](https://assets.postman.com/postman-docs/v10/api-builder-add-installed-app-v10-12b.png) ### Connecting an API using an installed app After you [create an installed app](#creating-an-installed-app), any API editor on the team can use it to connect an API to GitHub Enterprise Server or GitLab Self-Managed. To connect an API using an installed app, do the following: 1. Click **APIs** in the sidebar and select an API. 2. Under **Connect repository**, click **Connect** and select **GitHub Enterprise Server** or **GitLab Self-Managed**. 3. Select the authorized domain of your repository and click **Authenticate**. ![Image 2: Using an installed app](https://assets.postman.com/postman-docs/v10/api-builder-use-installed-app-v10-12.jpg) 4. A browser tab opens asking you to sign in to your repository. Follow the onscreen instructions. When you're finished, close the browser tab and return to Postman. 5. For GitHub, enter the **Organization** and the **Repository** where the API will be stored. For GitLab, enter the **Group** and **Project** for your API. 6. Select the **Initial branch** for the API. Any changes you make in Postman are stored in the initial active branch. (You can switch to another branch to make it the active branch at any time.) 7. Select an **API schema file** to add to your API. If you're working on a [multi-file API definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/#work-with-multi-file-api-definitions), make sure to select the [root definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#about-root-files) in your repository. The root file is the base file that has references to other files in the API definition. If you leave this field blank, no definition files are added to your API. You can [manually add a definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-an-api-definition-from-a-connected-repository) from your repository later. 8. Select a **Collection directory** where the collections linked to your API will be stored in the repository. If you leave this field blank, a `postman/collections` directory will be created in the root of the repository. 9. Click **Connect Repository**. The root definition file you selected is added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the root definition file and automatically adds them to your API. You can also [manually add more definition files](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-files-from-a-connected-repository) from your repository as needed. ## Connecting to Azure DevOps Server To connect an API to a repository hosted in Azure DevOps Server, use a personal access token. 1. Click **APIs** in the sidebar and select an API. 2. Under **Connect repository**, click **Connect** and select **Azure DevOps Server**. 3. Enter the **Domain URL** of your repository. You can enter a new domain or select a domain you've used before from the list. Use the name and port of your Git server along with the collection, for example: `https://my-azure-server:8080/my-collection` 4. Enter a **Personal access token** to access the repository. Ensure that the token has the required permissions as specified on the **Connect your repository** page. 5. Click **Next**. ![Image 3: Using a personal access token](https://assets.postman.com/postman-docs/v10/api-builder-use-access-token-v10-12.jpg) 6. Enter the **Organization** and the **Repository** where the API will be stored. 7. Select the **Initial branch** for the API. Any changes you make in Postman are stored in the initial active branch. (You can switch to another branch to make it the active branch at any time.) 8. Select an **API schema file** to add to your API. If you're working on a [multi-file API definition](/docs/design-apis/api-builder/develop-apis/defining-an-api/#work-with-multi-file-api-definitions), make sure to select the [root definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#about-root-files) in your repository. The root file is the base file that has references to other files in the API definition. If you leave this field blank, no definition files are added to your API. You can [manually add a definition file](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-an-api-definition-from-a-connected-repository) from your repository later. 9. Select a **Collection directory** where the collections linked to your API will be stored in the repository. If you leave this field blank, a `postman/collections` directory will be created in the root of the repository. 10. Click **Connect Repository**. The root definition file you selected is added to your API. For OpenAPI 2.0 and 3.0 APIs, Postman scans for any dependent files referenced in the root definition file and automatically adds them to your API. You can also [manually add more definition files](/docs/design-apis/api-builder/develop-apis/defining-an-api/#add-files-from-a-connected-repository) from your repository as needed. Postman stores your authorized accounts so you can use them to connect to other repositories and services. Learn more about [managing connected accounts for remote repositories](/docs/design-apis/api-builder/versioning-an-api/using-cloud-git-repo/#managing-connected-accounts-for-remote-repositories). ## Disconnecting an on-premises repository After you disconnect a remote repository, you can no longer sync changes between Postman and the repository. 1. Click **APIs** in the sidebar and select an API. 2. Click \u003cimg alt=\"Branch icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/descriptive-branch-stroke.svg#icon\" width=\"16px\"\u003e **Source Control** in the right sidebar. 3. In the **Source Control** pane, click \u003cimg alt=\"Options icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon\" width=\"16px\" role=\"img\"\u003e and select **Disconnect repository**. 4. Enter the name of the API to confirm, then click **Disconnect**. ## Next steps After you've connected a remote repository to your API, you can: * Work with branches, push and pull changes, and resolve conflicts. Learn more about [managing changes using Git](/docs/design-apis/api-builder/versioning-an-api/managing-git-changes/). * Publish an API version to a workspace or your team's Private API Network. Learn more about [publishing an API version](/docs/design-apis/api-builder/versioning-an-api/api-versions/). --- **Tip: Plan your Organization setup** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams and workspaces To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 4: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using \`@\`, for example, \`@api-developers\`. ![Image 5: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 6: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 7: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 8: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click \u003cimg alt=\"Slack icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon\" width=\"16px\"\u003e \u003cimg alt=\"Teams icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon\" width=\"16px\"\u003e **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. To learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip: Plan your Organization setup** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 9: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using \`@\`, for example, \`@api-developers\`. ![Image 10: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 11: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 12: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 13: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click \u003cimg alt=\"Slack icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon\" width=\"16px\"\u003e \u003cimg alt=\"Teams icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon\" width=\"16px\"\u003e **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. To learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip: Plan your Organization setup** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 14: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using \`@\`, for example, \`@api-developers\`. ![Image 15: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 16: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 17: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 18: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click \u003cimg alt=\"Slack icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon\" width=\"16px\"\u003e \u003cimg alt=\"Teams icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon\" width=\"16px\"\u003e **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. To learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip: Plan your Organization setup** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 19: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using \`@\`, for example, \`@api-developers\`. ![Image 20: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs/administration/managing-your-team/user-groups/) to assign Team membership, enabling control through an [Identity Provider (IdP) and SCIM](/docs/administration/scim-provisioning/scim-provisioning-overview/). ![Image 21: Add Organization Team members](https://assets.postman.com/postman-docs/v11/org-team-member-add.jpg) ## Create Organization workspaces To create workspaces for an Organization Team, do the following: 1. If you're not continuing from the previous step, from the [Home](https://go.postman.co/home) page, click [Teams](https://go.postman.co/teams) and locate the team you for which you want to create workspaces. 2. Click **Create Workspace**. ![Image 22: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-create-v11.jpg) 3. Select a blank workspace or a workspace template. Click **Next**. 4. Name the workspace. ![Image 23: Create Organization workspaces](https://assets.postman.com/postman-docs/v11/org-workspace-detail-v11.jpg) 5. Select the team for which to create a workspace. Otherwise, your team will be prepopulated. 6. Select **Internal** for workspace type. You can update the workspace visibility at any time. As a best practice, workspaces need to remain internal until all the work has been completed and approved. 7. Select **Everyone in [TeamName]** to allow all Team Members with access to the workspace, whether invited or shared, to edit the workspace elements. Collaborators will still have to be added to the workspace roles to enable their access. For stricter access, select **Only you and invited people**. If there's a specific need to open the workspaces to all people in the Organization, select **Everyone in [OrgName]**. 8. Click **Create**. After you create one or more workspaces, you can add workspace details, connect the workspace to a Slack or Teams channel, and post a workspace update announcing the workspace is ready for collaboration. ## Edit workspace details Postman recommends adding a useful workspace description and other details to help Organization Teams start collaborating. To identify workspaces further, do the following: 1. Under **Workspace description**, add a description. 2. Under **About**, add a summary. 3. Under **Tags**, add tags. Your teams can continue to edit workspace details as their workspaces, collections, and APIs evolve. To learn more, see [Edit workspace details](/docs/collaborating-in-postman/using-workspaces/internal-workspaces/manage-workspaces/#edit-workspace-details). ## Announce your team and workspace setup To post a workspace update, do the following: 1. From the workspace, select **Updates**. 2. Click **Post an Update**. 3. Enter a title and a description of your update. 4. Select **Announcement** from the dropdown list. 5. (Optional) Add a summary describing the change. 6. If you've integrated Postman with Slack or Teams, you can post a team workspace update to a channel on one or both of those apps. Click \u003cimg alt=\"Slack icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-slack.svg#icon\" width=\"16px\"\u003e \u003cimg alt=\"Teams icon\" src=\"https://assets.postman.com/postman-docs/aether-icons/brandLogo-teams.svg#icon\" width=\"16px\"\u003e **Connect** in the workspace overview to subscribe to a channel. Ensure the box is checked to send notifications when someone posts a workspace update. To learn more, visit the [Slack](/docs/integrations/available-integrations/slack/slack-app/) and [Teams](/docs/integrations/available-integrations/teams/teams-app/) integrations pages, respectively. To learn more about: * [Organization roles](/docs/administration/organization/roles/) * [Organization settings](/docs/administration/organization/settings/) --- **Tip: Plan your Organization setup** Before you set up your Organization Teams, consider the following: * How many teams do you need and for which specific step in your API lifecycle? * How will you name your teams and workspaces? * Who will be in each group and on which team? Who will manage each team? * How many workspaces will each team need to begin collaborating? * If you have Slack or Teams workspaces, which channels do you need to connect each workspace to post workspace updates? --- **Note:** The component library doesn't support AsyncAPI specifications or [the Postman CLI](/docs/postman-cli/postman-cli-options/#postman-spec-lint). ## Create Organization teams To create an Organization Team, do the following: 1. Access [**Organization Settings**](/docs/administration/organization/settings/) in the Postman header, then click **Teams** in the left sidebar. 2. Click **Create Team**. ![Image 24: Create an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-create-v11.67.png) 3. Name your team. The team will be taggable in the mentions using \`@\`, for example, \`@api-developers\`. ![Image 25: Name an Organization Team](https://assets.postman.com/postman-docs/v11/org-team-name-v11.jpg) 4. Click **Add Members**. To be added, members need to be part of the organization. > **Notes:** > * If no Team Manager is assigned, the Organization Manager can continue to manage the Team membership. > * You can use [Groups](/docs --- # variables _Store and reuse values using variables_ _By storing a value as a variable, you can reference it throughout your collections, environments, requests, and scripts. Variables help you work efficiently, collaborate with teammates, and set up dynamic workflows._ ## Understanding variables A variable is a symbolic representation of data that enables you to access a value without having to enter it manually wherever you need it. This can be useful if you're using the same values in multiple places. Variables make your requests more flexible and readable by abstracting the detail away. For example, if you have the same URL in more than one request, but the URL might change, you can store it in a "base_url" variable. Then, use "{{base_url}}" to reference the variable in your requests. If the URL changes, you can change the variable value and it'll be reflected throughout your collection wherever you've used the variable name. The same principle applies to any part of your request where data is repeated. Whatever value is stored in the variable will be included wherever you've referenced the variable when your requests run. If the variable value is `https://postman-echo.com` and the request uses the `{{base_url}}/get` URL, then Postman sends the request to `https://postman-echo.com/get`. ![Environment editor](https://assets.postman.com/postman-docs/v11/environment-editor-v11-60-4.jpg) ![Reference variable](https://assets.postman.com/postman-docs/v11/reference-var-v11-18.jpg) Variables in Postman are key-value pairs. Each variable name represents its key, so referencing the variable name enables you to access its value. You can use variables to pass data between requests and tests. For example, if you are [chaining requests](https://www.postman.com/postman/postman-team-collections/collection/fa2fdwg/extract-data-to-chain-requests) in a collection. Use your [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/) to store sensitive data as vault secrets and reuse them in your local instance of Postman. Only you can access and use values associated with your vault secrets and secrets aren't synced to the Postman cloud. Use environments to group sets of variables together and share them with collaborators. For example, if you use one set of config details for your production server and another for testing. See [Group sets of variables in Postman using environments](/docs/sending-requests/variables/managing-environments/) for more on how you can incorporate environments into your team workflows. ## Variable scopes Postman supports variables at different scopes, allowing you to tailor your processing to a variety of development, testing, and collaboration tasks. Scopes in Postman relate to the different contexts that your requests run in, and different variable scopes are suited to different tasks. You can create a variable without a variable scope if it isn't meant to hold a default value. You can also create a variable without a scope to try out the value before adding it to a scope. Learn more about [creating variables without a scope](#setting-values-for-variables-without-a-scope). In order from broadest to narrowest, these scopes are: _global_, _collection_, _environment_, _data_, and _local_. * **Global variables** enable you to access data between collections, requests, scripts, and environments. Global variables are available throughout a [workspace](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). Since global variables have the broadest scope available in Postman, they're well-suited for testing and prototyping. In later development phases, use more specific scopes. * **Collection variables** are available throughout the requests in a collection and are independent of environments. Collection variables don't change based on the selected environment. Collection variables are suitable if you're using a single environment, such as auth or URL details. * **Environment variables** enable you to scope your work to different environments, such as local development versus testing or production environments. One environment can be active at a time. If you have a single environment, using collection variables can be more efficient, but environments enable you to specify [role-based access levels](/docs/sending-requests/variables/team-environments/#share-an-environment). * **Data variables** come from external CSV and JSON files to define data sets you can use when running collections with the [Collection Runner](/docs/collections/running-collections/intro-to-collection-runs/), the [Postman CLI](/docs/postman-cli/postman-cli-overview/), or [Newman](/docs/collections/using-newman-cli/command-line-integration-with-newman/). Data variables have local values, which don't persist beyond request or collection runs. * **Local variables** are temporary variables that are accessed in your request scripts. Local variables are scoped to a single request or collection run, and are no longer available when the run is complete. Local variables are suitable if you need a value to override all other variable scopes but don't want the value to persist once the run ends. ![Variable scope](https://assets.postman.com/postman-docs/v10/var-scope-v10.jpg) If a variable with the same name is declared in two different scopes, the value stored in the variable with narrowest scope will be used. For example, if there is a "username" global variable and a "username" local variable, the local value is used when the request runs. Postman stores variables as strings. If you store objects or arrays, remember to `JSON.stringify()` them before storing, and `JSON.parse()` them when you retrieve them. ## Variable values By default, collection, environment, and global variable values are only available locally in your instance of Postman. The local value is used when sending requests, and it isn't synced to the Postman cloud. Update your local value as you'd like, without sharing it with your teammates. Learn how to [define a local value for your variables](#defining-variables). If you have Editor access to the element, you can [share a variable's value](#share-variable-values), syncing it's value to the Postman cloud. Share a variable's value to provide your teammates with a default value they can use to begin making requests to your API. Your teammates can continue to update their local value without sharing it. They can also reset their local value back to the shared value at any time. Some Postman features that run on the Postman cloud also use the shared value when sending requests. These features include scheduled collection runs, monitors, the Postman CLI, and Newman. If you're more familiar with current and initial values, learn more about the [previous way of defining variables](#previous-way-of-defining-variables). ### Previous way of defining variables Postman no longer supports maintaining multiple independent values for your collection, environment, and global variables. Previously, you could provide a _current value_ (local) and _initial value_ (shared) for your variables and update them separately. Initial and current values are supported in the Postman VS Code extension. Learn more about [variables in the VS Code extension](/docs/developer/vs-code-extension/send-requests/#store-variables). With this change, you only need to provide a single value for your variables that's local by default (previously the current value). Learn how to [define a local value for your variables](#defining-variables). You can choose to [share a variable's value](#share-variable-values) with your teammates (previously the initial value), based on the local value at the time of sharing. You can continue to update and use your local value without sharing it. Updates to your local value are only shared with your teammates if you intentionally choose to share the new value. ## Defining variables Variable values are local by default and only available to you in your instance of Postman. These values aren't synced to the Postman cloud. Once you've defined a local value, you can optionally [share variable values](#share-variable-values), syncing the value to the Postman cloud. Remember to delete variables you're no longer using. To define variables at any scope in the request builder, do the following: 1. Select the data you need, for example in the address, parameters, headers, or body. 1. Right-click the selection and click **Set as variable**. ![Set as variable](https://assets.postman.com/postman-docs/v11/set-as-var-prompt-v11-3.jpg) 1. Click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Set as new variable**. ![Set as variable](https://assets.postman.com/postman-docs/v11/set-as-a-new-var-v11-25.jpg) 1. Enter a **Name**, confirm the **Value** is correct, and select a **Scope**. Then click **Set Variable**. ![Set as variable](https://assets.postman.com/postman-docs/v11/set-as-var-modal-v11-25.jpg) You can also define variables in the following ways: * [Try out a variable locally without a scope](#setting-values-for-variables-without-a-scope), then [add the variable to a scope](#adding-variables-to-a-scope). * [Set a response body value as a variable](#setting-response-body-values-as-variables) (_Desktop app only_) * Define a variable in the [global](#defining-global-variables), [environment](#defining-environment-variables), or [collection](#defining-collection-variables) scope. * [Define variables using scripts](#defining-variables-in-scripts). Learn more about [variable scopes](#variable-scopes) in Postman. You can also learn how to [define variables from the VS Code extension](/docs/developer/vs-code-extension/send-requests/#store-variables). ### Setting values for variables without a scope Variables without a [variable scope](#variable-scopes) are useful for trying out the value before [adding the variable to a scope](#adding-variables-to-a-scope). This is also useful for sending data with requests that isn't meant to hold a default value. For example, a variable without a scope might send user-specific information that changes each time you send the request. Variables without a scope also enable you to create a placeholder variable to share with your API consumers, without having to define the variable at a specific scope. In the request builder, you can create a variable without adding it to a variable scope. The value you enter for this variable is stored locally and is only available in the request it's set in. When you click ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables**, the variable isn't associated with a scope (highlighted by color) in the variables pane under **Variables in request**. To create a variable from the request builder, [use double curly braces (\"{{\" and \"}}\") to reference a variable](#using-variables) that doesn't exist or isn't available from the request. For example, enter "{{username}}" to create a username variable that doesn't have a scope. ![Set a value for variable without a scope](https://assets.postman.com/postman-docs/v11/variables-used-temporary-value-v11-18.jpg) To set a value for a variable without a scope, hover over it, click the text box, then enter a value. You can also click ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the [workbench](/docs/getting-started/basics/navigating-postman/#environment-selector-and-variables-pane) to open the variables pane. Click **Enter value** next to the variable, then enter a value. You can use `pm.variables.get(variableName)` to access variables without a scope in scripts. Learn more about [using variables in scripts](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-variables/). Values for variables without a scope are stored locally in a request until you close its tab or sign out of Postman. When you open the request again, the variable's value will be empty. If you'd like to store and reuse the value in your requests, you can [add the variable and its value to a scope](#adding-variables-to-a-scope). You can also create a vault secret without adding it to your Postman Vault. [Open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault), then use the "{{vault:secret-name}}" syntax. When you're ready, you can add the vault secret to your Postman Vault. Learn how to [create](/docs/sending-requests/postman-vault/manage-vault-secrets/#set-a-value-for-a-vault-secret-that-doesnt-exist) and [add](/docs/sending-requests/postman-vault/manage-vault-secrets/#add-a-vault-secret-reference-to-your-postman-vault) a vault secret from the request builder. ### Adding variables to a scope From a Postman element, such as a request or collection, you can create a variable and add it to a specific [variable scope](#variable-scopes) to reuse it across your requests. You can also add a [variable without a scope](#setting-values-for-variables-without-a-scope) to a specific variable scope in your team. From the element, you can add a value that's stored locally for the variable. You need Editor access to an environment or collection to add variables to it. [Use double curly braces (\"{{\" and \"}}\") to reference a variable](#using-variables) that doesn't exist or isn't available from the element. Hover over the reference to the variable, click the text box, then enter a value if you haven't already. Select the **Add to** dropdown list, then select the scope you'd like to add the variable to. ![Add unresolved variable to a scope](https://assets.postman.com/postman-docs/v11/variables-used-define-unresolved-v11-18.jpg) You can define variables at any scope from the **Authorization** tab. Select the **Auth Type** dropdown list, select an authorization, then enter a value in a field that holds sensitive data, such as a password or token. Hover over ![Secret warning icon](https://assets.postman.com/postman-docs/aether-icons/state-secretWarning-stroke.svg#icon) **Sensitive value**, click **Set as Variable**, enter a name for the variable, then select the scope you'd like to add it to. ![Set as new variable](https://assets.postman.com/postman-docs/v11/set-sensitive-value-as-vault-secret-v11-39.jpg) You can also click ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the workbench to view the variables and vault secrets used in your request. Click the text box, enter a value for the variable without a scope, click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Add to**, then select the scope you'd like to add it to. ![Define a value for an unresolved variable](https://assets.postman.com/postman-docs/v11/variables-used-define-variable-pane-v11-18.jpg) You can also choose to add sensitive data as a vault secret in your Postman Vault. To add it as a vault secret in your Postman Vault, first [open your Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/#access-your-postman-vault). The environment you want to add a variable to must be active in the environment selector. If an environment isn't active, you can add a variable to an environment using one of the following options in the dropdown list: * **Select an existing environment** - Click **Select**, then choose an environment to make it active. The variable is added to the selected environment. * **Create a new environment** - Click **Create One**, enter a name for the environment, then select **Create**. The variable is created and added to the new environment. Note that you can [set global and environment variables as sensitive data](#set-a-value-as-sensitive-data), masking the values in the Postman app. ![Choose or create an environment for unresolved variables](https://assets.postman.com/postman-docs/v11/variables-used-choose-active-environment-v11-18.jpg) If the variable without a scope has the "vault:" prefix (for example, "vault:postman-api-key"), you can only add it to your Postman Vault as a vault secret. To add a local value to a variable that you can shared with collaborators, learn how to edit variables directly in the [global](#defining-global-variables), [environment](#defining-environment-variables), and [collection](#defining-collection-variables) scope. ### Setting response body values as variables Setting response body values as variables is only available in the [Postman desktop app](/docs/getting-started/installation/installation-and-updates/). To define variables at any scope from a request's response body, do the following: 1. (Optional) If you're setting the value for an environment variable, [select the variable's environment](/docs/sending-requests/variables/managing-environments/#switch-between-environments) from the dropdown list located in the top right of the workbench. 1. In the response, right-click the selection and click **Set as variable**. 1. Click ![Add icon](https://assets.postman.com/postman-docs/aether-icons/action-add-stroke.svg#icon) **Set as new variable**. 1. Enter a **Name**, confirm the **Value** is correct, and select a **Scope**. Then click **Set Variable**. ![Set as new variable](https://assets.postman.com/postman-docs/v11/set-sensitive-value-as-vault-secret-v11-39.jpg) You can also define variables in the following ways: * [Try out a variable locally without a scope](#setting-values-for-variables-without-a-scope), then [add the variable to a scope](#adding-variables-to-a-scope). * [Set a response body value as a variable](#setting-response-body-values-as-variables) (_Desktop app only_) * Define a variable in the [global](#defining-global-variables), [environment](#defining-environment-variables), or [collection](#defining-collection-variables) scope. * [Define variables using scripts](#defining-variables-in-scripts). Learn more about [variable scopes](#variable-scopes) in Postman. You can also learn how to [set a value as sensitive data from the VS Code extension](/docs/developer/vs-code-extension/send-requests/#store-variables). ### Defining global variables To view global variables, click **Environments** in the sidebar and select **Globals**. To add a new global variable, do the following: 1. Click the **Add variable** text box and enter a variable name. 1. (Optional) Click ![Key icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-key-stroke.svg#icon) **Mark as sensitive** next to the variable name to set the variable as sensitive data, masking the value in Postman. Learn more about [setting a variable as sensitive data](#set-a-value-as-sensitive-data). 1. Enter the variable's value. 1. (Optional) Click ![Edit description icon](https://assets.postman.com/postman-docs/v11/icons/icon-edit-description-v11.jpg#icon) **Add description** next to the variable name and enter a description of the variable. To display the description in a separate column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Description**. 1. (Optional) Click ![Share icon](https://assets.postman.com/postman-docs/v11/icons/icon-cloud-v11.svg#icon) **Share** next to the value to share it with teammates and use it with monitors and scheduled runs. To display the shared value in its own column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Shared Value**. To download global variables, click ![Export icon](https://assets.postman.com/postman-docs/aether-icons/action-export-stroke.svg#icon) **Export** in the upper right of the workbench. To edit an existing global variable, change the desired variable name, value, or description. To search for a global variable by name or value, click ![Search icon](https://assets.postman.com/postman-docs/aether-icons/action-search-stroke.svg#icon) **Search**, and enter your search. You can also learn about [defining global variables in scripts](#defining-variables-in-scripts) and [viewing and editing variables](#viewing-and-editing-variables-in-an-element) directly from a Postman element. Changes to your variables are automatically saved. ### Defining environment variables To view environment variables, click **Environments** in the sidebar and select the environment you want to view. To add a new environment variable, do the following: 1. Click the **Add variable** text box and enter a variable name. 1. (Optional) Click ![Key icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-key-stroke.svg#icon) **Mark as sensitive** next to the variable name to set the variable as sensitive data, masking the value in Postman. Learn more about [setting a variable as sensitive data](#set-a-value-as-sensitive-data). 1. Enter the variable's value. 1. (Optional) Click ![Edit description icon](https://assets.postman.com/postman-docs/v11/icons/icon-edit-description-v11.jpg#icon) **Add description** next to the variable name and enter a description of the variable. To display the description in a separate column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Description**. 1. (Optional) Click ![Share icon](https://assets.postman.com/postman-docs/v11/icons/icon-cloud-v11.svg#icon) **Share** next to the value to share it with teammates and use it with monitors and scheduled runs. To display the shared value in its own column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Shared Value**. To download environment variables, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to an environment and select **Export**. To edit an existing environment variable, change the desired variable name, value, or description. To search for an environment variable by name or value, click ![Search icon](https://assets.postman.com/postman-docs/aether-icons/action-search-stroke.svg#icon) **Search**, and enter your search. You can add and edit variables if you have Editor access to an environment. If you have Viewer access, you're restricted to updating the local value of existing variables. Any variables you edit are available to you, but not to collaborators in your [workspace](/docs/collaborating-in-postman/using-workspaces/create-workspaces/). Learn about [working with environments](/docs/sending-requests/variables/managing-environments/) in your team and [defining environment variables in scripts](#defining-variables-in-scripts). You can also learn about [viewing and editing variables](#viewing-and-editing-variables-in-an-element) directly from a Postman element. Changes to your variables are automatically saved. ### Defining collection variables To view collection variables, click **Collections** in the sidebar, select a collection you want to view, then select **Variables**. To add a new collection variable, do the following: 1. Click the **Add variable** text box and enter a variable name. 1. Enter the variable's value. 1. (Optional) Click ![Edit description icon](https://assets.postman.com/postman-docs/v11/icons/icon-edit-description-v11.jpg#icon) **Add description** next to the variable name and enter a description of the variable. To display the description in a separate column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Description**. 1. (Optional) Click ![Share icon](https://assets.postman.com/postman-docs/v11/icons/icon-cloud-v11.svg#icon) **Share** next to the value to share it with teammates and use it with monitors and scheduled runs. To display the shared value in its own column, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Shared Value**. To download collection variables, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **View more actions** next to a collection, then click **More** and select **Export**. Learn more about [exporting a collection](/docs/getting-started/importing-and-exporting/exporting-data/). To edit an existing collection variable, change the desired variable name, value, or description. To search for a collection variable by name or value, click ![Search icon](https://assets.postman.com/postman-docs/aether-icons/action-search-stroke.svg#icon) **Search**, and enter your search. With Editor access to a collection, you can add new collection variables, share values with your teammates, and update shared values. You can also [define collection variables in scripts](#defining-variables-in-scripts). If you have Viewer access to a collection, you can only update the local value of existing collection variables. Learn how to [request Editor access to a collection](/docs/collaborating-in-postman/requesting-access-to-elements/#request-editor-access). You can also learn about [viewing and editing variables](#viewing-and-editing-variables-in-an-element) directly from a Postman element. Changes to your variables are automatically saved. ### Defining variables in scripts You can set variables and vault secrets programmatically in your request scripts. Method | Use case | Example --- | --- | --- `pm.globals` | Define a global variable. | `pm.globals.set("variable_key", "variable_value")` `pm.collectionVariables` | Define a collection variable. | `pm.collectionVariables.set("variable_key", "variable_value")` `pm.environment` | Define an environment variable in the current environment. | `pm.environment.set("variable_key", "variable_value")` `pm.variables` | Define a local variable. | `pm.variables.set("variable_key", "variable_value")` `pm.vault` | Define a vault secret in your Postman Vault. | `await pm.vault.set("secret_key", "secret_value")` `unset` | Remove a variable. | `pm.environment.unset("variable_key")` If you don't have Editor access to an environment, your script code will affect the local value but won't be synced or shared with your team. Make sure you [enable scripts to access your vault secrets](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/pm-vault/). Otherwise, you'll receive an error in the Postman Console, and any code that comes after the method won't run. Also, you must use the `await` operator before each `pm.vault` method for it to run in your script. For instructions on how to use variables in pre-request or post-response scripts, see [Using variables in scripts](#using-variables-in-scripts). ## Set a value as sensitive data With [Editor](/docs/administration/roles-and-permissions/) access, you can set a global or environment variable as sensitive data. This masks the value, helping you avoid unintentionally sharing sensitive tokens, for example, to an unintended audience during screen sharing or live streaming. Postman stores variables as strings on the cloud. To learn about how Postman keeps your data safe, see [Security at Postman](https://www.postman.com/trust/security/). Postman recommends that you use your [Postman Vault](/docs/sending-requests/postman-vault/postman-vault-secrets/) to store sensitive data, such as API keys, as encrypted vault secrets. Only you can access and use values associated with your vault secrets, and they aren't synced to the Postman cloud. To set a variable value as sensitive data, do the following: 1. Open a [global](#defining-global-variables) or [environment](#defining-environment-variables) variable. 1. Click ![Key icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-key-stroke.svg#icon) **Mark as sensitive** next to the variable name. ![Set environment variable as sensitive data](https://assets.postman.com/postman-docs/v11/environment-variable-sensitive-data-v11-60-4.jpg) To set all variable values as sensitive data, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Mark all sensitive**. If you [share a value](#share-variable-values) that's set as sensitive data, Postman warns you about the outcome of sharing a sensitive value. Your teammates can view the value of a variable set as sensitive data by clicking ![View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon) **Show** next to the variable's value. To unset a variable value as sensitive data, do the following: 1. Open a [global](#defining-global-variables) or [environment](#defining-environment-variables) variable. 1. Click ![Key icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-key-stroke.svg#icon) **Remove sensitive mark** next to the variable name. The value is no longer masked. To unset all variable values as sensitive data, click ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More** and select **Unmark all sensitive**. You can also learn how to [set a value as sensitive data from the VS Code extension](/docs/developer/vs-code-extension/send-requests/#store-variables). ## Using variables You can use double curly braces (\"{{\" and \"}}\") to reference variables throughout Postman. For example, to reference a \"username\" variable in your request's authorization settings, use the following syntax: ```js {{username}} ``` When you run a request, Postman resolves the variable and replaces it with your value. For example, you could have a request URL referencing a variable: ```js https://postman-echo.com/get?customer_id={{cust_id}} ``` Postman sends the value stored for the "cust_id" variable when the request runs. If "cust_id" has a "3" value, the request is sent to the following URL with the query parameter: ```js https://postman-echo.com/get?customer_id=3 ``` If you want to access a variable from within a request body, wrap its reference in double-quotes: ```js { "customer_id" : "{{cust_id}}" } ``` You can use variables in request URLs, parameters, headers, authorization, body, and header presets. When you hover over a variable, Postman shows its value and its scope. As you add variables to your requests, Postman displays any existing variables. ![Variable prompt](https://assets.postman.com/postman-docs/v11/var-prompt-v11-60.jpg) The prompt indicates the local value, scope (highlighted by color), and ![Warning icon](https://assets.postman.com/postman-docs/aether-icons/state-warning-stroke.svg#icon) **Overridden** status where relevant. If a global or environment variable is set as [sensitive data](#set-a-value-as-sensitive-data), you can hover over the variable and click ![View icon](https://assets.postman.com/postman-docs/aether-icons/action-view-stroke.svg#icon) **Reveal** to show its value. You can also press and hold **⌘** or **Ctrl** to show the values for all variables set as sensitive data. If a variable doesn't have a value, Postman highlights it in red. Also, a red exclamation point displays on ![Variable list icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-variableList-stroke.svg#icon) **Variables** in the upper-right of the workbench. For information on how to fix this, see [Fixing empty variables](#fixing-empty-variables). ![Unresolved variable](https://assets.postman.com/postman-docs/v11/unresolved-variable-v11-18.jpg) ### Using dynamic variables Postman provides dynamic variables you can use in your requests. Examples of dynamic variables include: * `$guid` - A v4-style GUID. * `$timestamp` - The current Unix timestamp, in seconds. * `$randomInt` - A random integer between 0 and 1000. See the [Use dynamic variables to return randomly generated data](/docs/tests-and-scripts/write-scripts/variables-list/) section for a full list. ### Using variables in scripts You can retrieve your local value of a variable in your scripts using the object representing the scope level and the `.get` method: ```js //access a variable at any scope including local pm.variables.get("variable_key"); //access a global variable pm.globals.get("variable_key"); //access a collection variable pm.collectionVariables.get("variable_key"); //access an environment variable pm.environment.get("variable_key"); //access a vault secret await pm.vault.get("secret_key") ``` Using `pm.variables.get()` to access variables in your scripts gives you the option to change variable scope without affecting your script functionality. This method returns the variable that has the highest precedence (or narrowest scope). Postman doesn't support using `pm.variables` to access and manipulate vault secrets. To use [dynamic variables](#using-dynamic-variables) in pre-request or post-response scripts, use `pm.variables.replaceIn()`. For example: ```js pm.variables.replaceIn('{{$randomFirstName}}') ``` See [Postman Sandbox API reference](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/) for more details about scripting with variables. #### Logging variables You can log variable values to the [Postman Console](/docs/sending-requests/response-data/troubleshooting-api-requests/) while your requests run. Use the following syntax in your script to log the value of a variable: ```js console.log(pm.variables.get("variable_key")); ``` To view the results, click ![Console icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-console-stroke.svg#icon) **Console** in the footer. You can also access the Console by selecting **View > Show Postman Console**. ### Using data variables The Collection Runner lets you import a CSV or a JSON file and use the values from the data file inside requests and scripts. You can't set a data variable inside Postman because it's pulled from the data file, but you can access data variables inside scripts, for example using `pm.iterationData.get("variable_name")`. For more details, see [working with data files](/docs/collections/running-collections/working-with-data-files/) and the [Postman Sandbox API reference](/docs/tests-and-scripts/write-scripts/postman-sandbox-reference/overview/). ## Share variable values You can choose to share global, environment, and collection variables, syncing the values with the Postman cloud. By default, variables have a local value that only you can access in your instance of Postman. [Share a variable value](#create-a-shared-value) to create a separate, shared value your teammates can access. You can also [update a shared value](#update-a-shared-value) and [stop sharing a value](#stop-sharing-a-shared-value). Shared values are also used with Postman features that run on the Postman cloud, like scheduled collection runs, monitors, the Postman CLI, and Newman. Once the value is shared, you and your teammates can continue to [work with your own local values](#work-with-shared-values) during development and testing, without affecting the shared value. You can reset your local value back to the shared value, if you'd like. For more information on working with variables as a team, see [Work with environments as a team in Postman](/docs/sending-requests/variables/team-environments/). You can also learn how to [share variable values from the VS Code extension](/docs/developer/vs-code-extension/send-requests/#store-variables). ### Create a shared value You can create a shared value for a variable with Editor access to the element. Be aware that the shared values of all variables are [published with your documentation](/docs/publishing-your-api/publishing-your-docs/). Make sure your shared values don't contain sensitive information such as passwords or tokens. To share a variable with your teammates, do the following: 1. Create a [global](#defining-global-variables), [environment](#defining-environment-variables), or [collection](#defining-collection-variables) variable. 1. Click ![Share icon](https://assets.postman.com/postman-docs/v11/icons/icon-cloud-v11.svg#icon) **Share** next to the variable's value you'd like to share. If you've selected the ![Options icon](https://assets.postman.com/postman-docs/aether-icons/action-options-stroke.svg#icon) **More > Shared Value** view option, enter a value. The shared values automatically update. ![Share environment variable]( --- # View types and documentation for an API collection Anyone with access to a collection with types can view them for parameters, headers, and body data. They can also view types in [the collection's documentation](/docs/publishing-your-api/viewing-documentation/#viewing-documentation-for-a-collection). Knowing more details about a requests in a collection, such as a parameter's type or if a header is required, can help others better understand your API. It can also help consumers send valid API requests, so they get successful responses instead of errors. ## View types for parameters, headers, and body data You can view types for parameters, headers, and body data in a collection. If you enter a value that isn't valid, Postman flags it with an orange underline. Hover over the text or variable with the orange underline to view a tooltip about the issue. This enables you to fix any issues before you send the request. Open a request and click the **Params** or **Headers** tab. Click an empty value for a query or path parameter or a header to view more details. For example, more details may include the accepted values and default value. A red asterisk next to the key indicates that it's required. The component type, like **string**, also displays next to the key. ![View component types](https://assets.postman.com/postman-docs/v11/types-view-properties-v11-59.jpg) Enter a value for the parameter or header, or select a value from the list if enumerations are defined. ![Show valid values](https://assets.postman.com/postman-docs/v11/types-invalid-parameter-v11-59.jpg) You can also open a request and click the **Body** tab, or open a saved example and go to the response body. Click ![Image 3: Sliders icon](https://assets.postman.com/postman-docs/v11/icons/icon-sliders-v11.jpg#icon) **Schema** to show the schema pane. Hover over a key or value in the body data to view more details, such as the description, or view any issues with the body data. ![View tooltip](https://assets.postman.com/postman-docs/v11/type-definition-body-tooltip-v11-57.jpg) When you [fork](/docs/collaborating-in-postman/using-version-control/forking-elements/) a collection with types, you fork both the collection and types added to request components, such as parameters. Note that changes to types can't be [pulled](/docs/collaborating-in-postman/using-version-control/forking-elements/#pull-updates-from-a-parent-element) into a forked collection, [merged](/docs/collaborating-in-postman/using-version-control/forking-elements/#merge-changes-from-a-fork) into the parent collection, or pulled or merged during the [pull request process](/docs/collaborating-in-postman/using-version-control/creating-pull-requests/). ## View documentation for a collection with types To [view documentation](/docs/publishing-your-api/viewing-documentation/) for a collection, click the collection's **Overview** tab. Then, click **View complete documentation**. The documentation for a collection includes any types added to parameters and headers, such as format, allowed values (enumerations), and if the component is required. ![View documentation for a collection with types](https://assets.postman.com/postman-docs/v11/type-definition-view-docs-v11-59.jpg) If a request has body data, you can view it in raw (JSON) format or as a schema. When viewing the schema, click **Show properties** to show the body data with its types. ![View body schema documentation](https://assets.postman.com/postman-docs/v11/type-definition-schema-docs-v11-12.jpg) --- # View documentation in Postman [Documentation](/docs/publishing-your-api/api-documentation-overview/) helps you get more out of the collections and APIs that you work with in Postman. View documentation to learn more about the requests in a collection or how to interact with an API's endpoints. By default, documentation for a collection or API is private. You can view the documentation for any collections or APIs that have been shared with you directly or through an internal workspace. Documentation writers can also choose to [publish their documentation](/docs/publishing-your-api/publishing-your-docs/) to make it publicly available. Anyone in the world can view the public documentation using a browser. If the associated collection is in a public workspace, people can also view the collection in Postman. ## Viewing documentation for a collection You can view the documentation for any collection that you created or for collections that have been [shared with you](/docs/collaborating-in-postman/sharing/). Postman teammates with the Viewer role can view documentation, while teammates with the Editor role can also create and update documentation. Learn more about [roles and permissions](/docs/administration/roles-and-permissions/). To view documentation for a collection, do the following: 1. Click **Collections** in the sidebar, then select a collection. 2. In the **Overview** tab, click **View complete documentation**. ![View complete documentation](https://assets.postman.com/postman-docs/v11/documentation-view-complete-v11-68.png) You can't view complete documentation if your collection has multi-protocol requests like [gRPC](/docs/sending-requests/grpc/grpc-request-interface/#the-right-sidebar) or [WebSocket](/docs/sending-requests/websocket/document-websocket-requests/). To view the description for a multi-protocol collection or folder, click it in the sidebar. To view the request's description, open the request and click ![Docs icon](https://assets.postman.com/postman-docs/aether-icons/entity-docs-stroke.svg#icon) **Documentation** in the right sidebar. The documentation includes a [description](/docs/publishing-your-api/authoring-your-documentation/#adding-descriptions-to-your-documentation) of each request and details such as the method and URL, the required authorization type, and any headers or parameters. For each request, you can view sample code in various client languages, together with example response bodies and headers. Use the following options to customize the appearance of the documentation: * **Version** - This defaults to **CURRENT** and isn't shown in the published documentation. You can't create versions or releases for collections in Postman v10 and later, but you can [publish versions of an API in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/). * **Language** - Select a language to use for sample code. * **Code Generation Settings** - Click ![Setting icon](https://assets.postman.com/postman-docs/aether-icons/descriptive-setting-stroke.svg#icon) **Settings** to customize settings for the selected language. Another way to view documentation is to visit your [user profile](https://postman.co/me/collections). Select the **Collections** tab for a list of collections that have been shared with you and your own collections. Select a collection, then click **View complete documentation** to view its documentation. ## Viewing API documentation Postman automatically creates [documentation for a collection](#viewing-documentation-for-a-collection) you create. With [types in collections](/docs/design-apis/collections/overview/), you can build out this documentation by designing your API using a collection. You can add more details, such as data type and possible values, to request parameters, headers, and bodies in an HTTP collection. Postman also automatically generates API documentation for any OpenAPI 2.0 or 3.0 API [defined in the API Builder](/docs/design-apis/api-builder/develop-apis/defining-an-api/). API developers can [create detailed documentation](/docs/publishing-your-api/documenting-your-api/) for any API to help consumers understand and interact with their API's endpoints. ### Viewing API documentation in a collection To view API documentation from a collection with types, do the following: 1. Click **Collections** in the sidebar, then select a collection with types. 2. Click the collection's **Overview** tab and click **View complete documentation**. ![View documentation for a collection with types](https://assets.postman.com/postman-docs/v11/type-definition-view-docs-v11-12.jpg) ### Viewing API documentation in the API Builder To view API documentation from the Postman API Builder, do the following: 1. Click **APIs** in the sidebar, then select an API. 2. Select a documentation source on the API's overview: * To view schema documentation, under **Definition**, click **View schema documentation**. (Schema documentation is available for OpenAPI 2.0 and 3.0 definitions.) * To view collection documentation, select a collection and click **View complete documentation**. To get sample code in a different language, select it in the **Language** dropdown list. ![Viewing API documentation](https://assets.postman.com/postman-docs/v10/documentation-view-schema-docs-v10-16.jpg) API developers can publish different versions of an API in the Postman API Builder. You can view documentation for each published version. Learn more about [viewing a published API version](/docs/design-apis/api-builder/versioning-an-api/api-versions/). ## Viewing public documentation Public documentation is hosted by Postman. To access public documentation, enter the documentation URL in the address bar of your browser. The URL is generated by Postman during the [publication process](/docs/publishing-your-api/publishing-your-docs/#share-your-public-docs). Each request entry can have the following: * A description of the request * The required authorization type * The method and URL * Any headers or parameters * Sample client code for the request * Example response bodies and headers Use the options in the header to customize the appearance of the documentation: * **Version** - If the documentation has multiple versions, you can select a specific release to view. (Starting with Postman v10, you can no longer create versions or releases for collections, but you can [publish versions of an API in the Postman API Builder](/docs/design-apis/api-builder/versioning-an-api/api-versions/).) * **Environment** - If an [environment](/docs/publishing-your-api/document-a-collection/#associate-environments-with-documentation) was published with the documentation, you can select it to populate any variables. * **Layout** - **Double column** displays sample code in a column next to the documentation. **Single column** displays sample code inline beneath each request. * **Language** - Select a language to use for sample code. * **Language Settings** - Select the language settings icon ![Language settings icon](https://assets.postman.com/postman-docs/icon-settings-v9.jpg#icon) to customize settings for any of the available languages. * **Theme** - Select the theme icon ![Light theme icon](https://assets.postman.com/postman-docs/v10/icon-theme-light-v10.jpg#icon) or ![Dark theme icon](https://assets.postman.com/postman-docs/v10/icon-theme-dark-v10.jpg#icon) to switch between light and dark themes. ![Published documentation example](https://assets.postman.com/postman-docs/v11/documentation-published-docs-v11-23.jpg) ## Linking to public documentation Want to share a specific endpoint with someone or bookmark it for later? You can save links to sections in public documentation, including the introduction, requests, folders, and responses. To save a link, select a section, folder, or request in the sidebar. Copy the URL in your browser's address bar, or save it as a bookmark. Next time, you can use the URL to link directly to the selected section. --- # View monitor results [Monitors](/docs/monitoring-your-api/setting-up-monitor/) continuously track the health and performance of your APIs. With Postman, you can stay up to date on what's happening across all monitors in your workspace. Or you can review individual monitors to examine test results and performance over time. You can view your monitors in Postman by navigating to your workspace and clicking **Monitors** in the sidebar. Select your monitor to open a tab detailing its latest performance. ![View monitor in tab](https://assets.postman.com/postman-docs/v11/view-monitor-in-tab-v11.png) Monitors are visible to all members of the workspace. ## Monitor summary You can use the monitor summary to understand how your APIs have performed over time. Each monitor run is represented by a bar in the graph. By default, this displays the monitor's **Run summary** view. The upper section charts your monitor's average response time for each run, while the lower section visualizes the number of failed tests for each run across all regions. To view the exact values for failed percentage and response time, hover over each run individually. ![Monitor summary](https://assets.postman.com/postman-docs/v11/monitor-summary-with-hover-v11.jpg) A red bar indicates that either tests failed or errors occurred during the run. For more information, view your [Console Log](/docs/monitoring-your-api/viewing-monitor-results/#console-log). ### Individual requests You can select **Individual requests** to break down your monitor summary into separate requests. ![Request split](https://assets.postman.com/postman-docs/v11/monitors-individual-requests-v11.jpg) ## Filters You can use filters to identify recurring patterns in your monitoring runs by selecting particular requests, run types, results, and regions (if applicable). You can **Clear Filters** to return to your original dashboard view. ### Filter by request You can filter by request to compare an individual request's response time in different runs. Select **All Requests** under **Filter By**, then select your request. ### Filter by type You can filter by run type to compare how the response time changes between manual runs, scheduled runs, webhook runs, and Postman CLI runs. Click **Type: All**, then select the type of run you'd like to analyze further. Manual runs are initiated in Postman or are triggered by the [Postman API](https://www.postman.com/postman/postman-public-workspace/request/80oupaf/run-a-monitor). Scheduled runs are initiated by the schedule you set when creating or editing your monitor. Webhook runs are initiated by integrations you've created. Postman CLI runs are triggered by the [`postman monitor run` command](/docs/postman-cli/postman-cli-options/#postman-monitor-run). ### Filter by run result Each run is labeled based on its result: * **Successful** - Your monitor completed the run with no issues and passed all tests. * **Failure** - Your monitor completed the run, however one or more tests failed. * **Error** - Your monitor was unable to complete its run due to an error. An error can occur if there is a syntax error in the code you've written, a network error, or for various other reasons. If you get an error, your [Console Log](#console-log) will help you identify what caused it. * **Abort** - Your monitor timed out because it didn't complete its run within the allotted 10 minutes (Postman Free plans) or 15 minutes (Postman paid plans). You can filter by run result to compare how your runs with the same result have differed. Click **Run result: All**, then select one or more types of run results to view. ### Filter by region or runner You can filter by [regions or runners](/docs/monitoring-your-api/setting-up-monitor/#add-regions-and-runners) to compare API health or performance across multiple geographic regions or networks. Click **All Runners**, then select a region or runner to view its results. This feature is available if you selected multiple regions or runners when you created or last edited your monitor. Learn more about [regions and runners](/docs/monitoring-your-api/setting-up-monitor/#add-regions-and-runners). ### Filter by formula You can filter by mathematical formula to view the average, sum, minimum, and maximum response time for each run: * **Average** - The average of the total response time across all regions. * **Sum** - The sum of the response time across all regions. * **Minimum** - The minimum total response time for a run across all regions. * **Maximum** - The maximum total response time for a run across all regions. Click **Average** to open the menu, then select an option. To view the calculated response time value, you can hover over each run individually. ## Time traverse You can review past run results to understand what happened at a particular point in time. To do so, click **Go to** in the upper-left corner of the monitor summary or request split graph. Select the time and date, then click **Apply** to view a specific run. ![Time traverse](https://assets.postman.com/postman-docs/v11/monitors-time-traverse-v11.jpg) To revert the view to your most recent runs, select the time and date you defined in the upper-left corner of the graph, then click **Reset**. ## Test results Click **All Tests** to get more detailed information on your tests, including which passed or failed, the response codes, the response times, and any failed test assertions. ![Test results](https://assets.postman.com/postman-docs/v11/view-monitor-results-test-v11-75.png) To learn more about the test results for each request, you can view the following: * View the test results for a particular region by selecting it from the **Region** dropdown list. You can select a different region if your monitor is configured to run in multiple regions. * Click the **All Tests** tab to view all requests in the monitor with tests that passed or failed, including requests without any tests. Click the **Passed**, or **Failed** tab to only view requests with tests in that category. The number of tests in that category appears next to each tab. * Next to each request you can view the response code, time, and size. * Next to each request you can view the number of tests that passed (green background) or failed (red background). Hover over one of these numbers to view a detailed breakdown of the tests in the request. * Click a request to view which tests passed or failed. * Click the name of a request to open the request in a new tab. * If your requests are in a folder, click the name of the folder to open it in a new tab. ## Errors * Click the **Errors** tab to filter results by requests that encountered errors. Note that _errors_ indicate runtime issues like timeout or TLS handshake errors. _Failed_ requests occur when one or more user-specified checks (like post-request scripts) don't match expectations. * The requests in your collection run that have errors appear in the run results page with an error badge and the error message. Badges identify errors as related to **NETWORK**, **REQUEST**, or **SCRIPT** issues. ![Monitor errors](https://assets.postman.com/postman-docs/v11/monitor-errors-v11-75.png) ## Console log Click the **Console Log** tab to view and search monitor run details along with the [`console.log`](/docs/sending-requests/response-data/troubleshooting-api-requests/) statements that run as part of your pre-request and post-response scripts in the Postman Console. Run details specify the various stages of a monitor run such as preparing run, running, rerunning ([if applicable](/docs/monitoring-your-api/setting-up-monitor/#use-retry-on-failure)), and the run result, along with error and test failure information. Selecting a request in the Console log will open it in a tab, allowing you to review and edit the request as needed. If your monitor is configured to run in multiple regions, you can view the Console logs for a particular region by selecting it from **Region**. ![Console log](https://assets.postman.com/postman-docs/v11/monitor-view-console-log-v11-75-1.png) You can use the Console to both troubleshoot issues and learn more about an individual run's behavior. Find specific strings with the Console log's search feature. Searching enables you to highlight and cycle through error messages and codes automatically instead of scanning the log manually. Click **Search console logs** and enter a string. Matches are highlighted in the log, and you can click ![Down Large icon](https://assets.postman.com/postman-docs/aether-icons/direction-down-large.svg#icon) **Next match** and ![Up Large icon](https://assets.postman.com/postman-docs/aether-icons/direction-up-large.svg#icon) **Previous match** to cycle through them. Click ![Close icon](https://assets.postman.com/postman-docs/aether-icons/action-close-stroke.svg#icon) **Clear search** to clear the search field and results. **Monitor run logs are retained for a period of six months.** If you select a monitor run that's outside the retention period, you can view the number of failed tests and errors. Other monitor run details will no longer be available. To request this information, contact [Postman support](https://www.postman.com/support/). ## Activity feed You can view a monitor's activity by clicking the activity feed icon ![Activity feed icon](https://assets.postman.com/postman-docs/icon-activity-feed-v9.jpg#icon) in the upper-right corner. ![Activity feed](https://assets.postman.com/postman-docs/v11/monitor-activity-feed-v11.jpg) You can check these logs to learn when a monitor was created, edited, paused, or resumed running, and which team member performed each action. ## Monitor details You can view details about a monitor by clicking the information icon ![Information icon](https://assets.postman.com/postman-docs/icon-information-v9-5.jpg#icon) in the upper-right corner. Here you can view a monitor's ID, creator, creation date and time, collection, environment, and integration options. ![Monitor details](https://assets.postman.com/postman-docs/v11/monitor-information-v11.jpg) ## Troubleshooting Learn how to [troubleshoot your monitors](/docs/monitoring-your-api/troubleshooting-monitors/) and check out [Postman monitoring FAQs](/docs/monitoring-your-api/faqs-monitors/). --- # Visualize request responses using Postman Visualizer The _Postman Visualizer_ provides a programmable way to visually represent your request [responses](/docs/sending-requests/response-data/responses/). You can also use Postman's AI assistant Postbot to automate your visualization. If you add a visualization script to the **Scripts** tab of your request, the result renders in the **Visualization** tab for the response body. If you don't create a Visualizer script, you can select **Visualize** to get Postbot to generate the visualization. ![Response visualization](https://assets.postman.com/postman-docs/v11/response-pane-visualization-v11.23.jpg) The Visualizer enables you to present your response data in ways that help to make sense of it. You can use this to model and highlight the information that's relevant to your project, instead of having to read through raw response data. When you [share a Postman Collection](/docs/collaborating-in-postman/sharing/), other people on your team can also understand your visualizations within the context of each request. ## Visualize response data To visualize your response data, add code to the **Pre-request** or **Post-response** [script](/docs/tests-and-scripts/write-scripts/intro-to-scripts/) for the request. The `pm.visualizer.set()` method will apply your Visualizer code to the data and present it in the **Visualization** tab when the request runs. ### Add Visualizer code The `pm.visualizer.set()` method accepts a [Handlebars](https://handlebarsjs.com/) template string as its first parameter. The second parameter is the data you want to use the template to display. Read on to learn how you can build a Handlebars template and pass data to it. To see an example of the Visualizer in action, select **Run in Postman** and fork the enclosing collection in Postman. ![Run in Postman](https://run.pstmn.io/button.svg) In the first request, the example endpoint responds with a list of names and email addresses with the following JSON response body structure: ```js [ { "name": "Alice", "email": "alice@example.com" }, { "name": "Jack", "email": "jack@example.com" }, // ... and so on ] ``` The Visualizer code creates a Handlebars template to render a table displaying the names and email addresses by looping over an array. Handlebars can do this with the `{{#each}}` tag. The following runs as a **Post-response** script in the request: ```js var template = ` {{#each response}} {{/each}}
Name Email
{{name}} {{email}}
`; ``` The variable names inside the double curly braces in the template will be substituted by the data passed to the `pm.visualizer.set()` method. To apply the template, the following code completes the **Post-response** script: ```js // Set visualizer pm.visualizer.set(template, { // Pass the response body parsed as JSON as `data` response: pm.response.json() }); ``` The `template` variable is the template string created earlier. The second argument passed is an object defined as the `response` property—this is the variable that the template expects in the `{{#each response}}` loop. The value assigned to the `response` property is the response JSON data from the request parsed as an object. ### View visualizations **Send** the request in Postman and select the **Visualization** tab. Postman renders the table as HTML, as it would be in a web browser. ![Visualize a table](https://assets.postman.com/postman-docs/v11/visualizer-table-v11.23.jpg) ### Add styling and interaction to visualizations You can load an external stylesheet using `` tags in your HTML template code, using the same technique as adding a stylesheet to a web page. You can also add stylesheets as `