TL;DR
Thunder Client was built for individual developers, not teams. The free tier has no sharing at all. Pro adds git-based sync, which lets teams share collections through a repository, but it is not real-time collaboration and it requires git discipline to avoid merge conflicts. For teams needing more than file-sharing via git, Apidog’s free tier offers three-user workspaces with cloud sync.
Introduction
Thunder Client’s popularity comes from its simplicity: lightweight, lives in VS Code, no external app required. Those qualities make it excellent for solo developers. They also reveal its limits when you put it in front of a team.
This article looks honestly at what Thunder Client can and cannot do in a team context, what workarounds exist, and at what point it makes sense to switch to a tool built for collaboration.
What Thunder Client free offers teams
The short answer: nothing team-specific.
Thunder Client free stores collections in VS Code’s extension storage, tied to your local installation. There is no way to share collections with a teammate on the free tier. Each developer has an isolated set of requests.
For a two-person team, this means:
- Developer A creates a collection of 20 API endpoints
- Developer B has no way to access it without Developer A manually exporting and sending the JSON
- If Developer A updates an endpoint, Developer B’s copy is stale immediately
- There is no indication that anything has changed
In practice, teams on the Thunder Client free tier often end up with each developer maintaining their own copy of collections. This leads to drift – different developers testing different versions of the API contract – which is exactly the problem a shared tool should solve.
What Thunder Client Pro adds for teams
Thunder Client Pro introduces git sync: collections are stored as JSON files in your project directory (in a .thunder-tests folder). This means:
- Collections can be committed to git
- Teammates who pull the repository get the collections
- Changes to collections appear in git diffs
- Pull requests can include API collection updates alongside code changes
This is a meaningful improvement over the free tier. For teams already using git for everything, having API collections in the same repository is a natural fit.
How it works in practice:
- Developer A has Thunder Client Pro, enables git sync
- Collections appear as JSON in
.thunder-tests/ - Developer A commits and pushes the directory
- Developer B (also on Pro) pulls the repository and sees the collections in Thunder Client
- If Developer B updates a collection and pushes, Developer A pulls and sees the update
This works. It follows a pattern developers already understand.
Where it breaks down:
No real-time sync. Changes require a commit-push-pull cycle. If Developer A is adding endpoints during an active development sprint, Developer B has to manually pull to get the latest collections. There is no notification, no automatic update.
Merge conflicts. Collection JSON files can conflict like any other file. If two developers modify the same collection on separate branches, merging can produce conflicts in JSON that are hard to resolve. You are manually editing collection JSON in a text editor to fix a merge – not a pleasant experience.
Everyone needs Pro. Git sync requires every team member to be on a paid plan. At $10-15/month per user, a five-person team is $50-75/month just to share API collections.
No shared environments. Environments (API keys, base URLs) are not synced through git sync. Each developer manages their own environment variables. If the team uses shared dev/staging endpoints, each person configures them manually.
Workarounds for teams on the free tier
If your team is on Thunder Client free and you need to share collections, here are the workarounds:
Manual export/import: Thunder Client allows exporting collections as JSON and importing them on another machine. Teams sometimes maintain a shared folder (Slack, Notion, a shared drive) with exported JSON files. This is tedious and error-prone – stale files are a constant problem.
Switch to REST Client: REST Client uses .http files that live in your project directory. No special sync required – they are just files in git. Every developer who clones the repository has the requests. This is not a Thunder Client workaround; it is a replacement. But for teams that need free, git-based sharing, it works reliably.
Use both: Some teams keep Thunder Client for personal, exploratory testing and use REST Client .http files for the canonical, shared collection that lives in git. This doubles the maintenance burden but keeps each tool in its strength zone.
What teams actually need
API collaboration for a development team typically requires:
- Shared collections that all developers see the same version of
- Shared environments so the base URL and credentials are consistent
- Change tracking so you know when a request was updated and by whom
- Conflict-free updates – someone should not have to resolve a JSON merge conflict to add an endpoint
- Accessible from wherever developers work – editor, desktop app, browser
Thunder Client Pro addresses points 1 and 3 through git. Points 2, 4, and 5 are not fully addressed.
Where Apidog fills the gap
Apidog’s free tier was built around the collaboration model that Thunder Client lacks. Key differences:
Shared cloud workspace: Every team member on the free tier (up to three users) sees the same collections in real time. No commits, no pulls, no exports.
Shared environments: You define a dev environment once. Every teammate uses the same one. When the staging URL changes, one person updates it and everyone sees the change immediately.
No merge conflicts: Collections are not stored as git files. They live in Apidog’s cloud. Concurrent edits are handled by the platform, not by git.
API documentation: Apidog generates API documentation from your collections. Teammates and stakeholders who do not do API testing can read documentation from the same source.
VS Code extension: Developers who prefer to stay in VS Code install the Apidog extension and access the shared workspace inside the editor. This is comparable to Thunder Client’s VS Code experience, but connected to the shared team workspace.
The free tier’s three-user limit covers most small feature teams. Above three users, Apidog’s paid plans start lower than the equivalent Thunder Client Pro per-seat cost for a full team.
Teams switching away from Thunder Client often discover that lightweight alternatives carry the same structural ceiling — Bruno's cloud-sync limitations for teams follow a comparable pattern, with their own set of workarounds worth knowing before committing.
FAQ
Can Thunder Client teams use git without Pro?No. Git sync is a Pro-only feature. Free-tier collections are stored in VS Code’s extension data and are not accessible as files you can commit.
How many users does Apidog’s free tier support?Apidog’s free tier supports up to three users in a shared workspace. For teams larger than three, paid plans are available.
Does Thunder Client Pro support real-time collaboration?No. Thunder Client Pro’s collaboration model is git-based. Changes require a commit-push-pull cycle. There is no live cursor, no real-time notification, and no automatic sync.
What happens to shared environments in Thunder Client Pro?Environment variables are not synced through git sync by default in Thunder Client. Each developer manages their own local environments. This is a friction point for teams with shared staging or dev credentials.
Can a team use Thunder Client free with a shared .thunder-tests folder in git?This is not supported by the free tier. The free tier stores collections in VS Code extension storage, not as files in your project. Only Pro users get the file-based storage that would allow this.
Is Apidog’s VS Code extension suitable for developers who do not use the desktop app?Yes. The VS Code extension is a full client for Apidog’s workspace. You can create, edit, run, and organize requests entirely within VS Code. The desktop app is optional.
Thunder Client Pro is a workable team solution for small groups comfortable with git workflows. For teams that find git-based API collection management awkward or need more than three users without a per-seat fee, Apidog’s collaboration model is better suited to the actual workflow.
