Data Sources & Field Mapping

Your mock API serves rows from Mockomat's data pool. Mapping decides which pool data each of your tables and attributes reads. A table that is not mapped returns no rows; an attribute without a mapping returns no value.

This page explains where the data comes from, the three mapping types, and how to bind a table and its attributes.

Where the Data Comes From

• One shared data pool. Mockomat's team imports datasets into a shared pool — open data where a vetted source exists, generated sample data for the blueprints — and organizes them into tables with typed columns.
• Read-only. Your mock API only reads the pool; nothing you do changes it. You cannot upload your own datasets.
• Never invented. The runtime serves the rows as they are stored. Related rows stay consistent with each other, because they come from the same imported data.
• Same on every plan, guest sessions included.

Mapping Types at a Glance

Mapping type (in the app)	API name	Where the value comes from	In the mock API response
Data Source	SOURCE	A column of a table in the data pool	Yes — the value of the imported row
Constant	CONSTANT	A fixed value stored on the attribute	Yes — the same value on every row
Computed	COMPUTED	An expression over other fields of the record	No — the runtime does not evaluate expressions

New attributes start as Data Source without a bound column. Until you bind one, the attribute returns no value. The attribute editor no longer offers Computed; an attribute that already has a Computed mapping keeps it and is marked as not evaluated.

ws-datasrc-01-mapping-overviewMissing

Attribute editor with the Data Source and Constant mapping types.

Data Source (SOURCE)

The Data Source mapping binds an attribute to a column of the data pool. It is the mapping that gives your mock API its data.

Binding a Table

Mapping works table by table. In the Mappings pane of the modelling board:

1. Bind the table to a table of the data pool (shown as Canonical table). Suggest proposes a matching table; you can also search all tables yourself.
2. Pick a variant if the pool table holds several variants of the same concept. All variants serves all of them.
3. Bind the attributes to columns of that table. Adopt confident accepts all suggestions the app is sure about at once. The pane shows how many attributes are bound and how many are still open.

As long as a table is not bound, the runtime preview shows Not mapped to imported data and the mock API answers with an empty list and a NOT_READY error for it.

ws-datasrc-02-data-object-panelMissing

Mappings pane with the canonical table, suggestions and attribute bindings.

Attributes Without Data

Some attributes should stay empty, for example fields your frontend fills in itself. Mark them No mapping needed so they no longer show up as open. An attribute whose bound column no longer exists in the pool is marked Broken mapping; bind it to another column.

Data on every plan

Free User

Every plan, guest sessions included, maps against the same data pool. The mapping types and the binding workflow are identical.

Constant (CONSTANT)

A Constant mapping stores one fixed value on the attribute, for example "active" for a status field. The runtime returns it on every row, on rows of imported data and on rows composed from value pools alike.

ws-datasrc-05-const-configurationMissing

Constant value configuration for a status attribute set to 'active'.

Computed (COMPUTED)

A Computed mapping stores an expression over other fields of the same record, for example 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. Use a Data Source or a Constant mapping where you need a value.

How Mapping Reaches the Response

Situation	What the mock API returns
Table bound, attribute bound to a column	The column's value from the imported row
Table bound, attribute not bound	No value for the attribute
Table not bound	An empty list and a NOT_READY error
Constant attribute	The fixed value, on every row
Computed attribute	Not part of the response

The mapping type is invisible to API consumers: they receive field values without any indication of where they came from. Changing a mapping does not change field names or the response shape — it changes the values.

ws-datasrc-06-unmapped-hintMissing

Runtime preview showing the 'Not mapped to imported data' hint for a table.

Choosing a Mapping

Question	Answer
Should the field show realistic, varied data?	Bind it to a column (Data Source).
Should the field always hold the same value?	Constant — the runtime returns it on every row.
Is the value derived from other fields?	Computed is not evaluated and no longer offered; bind a column instead.
Should the field stay empty?	Mark it No mapping needed.

The Tables & Attributes page covers attribute configuration, and the Modelling Board page explains how to navigate between tables.

Mapping strategy for integration testing

Developer / Integrator

Bind the fields that drive business logic in your tests (categories, status codes, identifiers) to data columns, and query the records you need through operation parameters rather than relying on row order.

Summary

Mapping is the bridge between your model and the data your mock API returns. Bind every table to the data pool, bind the attributes your consumers read, and use the runtime preview to check that each table is ready to serve data.