Postman Free Tier Mock Server and Monitor Limits for Low‑Traffic Workflows

Direct Answer

To keep mock‑server calls under 1,000 per month while still testing latency, limit Postman mock usage to infrequent demos and use a local mock (e.g., WireMock, Mockoon, or Prism) with a latency injector such as Toxiproxy for day‑to‑day development. For teams with more than three members, export the collection to a Git repository and let each developer import it into their personal free Postman account; share via a public workspace or the Run in Postman button. Finally, free‑tier mocks provide no formal SLA; treat them as best‑effort tooling and run production‑adjacent tests against a staging deployment instead of the free mock.

Confirmed Facts (verify on Postman’s pricing page)

• Mock server calls: capped at 1,000 per month, no rollover.
• Monitor executions: capped at 1,000 per month, run only in US East (N. Virginia).
• Workspace seats: limited to three users on the free plan.
• Free mocks cannot simulate latency or error rates.
• No published SLA for free‑tier mock servers.

Likely Explanation

• Because each request to a Postman mock consumes one quota unit, keeping usage below 1,000 means limiting calls to essential integration checks.
• Local mock servers paired with a latency proxy allow realistic delay injection without touching the Postman quota.
• Git‑based collection versioning turns the repository into the single source of truth; each free account can import the same collection, effectively bypassing the three‑user seat limit.
• Without an SLA, free mocks are suitable only for development and non‑production testing; production‑adjacent tests should target a staging environment.

Practical Steps for This Case

1. Use Postman mocks only for stakeholder demos or cross‑team integration checkpoints (max 100 calls per month). Track usage in the team usage dashboard.
2. Set up a local mock (e.g., WireMock) and a latency injector (e.g., Toxiproxy). Run client tests against this chain; no Postman quota is consumed.
3. Export the canonical collection to Git. Each developer pulls the latest JSON and imports it into their personal Postman account. Share via a public workspace or a Run in Postman button.
4. Schedule monitors sparingly: either once a week or trim the collection to a single critical request. If the monitor quota counts per request, keep the run to ≤10 requests per month.
5. For production‑adjacent testing, point the collection at a staging deployment rather than the free mock.

Missing Diagnostic Detail

Does your monitor quota count per run or per executed request? Knowing this will determine whether a weekly monitor of a 5‑request collection stays within the 1,000‑per‑month limit.