TL;DR
Yes, Postman stores API keys and other credentials when you save them in environment variables with cloud sync enabled, which is the default. This does not mean Postman is misusing your keys, but it does mean your credentials exist on a third-party server. Understanding this helps you decide whether Postman’s default setup fits your security requirements, and when a local-first tool like Apidog is the better choice.
Introduction
The question “does Postman store my API keys?” comes up regularly in developer communities. Search Reddit’s r/webdev or r/programming, and you will find threads from developers asking the same thing, often prompted by a security audit finding or a conversation with their security team.
The concern is legitimate. API keys are essentially passwords for your services. A leaked API key for a payment processor can result in fraudulent charges. A leaked cloud provider key can lead to unauthorized resource creation, data exfiltration, or a bill in the tens of thousands of dollars. Developers who store these keys in their development tools are extending their trust to that tool.
Most developers know not to commit API keys to public GitHub repositories. The awareness around API client tools is lower. Postman has over 30 million users, which means a large number of developers are storing credentials in a tool without fully understanding where those credentials go.
This article gives a direct, technical answer to the API key storage question and explains what you can do about it.
The direct answer: yes, with important context
Postman stores API keys in the following scenarios:
When you use environment variables. Postman’s environment system is the standard way to store credentials for use in requests. If you create an environment variable called API_KEY with a value of sk-abc123..., that value is synced to Postman’s cloud servers when cloud sync is active. This is the default behavior.
When you use collection variables. Variables stored at the collection level sync the same way.
When you use global variables. Global variables sync to your Postman account.
When credentials appear in request bodies or headers. If you hard-code a credential in a request header (like Authorization: Bearer sk-abc123...) and save the collection, that value is synced.
What does not sync by default: Values stored in Postman Vault. Vault is a local credential store that explicitly does not sync to Postman’s cloud. It requires manually storing credentials there rather than in environment variables.
What “cloud sync” actually means
Cloud sync in Postman means that a copy of your workspace data is continuously maintained on Postman’s servers. This happens automatically in the background. You do not need to click “save” or “sync.” As you work, changes propagate to the cloud.
The purpose is collaboration and persistence. If your laptop dies, your work is not lost because it is on Postman’s cloud. If you switch machines, your collections and environments follow you because they sync to your account.
The security implication is that your API keys, which you might think of as living in the app on your laptop, are actually living in both places: your laptop and Postman’s cloud.
Postman encrypts this data. The specific scheme is AES-256 encryption for data at rest and TLS for data in transit. This is standard and reasonable encryption. The keys are not sitting in plaintext on a Postman database somewhere.
But encryption does not mean inaccessible. Postman can access the data to provide the service. If your Postman account is compromised (via phishing, credential stuffing, or a data breach at Postman), your stored API keys are potentially accessible to whoever gained access.
What Postman’s privacy policy says about your credentials
Postman’s privacy policy describes them as a data processor, not a data controller, for the content of your workspaces. They process your data to provide the service. They do not sell your workspace content to third parties.
Key points from their data handling documentation:
Purpose limitation. Postman states they use workspace content to provide and improve the service, not for marketing or resale.
Subprocessors. Postman uses third-party services for infrastructure, support, and analytics. These subprocessors may process your data as part of delivering the service. Postman publishes a list of subprocessors in their documentation.
Government requests. As a US company, Postman is subject to US law enforcement requests including national security letters. Data stored on US servers can be compelled through legal process.
Breach notification. Postman’s terms include security breach notification provisions. If your data is involved in a breach, Postman is contractually required to notify you.
Data deletion. When you delete your account, Postman deletes your data. Backup retention schedules vary.
This is a normal policy for a B2B SaaS company. It is not indicative of bad intent. The question is whether your organization’s security policy permits storing API credentials with a third-party cloud service, and whether you have reviewed that policy against what Postman actually does.
The workspace visibility dimension
Beyond cloud sync, there is a second dimension to Postman’s API key risk: workspace visibility.
Postman workspaces can be Public, Team, or Private. Public workspaces are accessible to anyone without authentication. They are searchable on Postman’s public API network.
In 2023, CloudSEK researchers found over 30,000 public Postman workspaces containing real API keys, tokens, and other credentials. Companies including Razorpay and New Relic had sensitive credentials in public workspaces. The exposure was not from a breach. It was from developers setting workspaces to public without realizing that the same workspace held real credentials in environment variables.
This is the second, distinct risk. Even if you trust Postman’s cloud security, misconfiguring workspace visibility can expose your credentials to the entire internet.
Who is most at risk
Not every developer faces the same level of risk from Postman’s credential handling. The risk is higher when:
You store production credentials in Postman. Testing against production APIs with production keys means production credentials are in Postman’s cloud. This is common and genuinely risky.
Your team workspace has broad access. If everyone in a 50-person company is in the same Postman team with access to all workspaces, a single compromised account exposes all credentials.
You work in a regulated industry. Healthcare, finance, government, and defense organizations often have explicit rules about where certain data can be stored. Storing API keys that grant access to systems holding PHI or financial data in a third-party cloud may violate those rules.
Your API keys have high privilege. A read-only key for a public API is low risk. An admin key for your cloud infrastructure or payment processor is high risk. The consequences of exposure scale with the privilege level of the key.
You are a contractor or consultant. Storing client API credentials in your personal Postman account means client credentials exist on a third-party server tied to your personal account. If that account is compromised, client security is at risk.
How Postman Vault changes the picture
Postman Vault, introduced to address these concerns, stores credential values locally on your machine. Values in the Vault do not sync to Postman’s cloud. You reference them in requests using {{vault:variable_name}} syntax.
This is a meaningful security improvement. API keys stored in Vault are not on Postman’s servers.
The limitations: it requires a deliberate behavior change. Developers have years of muscle memory around environment variables. Vault requires each team member to set up their own local vault, which means credentials are not shared through Postman’s team features. You need a separate secret sharing mechanism for onboarding team members.
Vault also does not address credentials that appear directly in request headers or bodies, or credentials in collection and global variables.
Local-first tools and the alternative model
The fundamental difference with local-first tools is the default. With Postman, cloud sync is on unless you turn it off (and even then, it requires Vault for credentials specifically). With Apidog, data stays local unless you turn sync on.
Apidog’s environment variables are stored in local SQLite databases on your machine. They do not sync anywhere without your explicit action. If you never enable team sync, your API keys never leave your machine.
For developers who need the tool to handle secrets safely without any configuration, this is a meaningful difference. You do not have to know about Vault, configure it, and train your whole team to use it. The secure behavior is the default behavior.
Bruno takes this further: it stores everything in files on your filesystem. There is no Apidog-style cloud option at all. If local-only is a hard requirement, Bruno removes the question entirely.
Practical recommendations
Audit what you have stored now. Open your Postman environments and review every variable. Look for API keys, tokens, passwords, and secrets. Know what is in Postman’s cloud.
Move to Postman Vault for credentials. For any credentials that need to stay in Postman, migrate them to Vault. Update your team’s documentation and onboarding process.
Use scoped, limited-privilege keys for testing. Create API keys specifically for development and testing with the minimum required permissions. If a testing key leaks, the impact is bounded. Never use admin or production keys in development tools.
Review workspace visibility. Ensure no workspace with credentials is set to Public. Default to Private for all workspaces.
Consider your threat model. For personal projects and non-sensitive APIs, Postman’s current setup is probably fine. For production credentials, regulated data, or client work, the extra steps to achieve security with Postman may be easier to just avoid by using a local-first tool.
FAQ
Does Postman sell my API keys or workspace data?No. Postman’s privacy policy states they do not sell user workspace content. They use it to provide and improve the service.
If my Postman account is compromised, can an attacker get my API keys?Yes, if those keys are stored in environment variables that sync to the cloud. This is why using Postman Vault for credentials and enabling multi-factor authentication on your Postman account are both important.
Does Postman support multi-factor authentication?Yes. Postman supports MFA via authenticator apps. Enabling MFA significantly reduces the risk of account compromise.
Are API keys in Postman Vault safe?Keys stored in Postman Vault are stored locally and do not sync to Postman’s cloud. They are as safe as your local machine. If your machine is compromised, Vault contents are accessible. But they are not accessible to Postman or to someone who compromises your Postman account without also compromising your machine.
What should I use if I can’t store API keys in any cloud tool?Bruno is the most restrictive option, with no cloud component at all. Apidog in local mode stores everything on-device. For team environments with no cloud tools at all, Hoppscotch self-hosted or Apidog self-hosted give you collaboration without relying on a third-party cloud.
How do I remove my API keys from Postman’s cloud?Go to your Postman environments, delete the variables containing credentials, and replace them with references to Vault. If you want to remove historical sync data, you would need to delete the workspace and any associated data from your Postman account settings.
The answer to “does Postman collect my API keys” is yes, under default settings and common usage patterns. That does not make Postman a bad product. It means you need to understand the data model before storing sensitive credentials, and use Vault or an alternative tool when your security requirements demand it.