If the API you want to mock is already described in a Postman collection, you do not need to recreate it request by request. Hand Mockfly the collection and it builds a whole project out of it: one endpoint per request, folders mirroring the ones in the collection, one response per saved example, and the collection's {{variables}} as environment variables of the project.
The result is a normal Mockfly project. Every endpoint, response and rule stays editable afterwards, and it can be exported again as Mockfly's own JSON format.
You need the collection as a v2.1 export — the one Postman offers from the collection's … menu, under Export. Keep the recommended v2.1 option: the old v1 format stores its requests under entirely different fields, so importing it leaves you with an empty project rather than with an error.
Then go to your projects page and click the Import project button at the top of the list. In the modal that opens, pick Postman in the Format row — "A Postman collection v2.1" — and then choose how you want to hand the file over:
.json file Postman wrote. It is read in your browser and sent as text.Picking Postman also brings up a notice in the modal, because it is the one thing that changes in the bodies that come in: the {{variables}} of the collection become environment variables of the project, and the imported bodies read them as {{env.variable}}. See Collection variables for what that means.
Then hit Import. The button is disabled until there is something to import, turns into "Importing…" while the project is being built, and when it finishes the modal becomes the import summary — with your new project already sitting in the list behind it. If the import fails, nothing is created and the error comes back as a toast explaining why.
This is what the importer does with each part of the export:
| In the collection | In Mockfly |
|---|---|
info.name | The project name. Falls back to Imported project when the collection has no name. |
Each item holding a request | One endpoint. GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD are imported. |
Each item holding more items — a folder | A folder. Nested folders are flattened into one name, so a request two levels down lands in folder / subfolder. Requests sitting at the root of the collection get no folder. |
| The URL of the request | The endpoint path. Only the path survives: the protocol, the host — including a {{baseUrl}} standing in for it — and the query string are dropped. |
A variable in the path, /pet/{{petId}} | A path param, /pet/:petId. Postman's own :petId syntax comes through as it is. See Dynamic Route Support. |
The description of the request, or its name when it has none | The endpoint description, truncated to 500 characters. |
The saved responses of the request — the examples you keep under it in Postman | One response per example, named <status> <example name>. The first 2xx becomes the endpoint's default response. |
A raw JSON request body | The endpoint's body example, so the request editor is prefilled. |
variable | The project's environment variables. See Collection variables. |
A request with no saved examples is still imported: it comes in with a single empty 200 OK response, ready for you to fill in. That is the common case for a collection that was only ever used to hit a real API, and it is why importing one gives you the whole surface of the API as endpoints even when nobody ever saved an example.
Everything else in the collection has no equivalent in a Mockfly endpoint and is left behind: authorization, request headers, query params, pre-request scripts and tests, and bodies that are not raw JSON — form-data, x-www-form-urlencoded, binary.
Given this collection:
{
"info": {
"name": "Petstore",
"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
},
"variable": [
{ "key": "baseUrl", "value": "https://api.petstore.dev" },
{ "key": "petName", "value": "doggie" }
],
"item": [
{
"name": "pet",
"item": [
{
"name": "Get pet by id",
"request": {
"method": "GET",
"description": "Returns a single pet",
"url": { "raw": "{{baseUrl}}/pet/{{petId}}?sold=true", "path": ["pet", "{{petId}}"] }
},
"response": [
{
"name": "successful operation",
"code": 200,
"body": "{ \"id\": 10, \"name\": \"{{petName}}\", \"host\": \"{{baseUrl}}\" }"
},
{ "name": "Pet not found", "code": 404, "body": "{ \"error\": \"not found\" }" }
]
}
]
}
]
}Mockfly creates a project called Petstore with two environment variables, baseUrl and petName, and a pet folder holding a GET /pet/:petId endpoint described as "Returns a single pet". It has two responses — 200 successful operation, the default one, and 404 Pet not found — and this is the body waiting in the first of them:
{
"id": 10,
"name": "{{env.petName}}",
"host": "{{env.baseUrl}}"
}Note what happened along the way: {{baseUrl}} and ?sold=true disappeared from the URL, {{petId}} became a path param, and the two variables used inside the saved body now point at the project's environment.
The variable array of the collection becomes the project's environment. Each variable keeps its name and its value; a variable declared without a value comes in as an empty string, ready for you to fill in from the Project environment variables button of the project's left-hand menu. Only the collection's own variables travel with the export — a Postman environment or your globals are separate files, so nothing from them is imported.
On top of that, every {{name}} found inside an imported body — a saved response or the request body example, at any depth, inside objects and arrays alike — is rewritten to {{env.name}}, which is how Mockfly reads an environment variable at request time. See Project Environment Variables for what you can do with them afterwards.
The rewrite only happens when name is one of the collection's variables. Anything else is left exactly as it was, and that is deliberate: {{string.uuid}}, {{internet.email}} and the rest of the Faker placeholders are resolved by the mock engine on every call, so a collection that already used them keeps returning live data once imported.
When the import finishes, the modal turns into a summary of what just happened. At the top is the name of the new project, taken from the collection, and under it four counters:
folder / subfolder entry;If anything was left out, a "N requests were not imported" section appears below the counters. It groups everything by reason, with a count next to each one; click a reason to unfold it and see every request behind it — its method, its path, and the status code when the skip was about one specific saved response rather than the whole request.
Nothing is ever dropped silently, so a request can show up in that list and still be in your project: when only some of its saved examples were skipped, the endpoint comes in with the ones that survived — or with the empty 200 OK response, if none did.
The summary is informative only; the project is already created and waiting in the list behind the modal. Close it with Done and open the project to start editing what came in.
| Reason | When it happens |
|---|---|
| The request has no URL. | The request carries no URL at all, or a url object with neither path segments nor a raw string in it. |
| The HTTP method is not supported by Mockfly. | In practice a TRACE request, or one saved without a method at all. |
| The response example is not a JSON object. | The saved body is not JSON — an HTML error page, plain text, XML — or it is a bare number or string. |
| The status code is not a valid HTTP status code. | The code of the saved example is not a status code Mockfly knows. |
| Another operation is already mapped to the same path and method. | Two requests collapse onto the same method and path once the host and the query string are dropped — the same endpoint saved twice with different query params, for instance. The first one wins. |
A saved example is imported when its body parses as JSON. Anything else — an HTML error page, an XML payload, a plain text body — is skipped and listed in the summary. An example saved with an empty body is fine: it comes in with an empty body, keeping its status code.
The same goes the other way around, for the request body: only a raw JSON body becomes the endpoint's body example. A form-data or x-www-form-urlencoded body is not turned into one.
Plan limits are checked before anything is written, so an import that exceeds them fails and leaves nothing behind — no half-created project you have to clean up. On the free plan that means a collection mapping to more than 4 endpoints, or a request with more than 2 importable examples, is rejected outright: the modal shows the limit as an error and the projects list is untouched. Upgrading lifts both limits.
The URL tab does not fetch the collection from your browser — Mockfly downloads it from its own servers, so the file has to be publicly reachable. The fetch is deliberately conservative:
http and https only,If any of those trip, the import fails with an error saying so and no project is created. Collection behind auth, or living in your Postman workspace only? Export it and use the File or Paste tab instead.
Import your collection→