How does Yaak use Git to version and share API requests?

Yaak stores each request, folder, and environment as a separate YAML file, so your API collection becomes a normal Git repository. You commit, branch, and diff those files from a built-in Git UI, and anyone with access to the repo can pull the same requests. Secrets are only shared if you turn on encryption, and access control comes from your existing Git provider rather than a separate permission system.

This fits teams that already use Git and want API requests to live alongside code. It is not a hosted collaboration platform: there is no cloud dashboard or automatic sync, and sharing depends on where you push the repo.

One YAML file per request, folder, and environment

The unit of versioning is the file, not a database row. According to the Yaak site, the app keeps "one YAML file per request, folder, and environment." That structure is what makes Git work naturally:

• A change to a single request shows up as a change to a single file, so diffs stay readable.
• Folders and environments are also files, so reorganizing a collection is itself a reviewable change.
• Because the format is plain YAML, you can inspect or edit it outside the app.

The practical consequence: merging two people's work is ordinary Git merging. If two people edit the same request, you resolve a text conflict the same way you would in code.

Branch, commit, and diff from the built-in Git UI

You do not need a separate terminal or third-party Git client to version requests. Yaak's built-in Git UI supports branching, committing, and diffing. The workflow looks like this:

1. Make or edit requests in the app. The changes are written to the YAML files in your working directory.
2. Open the Git UI, review the diff, and commit the changes you want to keep.
3. Create a branch if you want to try a variant without touching the main collection.
4. Push to your Git remote so teammates can pull the same requests.

The expected result is that your request collection has the same history, review, and rollback properties as the rest of your repository. A useful side effect: because changes are committed, you can see when a request changed and what it looked like before.

Sharing secrets safely with optional encryption

Sharing a request often means sharing the values it needs, including tokens and keys. Yaak's approach is to keep secrets out of plaintext by default and let you opt into encryption:

• Secrets can be encrypted with keys held in the OS keychain, so the raw values are not sitting in the YAML.
• Encryption is optional. If you enable it, you can share secrets through the repo; if you do not, treat committed files as potentially readable by anyone with repo access.
• The desktop app stores work locally and sends API requests directly to your servers, and the site states there is no account requirement and no automatic cloud sync.

A concrete scenario: a team keeps a staging environment in the repo. Without encryption, the staging token in that environment file is visible to everyone who can read the repo. With encryption enabled, the token is protected by a keychain-held key, and only people who can unlock it can use the value.

Access control comes from your Git provider

Yaak does not introduce its own permission model for shared requests. Instead, the site says you "manage access through your Git provider's existing permissions." In practice:

• If someone can read the repository, they can read the requests in it.
• If someone cannot push to the repository, they cannot change the shared collection.
• Revoking access means changing their access in the Git provider, not in Yaak.

This is the main trade-off of the local-first model. You get no proprietary cloud, no separate account system, and no dashboard to administer, but you also get no Yaak-specific sharing controls. Your Git provider's rules are the rules.

What this means for your team

Choose Yaak's Git workflow if your team already reviews code in Git and wants API requests to go through the same review and history. It works well when:

• You want requests to live next to the code they exercise.
• You want diffs and branches for API changes, not just for source files.
• You are comfortable with access being defined by your Git provider.

Look elsewhere if you need a hosted, always-synced collection with its own user management and no Git involvement. Yaak's model is deliberately the opposite: files on your machine, versioned with Git, shared through the remote you already use.

For teams that need centralized license management, the site also mentions per-seat licenses, SSO via OpenID Connect, SCIM provisioning, and a central dashboard, with pricing on a separate page. Those are team administration features layered on top of the local-first, Git-based core described above.