Context and problem
Many Postman users, especially those in healthcare and financial services, raised concerns about secrets (API keys, tokens) being stored in Postman. Their primary concern was data security—they did not want PII (Personally Identifiable Information) or PHI (Protected Health Information) stored in Postman’s cloud.
No secure, local way to store sensitive credentials within Postman.
Existing workarounds involved external vaults, which disrupted the workflow.
Developers needed a trusted yet seamless solution.Data gathering
Exploring possible solutions
From the start, designers and I worked closely with engineers to understand the technical nuances of different vaults and API security. We dived into how third-party vaults worked, the encryption standards used, and what made secret management both secure and usable.
We held deep-dive sessions with engineers, mapped out workflows, and talked to real users—especially those who had requested a vault feature to understand their mentality around security.
After weeks of exploration, we landed on a few potential approaches that seemed viable.
1. Integrating with third-party vaults (e.g., HashiCorp Vault, AWS Secrets Manager)
Leverage existing secret management solutions by allowing users to connect their Postman workflows to external vaults.
❌ Why it didn’t work:
Setup complexity: Users would need to manage a separate system, increasing onboarding friction.
Access management: Different vaults had different permission models, leading to inconsistent experiences inside Postman.
Reliability: Any downtime in the external vault would directly impact API testing in Postman.
2. Storing in Postman environments
Use Postman’s existing environment variables to store secrets securely in the cloud.
❌ Why it didn’t work:
Security concerns: Again, many users (especially in regulated industries like healthcare and finance) did not want their secrets stored in the cloud.
3. Local file-based storage (User’s system HDD)
Store secrets in a local file on the user’s system that Postman could access.
❌ Why it didn’t work:
Security risks: A plaintext file could be easily compromised if the system was breached.
Portability issues: Users working across multiple devices or teams wouldn’t have seamless access.
Management overhead: Manually handling encrypted files introduced unnecessary complexity.
The solution: Postman Vault
After evaluating these options, we realized that a built-in local vault provided the best balance of security, usability, and performance.
Local-first approach: Secrets are stored on the user’s local hard drive but remain fully encrypted. Every time a user accesses a secret, it’s decrypted on demand through Postman.
Cross-workspace usability: Vault secrets work across all Postman workspaces without syncing to the cloud.
Seamless developer experience: Users can store and reference secrets directly within Postman—without external dependencies.
Familiar and intuitive: The experience feels native to Postman, requiring minimal learning.
Content challenges & approach
The language had to be:
Technical enough to resonate with developers.
Simple enough to be accessible.
Trustworthy enough to reinforce security.
Educating users about Vault behavior since these don't sync like other postman features
Educating how to use Vault secrets
Solution implementation
Introducing Postman Vault to users
To ensure the right users discovered Vault, we initially tested it with power users—people who had previously requested a local secrets manager and those who had encountered security concerns in Postman.
We implemented two different email campaigns:
General invite – Targeted at users who might benefit from Vault based on usage patterns.
Interest-based Invite – Specifically crafted for users who had previously requested better security options.
Additionally, we introduced a contextual toast notification inside Postman that appeared when users interacted with API key-related features. The goal was to make the toast feel contextual and increase engagement.
Feedback, metrics & iterations
To ensure strong adoption, we tracked key user engagement metrics, including:
Click rates on the toast notification
Return rate to the Vault
Support queries related to Vault
User feedback from emails
These insights helped us continuously iterate on the in-app touch points.
Iteration 1: Low engagement
❌ The first version had low interaction. Feedback revealed that the language lacked clarity and urgency.
Iteration 2: More action-oriented & exclusive
✅ We refined the messaging to be clearer, more action-driven, and added exclusivity to make users feel valued. This change increased the click-through rate by 23%.
Iteration 3: Solving the return-visit problem
❌ Despite better engagement, many users weren’t returning to Vault after the initial setup
❌ The toast notification blended too much with the app’s light theme, making it easy to ignore.
✅ Increased contrast to improve visibility.
✅ Replaced the toast with a popover featuring a directional pointer, guiding users directly to Vault.
This helped users easily find and return to Vault, solving the re-engagement issue.
With these refinements, 30K users adopted Vault (created at least 3 secrets) within the first three months.
Onboarding Experience That Builds Trust
Once the touch points were refined. We moved on to the onboarding experience for Postman Vault. We had to ensure they understood why Vault exists, how it works, and what security precautions they need to take.
Key considerations
Reinforce security
We needed to educate users about security best practices without making the process feel overwhelming.
Terms like “encryption,” “local storage,” and “vault key” had to be used to be consistent with the industry standard and familiarity.
Progressive disclosure
As much as we wanted the set up to be quick and one step it didn't make sense. Instead of dumping all security details upfront, we guided users step by step. This was the only solution to make adoption long term.
Each screen was designed to focus on a single action, keeping cognitive load low. This way they could take their time in understanding and consuming the information.
Encouraging the right behavior:
The Vault Key step was a critical moment. Losing this key meant losing all stored secrets.
Instead of a generic warning, we reinforced why saving the key matters and nudged users toward using password managers.We also tried to personalize the message here based on mac and windows users.
With these in mind, here’s how we structured the onboarding flow:
Step 1: Vault landing page
Before users commit to setting up Vault, they need to understand what it does and why it’s useful. This ensures the right adoption and prevents abandonment.
Design & content choices
Minimalist UI: Kept the screen simple, focusing on the core value proposition.
Security clarity: Used “Locally store sensitive data in Vault as secrets” to highlight that data stays local.
Usage education: Introduced {{vault:secret-name}} syntax early so users immediately understood how to reference secrets. From past insights, we knew that developers engage more when they see the full workflow. Showing how easy it is to retrieve stored secrets reassures users and encourages adoption.
Straightforward CTA: “Set Up Vault”. Direct and action-driven.
Step 2: Saving the vault key
Losing the vault key = losing access to secrets. This is the most critical action in onboarding. Users must understand the risk and save their vault key.
Design & content choices
Bold warning message: Clearly stated the consequences: “Losing the key will result in the loss of all your secrets.”
Copy-to-clipboard feature: Allowed users to save their key effortlessly.
Pre-selected checkbox: Nudged users to save the key in their password manager.
Secondary CTA: “Download key”—offered multiple ways to store it securely.
Explicit consequence: Avoided vague warnings—clearly explained what happens if the key is lost.
Behavior nudging: Encouraged users to use a password manager instead of storing keys manually.
Step 3: Unlocking Vault with key
After setting up Vault, users are immediately asked to sign in with their vault key. This ensures they saved their key before proceeding and also prepares them for how they’ll access Vault in the future.
Design & content choices
Minimal input field: Kept the UI distraction-free, focusing only on key entry.
Reassuring illustration: Showed an astronaut accessing a secure portal, reinforcing control and security.
Clear escape hatch: Included a reset option in case users misplaced their key: “Couldn’t find the key? Reset Vault.”
Trust-building: “Unlock Vault and access its secrets by entering this device’s vault key.” This subtly reinforces that Vault is local and linked to this device.
