Mock servers in PolyApiIDE: faking a response without a real backend
Contents
I build PolyApiIDE, and one question comes up often: can you substitute your own response instead of hitting the real backend? You can — it is a paid-plan feature (Month, Year, Lifetime plans), called mock servers. Here is how it actually works, without overselling what gets substituted.
What it is
A mock server in PolyApiIDE is a rule: an HTTP method (GET, POST, and so on) plus a URL pattern. When a real request from the tab matches that rule, the extension intercepts it through the browser's own request-blocking/redirect engine and returns the response body and content-type you configured in the rule — instead of letting the request reach the real backend.
One important point: this is entirely local. The interception happens inside the browser, and no mock traffic goes to any server of ours — the rule simply swaps in a prepared response in place of the real request on your machine.
Scope priority: Collection > Workspace > Global
A rule can be set at one of three levels, and when several rules match the same request, the most specific one wins:
| Level | Applies to | Priority |
|---|---|---|
| Collection | only requests inside one specific collection | highest — overrides everything else |
| Workspace | all requests inside that workspace | middle |
| Global | all requests across every workspace in the IDE | lowest — acts as a default fallback |
Example: you set a global catch-all rule, GET /api/*, returning an empty list, so the tab does not fall over when the backend is unreachable at all. But inside the one collection where you are currently building a user-profile feature, you add a narrower rule, GET /api/users/*, with a realistic test fixture. Requests from that collection hit the collection-level rule; everything else falls back to the global catch-all.
What is actually mocked today, and what is not
Worth being direct here: today the platform substitutes only the response body and content-type. The status code, response headers, and an artificial delay before the response are not technically supported yet. If you need to mock an actual 500 with the right status code, or test how a client behaves against a slow response, you cannot do that right now. We work with what is actually shipped, and I won't pretend this is a full contract-testing platform on the level of WireMock or Prism. It is a lightweight substitution of body and content-type that covers the common case, not a complete mock-server platform.
Where this is genuinely useful
- The backend for an endpoint is not built yet (or you, as a frontend developer, are ahead of the backend team) — you build against an agreed contract without waiting for a release.
- You need to give a demo without a live backend — on a plane, or on a network without access to staging.
- You want to work fully offline, without depending on an external service's availability.
- You are testing scripts (
pm/poly) or QA checks against a fixed, deterministic response, independent of how flaky the real backend happens to be right now.
How you set one up, conceptually
Conceptually it is three steps: pick a scope (collection, workspace, or global), add a rule — method plus a URL pattern — and set the response body and content-type that should come back. Once the rule is on, an ordinary request from the tab that matches the pattern gets the substituted response immediately, without reaching the real address. The rest of the workflow — scripts, QA checks, scenarios — treats that response exactly like a real one.
If you have not set up PolyApiIDE yet, start with the quick start. For questions about licenses, plans, and the limits of paid features, see the FAQ.
The author builds PolyApiIDE. That is stated in the articles, not hidden in a footer.