postman-app-support: where Postman bug reports, billing and legacy issues split apart

Five top level entries and not one line of source code

Apart from a .gitignore file, everything this repository contains sits in this listing:

.github/
CONTRIBUTING.md
README.md
SECURITY.md
release-notes/

There is no lib directory, no package manifest, no build script and no application. The repository is a support front desk for the Postman app, and its default branch is named support rather than main or master, which is the layout you would expect from something that exists to receive issues instead of to ship code. If you came looking for the API client or the desktop app, the source is not here, and the presence of release-notes/ is about notes rather than published packages: the repository has no GitHub releases at all.

What you can take from here is a routing decision. The README names the issue tracker as the place for feature requests, new integration ideas and bug reports, and every other section of the file either redirects you somewhere else or points at documentation.

A bug report has to carry the version, the OS and the steps

Three fields are named as required in any bug report: steps to reproduce the bug, the Postman version in use, and the OS version. On top of those, the README asks for anything else that narrows the problem down, naming collections, data dumps, console errors and screenshots as the useful attachments.

That list is the practical standard here, and it is worth reading as a checklist before you open a tab on the tracker. A report with only a description of the symptom forces a round trip where a maintainer asks for the version anyway. The data dump and console error suggestions matter more than they look: the app is a tool for building and using APIs, so the request you were sending when it misbehaved is part of the evidence.

Feature requests and integration ideas go to the same tracker with no such checklist attached, which is the one asymmetry in the routing: bugs have a template in practice, ideas do not.

Search the tracker before you file, the request is made twice

The first substantive instruction in the README is not about how to report but about whether to report at all. It asks you to search the issue tracker to see whether someone else has already filed the issue and whether a known solution exists, and it calls that the fastest way to find a solution. A few lines later it also asks you to read the guidelines for reporting issues in CONTRIBUTING.md.

Both requests matter in practice. The tracker is the destination for bugs, feature requests and integration ideas at once, so a duplicate question is often one search away, and the guidelines in CONTRIBUTING.md are what turn a symptom into a report the maintainers can act on.

The other channel the README nominates for staying informed is the @getpostman account on X, described as the best place for news, features and releases. That is where change announcements go; the tracker is where work gets recorded.

Billing and account questions are pushed off the tracker

One category is explicitly walled off. Billing and account specific queries are told to go to the support page and be submitted as a ticket, and the README does not route them anywhere else. That is a sound separation on paper, since a public issue thread is the wrong place for account details, and a ticket gives the support team somewhere private to work.

The practical consequence for a user is that there are two support systems with two different response expectations, and only one of them is public. Anything you file on the tracker is visible to everyone who browses it; anything on the support page is not. When a problem spans both, such as a feature request that depends on a plan, you end up describing it twice.

Two more channels sit alongside these: the community forum at community.postman.com, where you sign in with your Postman account or read without signing in, and the blog and learning site, which cover features, installation and usage rather than individual reports.

Legacy version problems belong to a different repository

The last routing rule in the README is also the most specific. Issues or code contributions that pertain to the legacy version of Postman should go to postmanlabs/postman-chrome-extension-legacy instead. The legacy product is the browser extension, so the split is by product line: current app problems land here, extension problems land there.

This repository does not describe a code contribution path for the current app, because there is nothing here to contribute to. Its documented contribution surface is the issue tracker.

If you are unsure which side of the split you are on, the deciding question is which product you were running. A report about the desktop or web app belongs in this tracker; a report about the old extension belongs in the legacy repository, where the maintainers can act on it.

release-notes/ is the only content directory in the tree

Of the six entries, the others are a README, a contributing guide, a security policy, a .gitignore and the .github directory. That leaves release-notes/ as the single content directory, and it is the reason to watch this repository even though you will never install anything from it.

The catch is what is missing around it. The repository publishes no GitHub releases, so there is no tag to subscribe to and no release page that a feed reader can watch. Anyone tracking versions has to watch a directory of notes on the default branch instead, and the last push to the repository is dated 14 October 2026.

SECURITY.md is present but the README never mentions it, so the reporting route for a vulnerability is whatever that file says rather than anything on this page. For a bug, the documented route is the issue tracker with a version, an OS and reproducible steps.

The only usage numbers sit inside a hiring pitch

One section of the README recruits engineers, and that is where the repository's only figures appear: more than 45 million developers, 500,000 organizations, and 98% of the Fortune 500 using the platform, presented as the reason to apply. Those numbers are the vendor's own claims, made in a careers context, and no methodology or date accompanies them anywhere in the repository.

Set against that, the operational content is thin by design. There is no changelog in release form, no status page, no service level statement and no uptime history here, which means this repository cannot answer whether the app is currently reachable. That question belongs to the support page or the tracker.

The honest summary is that this is a front desk, not an archive. Its value is telling you where to go and what to bring.

Editorial conclusion

Treat this repository as a front desk rather than a codebase. It is the right place to confirm what a good bug report needs before you file one, and to learn that legacy version problems are handled in a separate repository, but it holds nothing you can build against, install or run. Before you file anything here, search the tracker for an existing report as the README asks, gather the Postman version, the OS version and reproducible steps, and send billing or account questions to the support page instead of leaving them in a public thread.

Frequently asked questions

Official sources

1. Issues
2. postmanlabs/postman-app-support on GitHub
3. Project website
4. README