API Collections in Git: Version Requests, Docs & Tasks (2026)

Your code lives in Git. Your API collections, the docs that explain the API and the tasks that describe what to build next usually do not: they sit in a vendor’s cloud, in a wiki and in a ticket tracker, each with its own history, or none at all. When a request breaks, nobody can say who changed the auth header, or what the request looked like last Tuesday.

Putting API collections in Git fixes that. Every change becomes a commit you can read, review and roll back, and the collection travels with the code it tests. This guide covers why it matters, what a good layout in the repository looks like, how the popular API clients handle Git in 2026, and how Apiboo puts your requests, documents, boards and projects in the same repository. We make Apiboo; competitor facts were checked on their own sites in September 2026.

Why API collections belong in Git

History: who changed which request, when, and why, without asking in chat.
Review: a change to an endpoint’s request shows up next to the code change that needed it.
Rollback: bring back the version of one request that worked, not the whole workspace.
Ownership: the files are in a repository you control, on GitHub, GitLab or your own server, and outlive any vendor.
AI agents: a coding agent that reads your repo can read the collection and the docs too, as plain text.

What a good Git layout looks like

Not every “Git sync” is equal. A collection exported as one large JSON file is technically in Git, but every edit rewrites the file and the diff is unreadable. What you want:

One file per request, so a change touches one file and a review shows exactly that request.
A text format a person can read, such as YAML, and Markdown for prose.
Secrets kept out of the repository, with a check that stops a token before it is committed.
Stable ids in the files, so renaming a request is a rename in the history, not a delete plus an add.
Your other files left alone: the README and the code next to the collection are never rewritten.

How the popular API clients handle Git (September 2026)

Each of them has an answer now; they differ in what goes into the repository and what it costs.

Postman — Native Git since v12 keeps collections as files in your repository, tied to team workspaces; Newman does not read the v3 collection format it uses, so CI moves to the Postman CLI.
Bruno — the collection is a folder of plain-text files (YAML by default since v3.1, .bru supported); you commit with your own Git tools for free, and the in-app Git UI (clone, diff, branches, conflicts) is part of the paid Ultimate tier.
Insomnia — Git Sync per project, next to Local Vault and Cloud Sync; the free Essentials plan includes Git Sync for up to 3 users.
Yaak — workspaces live in the app and can be mirrored to a folder that you commit yourself.
Thunder Client — Git sync is on the paid plans.
Apiboo — a Git page in the desktop app: requests as YAML, one file each, plus documents as Markdown and boards, tasks and projects; free, and it works without an Apiboo account for anything but GitHub.

Not just requests: docs, tasks and projects in the same repo

Most API clients stop at the collection. Apiboo also syncs the work around it, because a request without its context is half the story. Connect My projects, boards & documents to a repository and it writes:

documents/ — every page as a Markdown file, subpages in a folder named after their page, images under documents/media/.
boards/<name>/ — a board.yaml with the lists and labels, and one Markdown file per task in tasks/, with its comments.
projects/ — one YAML file per project, plus how they link together.

What Apiboo writes for a workspace

A workspace becomes a handful of readable files: apiboo.yaml with its id and name, collections/<name>/collection.yaml for folders, settings, scripts and auth, collections/<name>/requests/<name>.yaml for each request, environments/<name>.yaml, and variables/globals.yaml and variables/workspace.yaml. Apiboo keeps its own block in .gitignore and .gitattributes and leaves your lines alone.

Secret variables never reach the repository. A variable marked secret is written without its value; the value stays in a *.local.yaml file next to it, which Git ignores. The vault, your keychain, chat and the mail catcher are never in a repository.

The everyday loop

Apiboo never commits or pushes on its own. You edit requests as usual, and the Git page shows what changed since the last sync, grouped into requests, folders, collections, environments and variables, each marked added, changed, deleted or renamed. Click one and you see every changed field, old value above new. Discard this change puts one item back.

Sync now commits and pushes; Pull brings in your teammates’ changes. If you are offline, the commit is made and sent when the connection is back. When two people changed the same file, you choose yours or theirs per file and push. History lists every sync, and a single request has its own History button: restore last Tuesday’s version of one request and the next sync records it as a new change.

Before every commit, a secret check looks for API keys, GitHub, Slack, AWS and Google keys, JWTs, private keys and passwords in URLs. If it finds one, nothing is committed and it tells you the file and line, never the value.

GitHub, GitLab, or no server at all

GitHub links through your Apiboo account; GitLab.com and self-managed GitLab sign in with a personal access token kept in your system keychain; Gitea, Forgejo, Codeberg, Bitbucket and company servers work over HTTPS or SSH with a sign-in taken from your vault. Connect & push creates the repository on GitHub and GitLab if it does not exist yet.

You do not even need a server. This device only keeps every saved version on your computer, with the same changes, history and restore, and Add a remote sends the whole history to a server later, in the same order. For a team, owners connect the team’s repository once, and every member joins with their own account; nobody’s sign-in is shared.

Your AI agent reads the same files

When the collection, the docs and the tasks are plain files in the repository, a coding agent such as Claude Code or Codex can read them like code: the request it should call, the document that explains the endpoint, the task it is working on. Apiboo also has a built-in MCP server for agents that work inside the app, with permissions you switch on per area. Either way, the agent and you look at the same source of truth.

Honest limits

Git is in the desktop app only.
Conflicts are resolved per file (yours or theirs), not line by line inside Apiboo; for a line-level merge, use your own Git tools on the repository.
A team’s history has to live on a server; This device only is for your own workspaces, projects, boards and documents.
Plain http:// addresses work only for servers on your own computer, and files over 48 MB are not read.
Renaming a linked workspace renames it in Apiboo only; the repository keeps its name.

Try it with your own work

Import your collection (Postman, Insomnia, Bruno, Hoppscotch, OpenAPI or HAR), open the Git page, and click Connect to a repository, or pick This device only to start without a server.

Download Apiboo for Windows, macOS or Linux at apiboo.com/download. It is free to start, with no card and no account: every tool runs on your own machine, and you only sign in when you want sync or a team.

API collections in Git: version your requests, docs and tasks in your own repo