Postman global variables are actually not global in the way you’d expect, and that’s precisely why they’re so powerful for sharing values across workspaces.
Let’s see how this plays out. Imagine you have a collection of API calls for a project that spans multiple environments, and you want to keep your base URLs or authentication tokens consistent.
Here’s a collection that uses a global variable baseUrl for its requests:
{
"info": {
"_postman_id": "...",
"name": "My Project API",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"item": [
{
"name": "Get Users",
"request": {
"method": "GET",
"header": [],
"url": {
"raw": "{{baseUrl}}/users",
"host": [
"{{baseUrl}}"
],
"path": [
"users"
]
}
},
"response": []
},
{
"name": "Create User",
"request": {
"method": "POST",
"header": [
{
"key": "Content-Type",
"value": "application/json"
}
],
"body": {
"mode": "raw",
"raw": "{\"name\": \"New User\"}"
},
"url": {
"raw": "{{baseUrl}}/users",
"host": [
"{{baseUrl}}"
],
"path": [
"users"
]
}
},
"response": []
}
]
}
When you run these requests, Postman looks for the baseUrl variable. If it’s not found in the current environment, it then checks the collection’s own variables, and then it looks at the "Globals" tab in the "Manage Environments" modal.
The "Globals" tab is where you define variables that are truly accessible across all your workspaces. This is the key to sharing. You’re not limited to a single workspace; you can define a baseUrl there, and any collection, regardless of the workspace it resides in, can reference it.
Here’s the crucial part: you define these "global" variables in the "Manage Environments" modal, by clicking the "Globals" button.
You can add variables like:
baseUrl:https://api.example.com/v1authToken:Bearer abcdef123456tenantId:my-awesome-tenant
When you run a request that uses {{baseUrl}}, Postman first checks your active environment. If it finds baseUrl there, it uses that value. If not, it falls back to the value defined in the "Globals" tab. This fallback mechanism is what allows true cross-workspace sharing. You can have different environments for different projects (e.g., Development, Staging, Production) within a single workspace, but the "Globals" are always there, ready to be used by any collection, anywhere.
This setup is incredibly useful for maintaining consistency in things like API endpoints, authentication tokens, or shared configuration values. Instead of duplicating these values in every collection or environment, you define them once in "Globals" and reference them everywhere. It significantly reduces errors and makes updating shared values a breeze.
The real magic of Postman’s "Globals" is that they aren’t tied to any specific workspace. They live in a separate, higher scope. When you set a variable in the "Globals" tab, you’re essentially creating a persistent, universally accessible variable for your Postman account. This means a collection you created in "Workspace A" can seamlessly use a baseUrl defined in "Globals," even if you later move that collection to "Workspace B" or open it on a different machine where you’re logged into the same Postman account.
The common misconception is that "Global Variables" means variables within the current workspace that are globally accessible to that workspace. Postman’s "Globals" bypass this limitation entirely, acting as a true account-wide variable store.
This system allows you to manage your API testing configurations with a level of abstraction that is often overlooked. You can effectively create a "master configuration" for your common API elements and then layer project-specific environments on top of it.
The next step after mastering cross-workspace sharing is understanding how environment-specific variables override global ones, and how to dynamically set variables within scripts to further control your API calls.