Import & Migration

Import is the mechanism through which external data and schemas enter a Mockomat project. Whether you are populating collections with real-world datasets or generating an entire model from an existing API specification, import is the bridge between your external sources and the Mockomat modelling environment.

Mockomat provides two distinct import paths:

• Data Import — load raw datasets (CSV, JSON) into tenant-isolated MongoDB collections, making them available as OFF_FIELD mapping sources for your attributes.
• OpenAPI Import — upload an OpenAPI 3.x specification to generate entities, attributes, and relations automatically, populating your modelling board with a ready-to-refine schema.

Both paths converge on the same outcome: structured, queryable data that powers your mock API through the Runtime pipeline.

im-01-import-overviewMissing

Import section overview showing the two available import paths.

Data Import Pipeline

The data import pipeline moves raw datasets from external sources into queryable MongoDB collections. The pipeline follows a defined sequence of stages, each building on the output of the previous one.

Stage 1: Raw Dumps

Data files originate from one of two sources:

• Public datasets — curated datasets processed through the Mockomat data acquisition pipeline (e.g., Open Food Facts, GeoNames, economic indicators). These arrive pre-normalized with metadata sidecars.
• Custom uploads — user-provided CSV or JSON files uploaded directly through the workspace.

Raw dumps are stored in a staging area and scanned for structural metadata before they become available for import.

im-02-raw-dumps-listMissing

Raw dumps listing showing available datasets with file type, record count, and import status.

Stage 2: Metadata Extraction

Once a raw dump is registered, Mockomat automatically extracts structural metadata:

Metadata Property	Description
Field names	Column headers or JSON property keys discovered in the file
Inferred types	Data type per field (string, number, boolean, date) based on value sampling
Sample values	A representative subset of values for each field, used for preview
Record count	Total number of rows or documents in the file
Tags	Categorical labels derived from the dataset source and content domain

This metadata powers the import wizard and later appears in the Data Sources & Mapping panel when you configure OFF_FIELD mappings.

Stage 3: Import Wizard

The import wizard provides a guided configuration flow before data enters MongoDB:

1. Select fields — choose which fields from the raw dump to include in the import. Not every column needs to be imported; select only those relevant to your model.
2. Map columns to attributes — optionally pre-map imported fields to existing entity attributes, or defer mapping to a later stage.
3. Review sample data — inspect a preview of the data that will be imported, verifying that types and values align with expectations.
4. Confirm and start — initiate the import job.

im-03-import-wizardMissing

Import wizard showing field selection, type preview, and sample data inspection.

Import on the free plan

Free User

Free plan users can import from the curated public dataset library. Custom file uploads are available on the Enterprise plan. See the availability table at the end of this page for full details.

Stage 4: MongoDB Storage

Upon confirmation, the import job loads the selected fields into a tenant-isolated MongoDB collection. Each project's data resides in its own namespace, ensuring strict isolation between tenants and projects.

The import process:

• Creates or updates the target MongoDB collection.
• Inserts records in batches for performance and resilience.
• Records import metadata (timestamp, record count, source file) for auditability.

Stage 5: Ready for Mapping

After a successful import, the imported fields become available as data objects in the Data Sources & Mapping panel. You can now:

• Browse imported fields in the data object selector.
• Map them to entity attributes using the OFF_FIELD mapping type.
• Preview the resulting data in the Workspace preview panel.

The imported data flows through the Runtime pipeline exactly as any other data source — consumers querying your mock API receive values drawn from the imported collection.

im-04-post-import-mappingMissing

Data object selector showing newly imported fields available for OFF_FIELD mapping.

Progress Tracking

Import jobs use Server-Sent Events (SSE) to stream real-time progress updates to the workspace UI. This provides immediate feedback throughout the import process without requiring polling.

What the Progress UI Shows

Indicator	Description
Progress bar	Visual percentage of records processed relative to the total
Records processed	Absolute count of records loaded so far
Estimated time remaining	Projected completion time based on current throughput
Status label	Current state: queued, processing, completed, failed, cancelled

Cancellation and Retry

• An import can be cancelled while it is in the processing state. Cancellation stops further record insertion; records already written remain in the collection.
• A failed import displays detailed error information (e.g., malformed rows, type mismatches, connection errors). Failed imports can be retried from the import history panel.

im-05-progress-trackingMissing

Import progress view with SSE-driven progress bar, record count, and estimated time.

Post-Import Validation

After an import completes, perform the following checks to confirm data integrity before proceeding to modelling:

Verification Checklist

1. Record count — compare the imported record count against the expected total from the source file. A mismatch may indicate skipped rows due to parsing errors.
2. Sample data inspection — open the data preview for the imported collection and verify that values appear correctly formatted and within expected ranges.
3. Field mapping — navigate to the Data Sources & Mapping panel and map imported fields to the appropriate entity attributes.
4. Preview query — run a preview query in the Workspace to confirm that mapped data appears in the GraphQL response.
5. Hint resolution — check the Preview & Hints panel for any unmapped-attribute hints that may need attention.

Validation tip for paid users

Paid User

On paid plans, the import summary includes a detailed field-level quality report showing null rates, type distribution, and value uniqueness per column. Use this report to identify fields that may need cleaning or alternative mapping strategies.

OpenAPI Import

OpenAPI import generates a Mockomat model from an existing API specification. This path is designed for teams that already have an API contract and want to create a mock implementation without manually defining every entity and attribute.

Supported Specifications

Mockomat accepts OpenAPI 3.x specifications in both JSON and YAML formats. Swagger 2.0 files are not directly supported — convert them to OpenAPI 3.x using a tool such as swagger2openapi before uploading.

Import Workflow

The OpenAPI import follows a five-stage process:

1. Upload Specification

Provide your OpenAPI specification file through the upload dialog. The file is validated for structural correctness before parsing begins.

im-06-openapi-uploadMissing

OpenAPI specification upload dialog with file format validation.

2. Schema Analysis

Mockomat parses the specification and extracts:

• Schema definitions — component schemas that describe data structures.
• Properties — individual fields within each schema, including types and constraints.
• References — $ref pointers that indicate relationships between schemas.
• Endpoints — path definitions with HTTP methods, request bodies, and response schemas.

3. Model Generation

The extracted information is mapped to Mockomat modelling primitives:

OpenAPI Element	Mockomat Equivalent
Component schema	Entity (table)
Schema property	Attribute (with type mapped)
$ref reference	Relation (where cardinality is inferable)
Path + method	Query name suggestion
Property constraints (required, enum)	Attribute flags

4. Board Population

Generated entities appear on the Modelling Board as table cards with attributes pre-configured. Relations inferred from $ref pointers are drawn as connection lines between the relevant entities.

im-07-openapi-board-resultMissing

Modelling board populated with entities generated from an OpenAPI specification.

5. Refinement

The generated model is a starting point, not a finished configuration. After import, review and adjust:

• Entity and attribute names — rename where the OpenAPI schema names do not match your preferred conventions.
• Relation cardinality — verify that inferred relations have the correct direction and cardinality. Some $ref patterns are ambiguous and may require manual correction.
• Data source mappings — generated attributes have no data source configured. Assign OFF_FIELD, FAKE, or CONST mappings as described in Data Sources & Mapping.
• Attribute flags — enable sortable, filterable, and searchable flags based on your API design requirements. See Tables & Attributes for flag configuration.
• View configuration — define how entities are presented to consumers through the Views system.

What Gets Imported

Source Element	Generated Output
Schema definitions	Entities with names and descriptions
Properties	Attributes with inferred types
$ref references	Relations (where direction and cardinality can be determined)
Endpoint paths	Query name suggestions for API design
required arrays	Required attribute flags
enum constraints	Attribute metadata annotations

What Needs Manual Configuration

The following aspects cannot be reliably inferred from an OpenAPI specification and require manual setup after import:

• Data source mappings — OFF_FIELD, FAKE, or CONST assignments for each attribute.
• Precise relation cardinality — especially for m:n relationships that are not explicitly represented in OpenAPI.
• Attribute flags — sortable, filterable, and searchable designations.
• View configuration — column visibility, pagination defaults, and detail relation setup.
• Relation linking columns — the specific fields used to join related entities.

OpenAPI import for integration teams

Developer / Integrator

If you maintain an existing API contract in Postman, Stoplight, or Swagger UI, export it as an OpenAPI 3.x specification and import into Mockomat. This gives your frontend team a working mock API in minutes, aligned with the contract your backend team is implementing. Changes to the contract can be re-imported to keep the mock in sync.

Migration from Other Tools

OpenAPI import serves as the primary migration path from other mock server tools or API design platforms. The workflow is straightforward:

1. Export your specification — most tools (Postman, Stoplight, Swagger, Apigee, Insomnia) support exporting to OpenAPI 3.x format.
2. Import into Mockomat — upload the exported specification through the OpenAPI import flow described above.
3. Refine the generated model — adjust naming, relations, mappings, and flags to match your requirements.
4. Configure data sources — assign realistic data to your attributes using the mapping system.
5. Validate in runtime — run preview queries to confirm the mock API behaves as expected.

There is no direct import path from proprietary mock server formats (e.g., WireMock mappings, MockServer expectations, Prism configurations). The OpenAPI specification serves as the universal interchange format.

im-08-migration-flowMissing

Migration workflow from external tools through OpenAPI specification to Mockomat model.

Import Availability per Plan

Not all import features are available on every plan. The following table summarizes access:

Feature	Guest	Free	Professional	Business	Enterprise
OpenAPI Import	Yes	Yes	Yes	Yes	Yes
Public Dataset Mapping	Yes	Yes	Yes	Yes	Yes
Custom Dataset Upload	—	—	—	—	Yes
Import History & Retry	—	Yes	Yes	Yes	Yes
Field-Level Quality Report	—	—	Yes	Yes	Yes
Bulk Import (multiple files)	—	—	—	Yes	Yes

Enterprise import capabilities

Enterprise User

Enterprise plans include custom dataset upload, bulk import of multiple files in a single operation, and extended import history with full audit trails. Contact your account representative for volume limits and storage quotas.

Summary

Import is the entry point for external data and schemas into the Mockomat modelling environment. The data import pipeline transforms raw files into queryable MongoDB collections with real-time progress tracking, while OpenAPI import generates a complete model scaffold from an existing API specification. Both paths feed into the same modelling and Runtime systems, and both produce artifacts that can eventually be included in an Export to generate a production backend. Selecting the appropriate import path depends on whether you are starting from data (use data import) or from a contract (use OpenAPI import).