Getting Started

This section helps a new user move from first access to a reliable first workflow in one session. By the end, you will have a working domain model with mapped data, a live GraphQL API you can query, and a clear understanding of what to do next.

What You Will Build

In this guide, you will:

1. Access Mockomat and choose your working mode.
2. Create a domain table that represents a real business concept.
3. Add attributes with appropriate types and mapping.
4. Establish at least one relation to another entity.
5. Preview your model through the live runtime.
6. Validate that the API returns the data shapes you expect.

The entire process takes about 15 minutes.

gs-01-start-entryMissing

Entry point from landing to app workspace.

Step 1: Choose Your Access Mode

Mockomat offers two access modes, each designed for a different stage of work:

Guest Mode (Quick Start)

Guest mode is the fastest path to a working mock API. No registration, no setup — just open Mockomat and start modeling.

What you get:

• One temporary project whose mock endpoint opens with its share token
• Full access to the modelling board, attribute configuration, and preview
• The same shared data pool and mapping types as every plan
• A live GraphQL endpoint you can query immediately

Limitations:

• Your work lives in this browser until your 24-hour guest session ends. The 24 hours run from the start of your guest session, which the app starts when you first open it in this browser, so a project you create later gets less time. A cleanup that runs every hour then deletes the project, so it can stay up to an hour longer.
• Clearing cookies loses your work earlier; sign up to keep it — the app offers to move the project into your account
• Only one project at a time
• No team sharing or project management
• No API keys — the endpoint opens with the project's share token

Guest mode is ideal for quick idea validation, demos, and evaluating whether Mockomat fits your workflow.

Account Mode (Persistent Workspace)

Account mode adds persistence, project management, and the ability to grow your usage over time.

What you get (Starter, free):

• 1 saved project (Professional and above include more)
• Persistent models that survive browser sessions
• 1,000 API requests per day
• The runtime preview of every project in the app (calls from your own code need API keys — Professional and above)

When to switch:

• When your first model proves useful and you want to keep it
• When you want to share your work — through preview and collaboration links, or by inviting teammates from Professional on
• When you want to iterate across multiple sessions

Guest and Starter guidance

Free User

Start in guest mode to test one concrete domain scenario quickly. Focus on naming clarity, required fields, and data behavior. If your model holds up after a few queries, create a free account to save it.

Registered user guidance

Registered User

Switch to account mode once your first model is useful. Persistence and repeatability become more valuable than instant-only speed. With an account, your project stays until you delete it, and from Professional on you can invite your team.

gs-02-guest-workspaceMissing

Guest workspace with first domain table.

Step 2: Model One Real Domain Slice

A domain slice is a small, coherent subset of your business model. Start with one or two entities that represent something real in your system.

Choose Meaningful Names

Avoid generic sample names. Use actual business language your team already uses:

Good examples:

• Customer, Subscription, Invoice
• Order, Payment, Shipment
• Product, Category, Review
• Employee, Department, TimeEntry

Avoid:

• Table1, TestEntity, MyModel
• Data, Item, Thing

Meaningful names make your model self-documenting and immediately useful for team discussions.

Add Attributes

Each entity needs attributes that describe its data. When adding attributes, consider:

Property	Purpose	Example
Name	Descriptive identifier	firstName, totalAmount, isActive
Type	Data type	String, Integer, Boolean, Date
Required	Must always have a value	true for email, false for middleName
Searchable	Takes part in the searchTerm search	true for name, title

The Sortable and Filterable flags do not change the mock API: you can sort by any attribute bound to a data column, and filtering uses the parameters you define on an operation in API design.

Practical tip: Start with 4-6 core attributes per entity. You can always add more later, but a focused model gives better feedback than a broad, shallow one.

Choose Field Mappings

Each attribute needs a data source. Mockomat supports three mapping types:

Data Source (SOURCE) — Imported data

Bind the attribute to a column of the shared data pool — imported datasets: open data where a vetted source exists, generated sample data for the blueprints. The runtime serves the imported rows and never invents values. Best for names, addresses, product data, categories, dates, and amounts.

Constant (CONSTANT) — Fixed values

Pins one fixed value on the attribute, e.g. a default status ("active"). The runtime returns it on every row, on rows of imported data and on rows composed from value pools alike.

Computed (COMPUTED) — Expressions

Stores an expression over other fields, e.g. a full name from first and last name. The runtime does not evaluate expressions, so a computed field is not part of the response. The attribute editor no longer offers Computed; an attribute that already has a Computed mapping keeps it and is marked as not evaluated.

gs-03-first-tableMissing

First table creation and attribute setup.

Establish a Relation

Once you have one entity modeled, add a second entity and connect them:

1. Create a second table (e.g., Order if your first was Customer).
2. Define the relation type: Does a customer have many orders (1:n)? Does an order belong to exactly one customer?
3. Set the direction: which entity owns the relation?

Relations are critical for testing how your API handles nested data. A model with at least one relation gives you much richer preview feedback.

gs-03b-first-relationMissing

First relation setup between two entities.

Step 3: Validate Through Preview

Preview is not only for demos. It is a model quality checkpoint. Every time you change your model, run a preview to confirm the change behaves as expected.

What to Check

Field readability — Do the returned field names make sense? Are they consistent (all camelCase, no abbreviations)?

Data shape consistency — Does each field return the expected type? Are strings actually strings, numbers actually numbers?

Relation behavior — When you query a parent entity, do child entities appear correctly nested? Is the cardinality right (array for 1:n, single object for 1:1)?

Missing mapping signals — If a table is not bound to imported data, the preview says so and the API returns no rows for it. Bind the table before moving forward.

Filter and sort behavior — Try a parameter you defined on the operation, and sort by an attribute with sortField. Do the results make sense?

Common Preview Issues

Issue	Likely Cause	Fix
Field returns null	No mapping configured	Bind the attribute to a data column (Data Source mapping)
Relation returns empty array	Relation not properly defined	Check relation direction and target entity
Sort has no effect	sortField is not the name of a mapped attribute	Use the name of an attribute bound to a data column
Filter returns all records	The operation defines no parameter for that argument	Add the parameter in API design

gs-04-first-previewMissing

First preview run with mapped and unmapped fields.

Step 4: Query Your API

Once preview looks correct, your mock API is already live. Call it from any GraphQL or HTTP client with an API key of the project — API keys come with the Professional plan and above. A guest project uses its share token (?token=…) instead. See Integrators for the details.

The endpoint for your project is:

POST /mock/{your-project-slug}/graphql
Authorization: Bearer mck_your_api_key

Try a simple list query:

query {
  customers(page: 1, pageSize: 10) {
    items {
      id
      firstName
      lastName
      email
      orders {
        id
        totalAmount
        createdAt
      }
    }
    total
  }
}

The response contains the imported rows your mappings point to, with relations resolved automatically.

gs-04b-first-queryMissing

First GraphQL query against the live mock endpoint.

Step 5: Decide the Next Path

After your first successful model and query cycle, you have several directions:

• Deepen your model — add more entities, refine attributes, establish additional relations.
• Configure API exposure — define which operations are available, set query naming conventions.
• Move toward export — if the model is stable enough, explore code generation to get a production-ready NestJS backend.
• Use blueprints — explore pre-built domain templates to accelerate future projects.
• Share with your team — create an account (if in guest mode) and invite collaborators.

Paid user guidance

Paid User

After first validation, standardize your table naming and operation strategy. This makes collaboration and governance easier later. Define conventions early — they compound in value as your project grows.

Enterprise user guidance

Enterprise User

Treat the first workflow as a pilot pattern. Define conventions early (naming, ownership, validation criteria) and reuse them across teams. A well-structured pilot becomes the template for every subsequent project.

gs-05-next-stepsMissing

Decision point after first successful preview cycle.

What You Have Now

After completing this guide, you have:

• A domain model with at least one entity, meaningful attributes, and configured data mappings
• A live GraphQL API endpoint that returns rows of the data pool
• Validation that your model behaves as expected under real queries
• A clear understanding of the model → preview → query workflow

From here, explore Core Concepts to understand the architecture behind what you just built, or dive into Workspace for a detailed guide to the modeling tools.