Turn a Postman collection into a shared team mock API

Most teams already have the best description of their API sitting in a Postman collection: every request, the folders, a few saved examples and a handful of variables. It just lives in one person's workspace and only answers when a real backend does. Import it into Mockfly and the same collection becomes a hosted mock your frontend, QA and CI can all call.

Why a collection is a good starting point

Writing mocks from scratch means retyping routes and payloads that someone already captured. A collection gives you the route list and, when people saved examples, realistic response bodies for success and error cases. The import turns that into a normal Mockfly project, so nothing is locked in: every endpoint, response and rule stays editable afterwards.

Step 1: export a v2.1 collection

In Postman, open the collection's … menu, choose Export and keep the recommended v2.1 option. Before exporting, spend two minutes on the collection itself: the more examples are saved under each request, the more useful the mock is on day one.

Here is a tiny collection we will use through the article. It has one folder, one request with two saved examples and a collection variable:

{
  "info": {
    "name": "Orders",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "variable": [{ "key": "currency", "value": "EUR" }],
  "item": [
    {
      "name": "orders",
      "item": [
        {
          "name": "Get order by id",
          "request": {
            "method": "GET",
            "url": { "raw": "{{baseUrl}}/orders/{{orderId}}", "path": ["orders", "{{orderId}}"] }
          },
          "response": [
            {
              "name": "found",
              "code": 200,
              "body": "{ \"id\": \"{{orderId}}\", \"currency\": \"{{currency}}\", \"status\": \"paid\" }"
            },
            { "name": "not found", "code": 404, "body": "{ \"error\": \"order_not_found\" }" }
          ]
        }
      ]
    }
  ]
}

Step 2: import it into Mockfly

On your projects page, click Import project, pick Postman in the Format row and hand the file over with the Paste, File or URL tab. The URL tab makes Mockfly download the collection from its own servers, so it must be public, must not redirect and is capped at 10 MB. For a collection that sits behind auth, use File or Paste.

What the importer builds from the example above:

• A project named Orders (the collection's info.name).
• An orders folder with a GET /orders/:orderId endpoint. The host and {{baseUrl}} are dropped, only the path survives, and {{orderId}} becomes a path param (see dynamic routes).
• Two responses, 200 found (the default, because it is the first 2xx) and 404 not found.
• A project environment variable currency set to EUR.

The saved 200 body also changes slightly: variables that belong to the collection are rewritten to the way Mockfly reads environment variables, so {{currency}} becomes {{env.currency}}. Placeholders that are not collection variables are left alone, which is how Faker placeholders keep returning live data.

{
  "id": "{{orderId}}",
  "currency": "{{env.currency}}",
  "status": "paid"
}

Step 3: read the import summary

When the import finishes you get counters for endpoints, responses, folders and environment variables, plus a list of anything that was not imported, grouped by reason. Nothing is dropped silently, so treat that list as your to-do list. The documented reasons are a request with no URL, an unsupported HTTP method, a response example that is not a JSON object, an invalid status code, and two requests that collapse onto the same method and path once the host and query string are removed.

Some things never travel with the collection because a Mockfly endpoint has no equivalent: authorization, request headers, query params, pre-request scripts, tests, and bodies that are not raw JSON.

Step 4: fill the gaps the collection leaves

A collection records what the API returned once. A good mock also needs the cases nobody saved. Three edits are worth doing right after the import:

• Make responses depend on the request. The 404 above should only appear for unknown ids. Add a rule that matches the request (a path param, query string, header or JSONPath on the body) and returns the not-found response, so the default stays the happy path.
• Echo what the client sent. Use URL, body and environment placeholders so the 200 returns the same orderId the client asked for instead of a frozen value.
• Replace frozen data. Swap copied production-looking values for Faker placeholders so tests do not depend on one specific customer.

Be careful with what the collection contained. Saved examples sometimes hold real customer data or tokens, and an imported project is a copy of them. Scrub sensitive values before you share the project.

Step 5: share one mock with the team

The point of the exercise is that nobody owns a private copy any more. The mock lives in a Mockfly project, not in a file on one laptop, so everyone calls the same URL. On the Team plan you can invite anyone to your projects, including free accounts, so QA, design and product can view and edit the mock without a seat each. See Mockfly for teams and pricing for what each plan includes.

A few habits keep a shared mock healthy:

• Keep the Postman collection and the mock in step: when the API changes, re-export and re-import.
• Put base URLs in config. Frontend, tests and Postman can all point at the mock host by changing a single environment value.
• Name responses after the scenario (404 order not found) so teammates pick the right one in the editor.
• Flip an endpoint to the real backend with proxy mode when it is ready, and keep the mock responses for failures the real API cannot produce on demand.

Plan limits to know before importing

Limits are checked before anything is written. On the free plan a collection that maps to more than 4 endpoints, or a request with more than 2 importable examples, is rejected as a whole and the projects list is untouched. If your collection is bigger, import a trimmed copy or upgrade. For specs rather than collections, see from an OpenAPI spec to a mock API.

Frequently asked questions