Design & Build
Native Git
One repository for your code, collections, specs and tests. Local by default. Ship them the way you ship code.
Trusted by teams at
Your API work, as files in your repo
Postman Native Git stores your API collections, environments, specs, and tests as files in your own Git repository, next to the code they cover. Branch and review them with Git, run them in CI with the Postman CLI, and push them to a shared Postman workspace when the work is ready.
Collections and specs live with your code
One YAML file per request, per spec, per environment, under /postman in your repo. They diff line by line, like everything else you review.
Keep the Git workflow you have
They are plain files, so you branch, diff, and review them with the Git tooling you already use. Postman doesn't replace it.
Test in CI, publish on merge
Run your collections in the pipeline with the Postman CLI, then publish to Cloud View when the branch merges.
Postman AI reads your code, not just your collection
Your collection is a file in the same repo as your service, so Postman AI can read both. Ask it what your tests miss and the answer comes from the route handlers, not from a spec.
CAPABILITIES
Bring Postman to your codebase, not your codebase to Postman
Your collections, specs, and environments version with your code in the repo you already use, run in the pipeline you already have, and reach your team the moment you decide to push them.
One pull request for the code and the contract
Change a handler and change its collection in the same commit. Reviewers see the API change and the code change side by side, and neither one ships without the other.
Lint, test, and publish in CI
The Postman CLI lints specs against your governance rules, fails the build on violations, runs your functional and performance suites, then publishes on merge.
Cloud View for everyone else
Push when you're ready and the rest of your team gets a read-only view in Postman. No repo access, no local clone.
Any Git provider, any repo
GitHub, GitLab, Bitbucket, cloud or self-hosted, public or private. Postman connects to the repository you already have.
Monorepo ready
Connect the repository root and register every service's collections and environments in one .postman/resources.yaml.
Edit where you work
Change a collection in your IDE, in Postman, or with Agent Mode. It is the same YAML file on disk either way.
On every plan, including Free
Native Git, unlimited workspaces, and private repositories are not paid add-ons. Collaborating through Git costs nothing.
Frequently asked questions about Postman Native Git
What is Postman Native Git?
Postman Native Git stores your API collections, environments, specs, and tests as files in your own Git repository, next to the code they cover. You develop in a local Git repository and sync to Postman Cloud only when the work is ready to share. In Local View, your collections, environments, and specs live alongside your code. In Cloud View, they're the shared version your team can review and rely on.
What do I need to use Native Git?
Native Git works in the Postman desktop app, not the web app. You also need a local project folder with your API code, and a Postman team to create the workspace in (or permission to create a workspace outside a team).
Is Native Git available on the Free plan?
Yes. Native Git is available on every Postman plan, including Free. Compare plans on the Postman pricing page.
Which Git providers does Native Git support?
Native Git works with GitHub, GitLab, and Bitbucket, cloud or self-hosted, with public or private repositories.
Where does Native Git store files in my repository?
Native Git writes one YAML file per request, spec, and environment under the postman directory, and registers them in a .postman/resources.yaml manifest. A collection is a folder of small files, not a single collection file, so a diff shows exactly which request changed, and files you didn't change are left exactly as written. In a monorepo, connect the repository root and register every service's resources in that one manifest.
orders-service/
.postman/
resources.yaml
postman/
collections/
orders api/
list orders.request.yaml
create order.request.yaml
environments/
staging.yaml
src/Does Postman replace my Git client?
No. You branch, diff, review, and commit with Git in your own terminal, IDE, or Git host. Postman doesn't do those steps for you. When the work is ready to share, you sync it to Postman Cloud.
How do I automate Native Git in CI/CD?
Use the Postman CLI. Run postman workspace lint on pull requests, and postman workspace push to sync local files to the cloud workspace after merge. Authenticate the pipeline with a Postman API key stored as a secret; pushes from CI are attributed to the account that owns the key. The Native Git CI/CD guide has the full setup.
Which request types can I keep in Git?
Native Git stores REST, SOAP, GraphQL, gRPC, WebSocket, Socket.IO, MQTT, SSE, MCP, and AI requests as files in your repository, alongside the environments and specs they use.
When does my API work reach Postman Cloud?
Only when you push it. Your collections, specs, and environments live as files in your repository, and they reach Postman Cloud when you push them, from the app or from CI with postman workspace push.
Is there a limit on collection runs?
No. Collection runs in local mode have no limit, on every plan, including Free.
How do I keep secrets out of Git?
Keep local environment values in the Postman app and commit only shared values to Git. Reference secrets from Postman Vault or a connected vault such as 1Password, AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault instead of committing them to your repository.
Can Newman run Native Git collections?
No. Native Git uses the v3 YAML collection format, and Newman only supports the v2.1 JSON format. Run Native Git collections with the Postman CLI, and use postman collection migrate to convert older collections to v3.
RESOURCES
Go deeper on Native Git
See Native Git on your own repository
Chat with a Postman expert about connecting your repository, keeping collections and specs versioned with the code they cover, and running them in the pipeline you already have.