Testing phaseThis environment is in pre-launch testing — all data will be reset at launch.
Skip to content

Workspace ​

The workspace is where domain, API, and runtime decisions stay connected in one operational flow. It is the central environment where you build, configure, validate, and iterate on your mock API project.

This page provides an overview of the workspace areas. Each area has its own detailed guide linked below.

Workspace Areas ​

The workspace is organized into distinct areas, each focused on a specific part of the modeling and API design workflow. Changes in one area are immediately reflected across the others.

Modelling Board ​

The visual canvas where you create entity table cards, position them spatially, and connect them with relation lines. The board is the starting point for all modelling work — drag to connect entities, zoom and pan to navigate large domains, and use the minimap for orientation.

Tables & Attributes ​

The configuration layer for each entity. Define table properties (name, description, icon), add attributes with types and flags (required, searchable, sortable, filterable), and select data sources for each field. Of the flags, Searchable changes the mock API: it puts the field into the searchTerm search.

Relations ​

Connect entities to define how data flows between them. Choose cardinality (1:1, 1:n, m:n), set direction and ownership, and specify linking columns. Relations determine how the runtime engine resolves nested GraphQL queries.

Data Sources & Mapping ​

Configure where each attribute's data comes from. There are three mapping types: SOURCE (a column of the imported data), CONSTANT (a fixed value, returned on every row), and COMPUTED (an expression the runtime does not evaluate; the attribute editor no longer offers it). The mapping type determines what values the field returns at runtime.

Views ​

Define how a table's data is presented in the runtime preview: which columns show and in which order. The mock API response itself always carries every mapped attribute.

API Design ​

Control how your domain model is exposed as a GraphQL API. Set query names, enable or disable operations per entity, configure pagination limits, and shape the consumer-facing API contract.

Preview & Hints ​

The feedback loop that keeps your model honest. Open preview to test queries against your mapped data. The preview tells you when a table is not mapped to imported data, when a view has no list operation, or when it has no identifier field. Preview should be part of every modelling iteration.

Modelling Runtime Preview ​

A dedicated panel that combines view configuration, live data preview, and relation detail into one place — accessible directly from the modelling board via the play button on any table card.

When working in one area, links to related contexts are available inline. For example:

  • From a table detail view, jump to the runtime preview to test queries.
  • From the runtime preview, jump back to the table editor to fix a field issue.
  • From the API design view, jump to the modelling board to review domain structure.

This navigation model keeps you in flow — you never need to go "back to the dashboard" to switch context.

Project Context ​

Each project has a unique slug that determines its API endpoint URL; calls from your own code carry an API key of the project (see Integrators):

POST /mock/{slug}/graphql
Authorization: Bearer mck_your_api_key

The slug is auto-generated from your project name but can be customized. Keep slugs short, lowercase, and hyphenated (e.g., customer-portal, ecommerce-demo).

Screenshot ws-01-project-switcherScreenshot ws-01-project-switcher
ws-01-project-switcherMissing

Project context bar and view switching.