Rethinking API Workspaces for microservice architecture

In modern development, services rarely live in one giant codebase. Instead, applications are split into multiple microservices — each with its own repo, APIs, and logic.

Testing these APIs is just as important as writing the code, but here’s the problem:

• Every service usually has its own API requests and environments.
• Teams often manage these in separate workspaces.
• Developers who need to test flows across multiple services end up juggling between workspaces.

This slows down debugging and makes collaboration harder.

Requestly’s Multi-Workspace View solves this by letting you keep API collections and environments inside each service’s source code and then combine them as needed.

Keeping API Collections Close to the Code

Instead of having a single central workspace for everything, each team can store its own Requestly workspace (collections + environments) alongside the service it belongs to.

For example:

📁 service-a
 ├─ 📁 src
 ├─ 📁 tests
 └─ 📁 requestly-workspace   # Contains API collections + environments

📁 service-b
 ├─ 📁 src
 └─ 📁 requestly-workspace

📁 service-c
 ├─ 📁 src
 └─ 📁 requestly-workspace

This approach has some big advantages:

• Version-controlled: Workspaces live in Git, just like your code.
• Scoped: Each service has only the API requests relevant to it.
• Discoverable: Any new developer can clone the repo and instantly access the APIs for that service.

Mixing Services When You Need Them

Here’s where Multi-Workspace View comes in.

Say you’re working on a checkout flow that touches:

• Service A (Auth)
• Service D (Orders)

Instead of merging their API requests into one messy workspace, you can simply:

1. Clone both repos (service A and D).
2. Open Requestly.
3. Load the two local workspaces in Multi-Workspace View.

Now you have both sets of requests + environments available side by side. You can:

• Call Auth APIs from service A.
• Call Order APIs from service D.
• Debug the full flow — without ever switching workspaces or duplicating requests.

This scales beautifully when teams maintain multiple repos but need to collaborate on larger workflows.

Benefits of This Approach

• Close to source: Workspaces live where APIs are implemented.
• Reproducible setups: New team members don’t need to hunt for API docs — they get the collections with the code.
• Mix & match flexibility: Developers can load exactly the services they need (A + D, B + C, etc.) without clutter.
• Cross-team collaboration: Workspaces can be versioned, reviewed, and shared just like code changes.

Getting Started with Multi-Workspace View

Step 1: Open Requestly and navigate to the API tab from the sidebar.

Step 2: In the top-right corner, click on your current workspace name to open the Workspace Selector dropdown.

Step 3: Check the boxes next to the local workspaces you want to load together.

Step 4: Your chosen workspaces will appear grouped in the selector.

Note: Multi-Workspace View currently works with local workspaces only.

Final Thoughts

Microservices encourage modularity in code — and your API testing setup should reflect that too. By keeping Requestly workspaces next to the service code and using Multi-Workspace View, you get the best of both worlds:

• Organized, version-controlled API collections per service.
• The flexibility to test across multiple services in one view.

This approach makes API testing more maintainable, collaborative, and aligned with how modern teams ship software.