Postman is probably not HIPAA-compliant

We’ve noticed that in the healthcare world, Postman seems to be the most popular local client for working with APIs. While we think Postman is a great general-purpose tool for testing APIs, we don’t use it internally and don’t recommend that customers use it for processing PHI (Protected Health Information).

As there seems to be an awareness gap in the healthcare industry about Postman’s shortcomings when it comes to processing PHI, we wanted to publish a post outlining the issues.

The root of the problem is that Postman stores request history – including full request payloads – on its cloud servers, and you can’t turn this feature off without impractical workarounds that we’ve rarely seen used in practice. Many users are unaware that request payloads containing PHI are being synced to Postman’s servers, and if their company does not have a BAA in place with Postman, they may be unintentionally falling short of HIPAA requirements.

Why Postman isn’t safe for requests containing PHI

Postman’s core flaw for HIPAA compliance is its sync feature. Sync makes your Postman data available across devices and Postman’s web client. This lets you reuse prior API requests and share them with others. But if you're sending PHI, you’re leaking sensitive patient data to Postman, a third party, without knowing it.

Sync works by uploading your Postman data, including API request history, to Postman’s cloud servers. There’s no opt-in; syncs occur automatically while you’re logged in to Postman. You can’t stop syncing without logging out, which cuts off basic features like OpenAPI imports.

Despite this, many companies that offer APIs in the healthcare ecosystem – including healthcare clearinghouses – recommend Postman for API testing (Postman itself even highlights these APIs in their curated Healthcare APIs directory, and may be unaware of the necessary caveats).

Postman’s workarounds are impractical

There are multiple GitHub issues and community posts that raise concerns about Postman and HIPAA compliance. Postman’s own docs state:

Some organizations have security guidelines that prevent team members from syncing data to the Postman cloud.

Postman offers two workarounds:

• A lightweight API client: Essentially just using Postman while logged out. However, if you log back in, syncing starts again.
  
  

• Postman Vault: Secrets that you can reference as variables in requests. Vault secrets aren’t synced to the cloud. However, using variables for every request payload would be tedious.

Neither of these solutions scale – data leakage is one login or one bad request away.

Alternative API clients

Ultimately, proper API client usage is your responsibility. You should do your own research to determine HIPAA requirements – you can use any tool in a non-HIPAA-compliant way. At a minimum, if you are going to test APIs that handle PHI from your local machine, use an API client that defaults to local-only storage.

The following open-source API clients use an offline-first approach, which sidesteps the fundamental Postman problem. Each client also supports OpenAPI imports, which you can use to import the Stedi OpenAPI specs. With that said, you should have your security and compliance teams review any tool carefully, especially because applications evolve – there was a time that Postman was local-only, too.

• Bruno (repo): A local-only API client built to avoid cloud syncing. Bruno has several interfaces, including a desktop app, CLI, and VS Code extension.
  
  

• Pororoca (repo): A desktop-only API client with no cloud sync, built for secure local testing. Poroca’s data policy states that no data is synced to remote servers.
  
  

• Yaak (repo): A simple, fast desktop API client. Yaak supports several import formats, including Postman collections, OpenAPI, and Insomnia.

Secure defaults matter

Postman is a great tool for general APIs. But healthcare isn't general software. When you’re handling PHI, invisible cloud storage is a failure, not a feature. Secure defaults, like local-only storage, prevent developers from accidentally exposing sensitive data. Of course, even if your requests never leave the machine, every laptop that handles PHI should still be locked down with best practices like full-disk encryption, strong authentication, automatic screen-lock, and remote-wipe.

—

Security is job zero at Stedi. We build every system and design every API with secure defaults in mind. If you want a healthcare clearinghouse that’s serious about security and developer experience, start with Stedi. Reach out or create a free sandbox today.

—

Disclaimer: Product features, security controls, and regulations change over time. Your organization must perform its own HIPAA risk analysis, implement appropriate administrative, technical, and physical safeguards, and verify that every vendor and workflow meets current legal and policy requirements.