Enterprise

Enterprise is the plan for organizations that outgrow Business: more team members, no catalog limits on projects and requests, and limits that can be adjusted to your contract. This page explains what the plan includes, how Mockomat separates your account from others, and how to keep domain modeling consistent across several teams.

Getting Enterprise

Enterprise is arranged with our sales team, not bought online. Use Talk to sales in the app or the contact form; pricing is on request.

What Enterprise Includes

• Everything in Business: API keys, team roles, code export, endpoint analytics.
• No catalog limits on projects, workspaces, monthly API requests, API keys per project, tables, attributes, relations, operations and board notes.
• Up to 26 team members, 5 of them maintainers.
• The Enterprise code package: code export generates a NestJS backend and an Angular frontend (see Export).
• Limits adjusted to your contract: our team sets your account's limits to what you agreed with sales.

For the limits of the other plans, see Account and Plans.

ent-01-tenant-isolationMissing

Account and project access model overview.

How Your Account Is Separated

Enterprise uses the same platform as every other plan. These boundaries apply to every account:

• Your account is the boundary. Projects, models, members, API keys and plan limits belong to your account. Every request is checked against it, so members of other accounts cannot open your projects.
• Project access per member. Maintainers see every project of the account. Other members see the projects they were given access to when they were invited, with an optional per-project override that can restrict, but never raise, their role.
• One API key per consumer. Every project in an account answers its mock API only to requests with an API key of that project. Keys can be revoked at any time.
• Shared, read-only mock data. The mock API serves rows from Mockomat's data pool, which our team imports and maintains. Your requests only read it, and it is the same on every plan. You cannot upload your own datasets.

ent-01b-isolation-architectureMissing

Account, project and data boundaries.

Team and Roles

Role	What it adds
Readonly	Sees projects, the model and the data preview; reads board notes
Reporter	Writes and edits board notes and their comments
Editor	Builds the model, creates projects, manages API keys, runs code export
Maintainer	Deletes projects, manages members and their project access, manages workspaces

Each role includes everything of the roles above it. The owner of the account is a maintainer and manages billing. See Team & Roles for the full permission list and the invitation flow.

ent-02b-team-collaborationMissing

Team member management and role assignment.

Sessions and External Consumers

• Sign-in sessions: on Enterprise, the account owner can stay signed in on several devices at once. Invited members do not get this from the account they join: they are signed in in one place at a time unless they own an account whose plan allows more, and signing in elsewhere ends their earlier session. Everyone is signed out automatically after a period without activity.
• API consumers: every request to the mock API carries an API key of the project. Use one key per consumer or environment (development, staging, CI) so that you can revoke one without touching the others.
• Actor tokens (optional): a consumer can request an actor token so that concurrent use of one API key can be capped. See Integrators → Actor Tokens.

Governance Model

A practical governance approach keeps domain modeling consistent as more teams join.

Domain Ownership

Assign clear ownership for each business domain area:

• Domain owner — responsible for entity naming, attribute definitions and relation strategy within their domain.
• Reviewers — team members who check changes before consumers rely on them (the Reporter role fits).
• Consumers — frontend developers and integrators who query the mock API but do not change the model (the Readonly role fits).

Shared Naming Conventions

Define organization-wide standards for:

• Entity naming — PascalCase, singular nouns, business language (e.g., Customer, not customers_tbl)
• Attribute naming — camelCase, descriptive, no abbreviations (e.g., totalAmount, not tot_amt)
• Relation naming — clear direction and cardinality
• Operation naming — consistent plural names for list operations, singular names for detail operations

Keep a reference project that follows these conventions, and fork it as the starting point for new projects.

Review Gates

Stage	Review Focus	Who Reviews
Model change	Naming consistency, attribute completeness, relation correctness	Domain owner
API exposure change	Operations, parameters, page sizes	Domain owner + integrator
Before export	Runtime behavior, parameters, sorting, relations	Domain owner + QA
After export	Generated code, module boundaries, inputs	Development team lead

Readiness Criteria

Define what "ready" means for each entity before consumers depend on it:

• Every attribute consumers need is bound to a column of the imported data
• Relations resolve in the preview
• Operation parameters and sorting return the expected rows
• Pagination produces clean page boundaries

ent-02-governance-controlsMissing

Governance controls across modeling and runtime stages.

Security

• Sign-in: the app uses a signed token per sign-in session. Signing out, inactivity and a password change end sessions on the server.
• API keys: keys are secrets. Use them from server-side code, CI or a proxy — never ship one in a frontend bundle — and revoke a key as soon as it is no longer needed.
• Encrypted traffic: the app and the mock API are served over HTTPS.
• No production data needed: mock APIs serve rows from Mockomat's data pool, so your test environments never need real customer data.

ent-03c-security-overviewMissing

Security overview.

Operational Best Practices

1. Define readiness criteria per entity before assigning it to a team.
2. Include runtime checks in reviews — run the preview before consumers depend on a change.
3. Export at milestones — keep the generated code in version control and note which model state it came from.
4. Watch usage — use endpoint analytics to see which operations consumers call before you change them.
5. Review regularly — keep domain definitions aligned with changing business requirements.

ent-03-enterprise-runtimeMissing

Enterprise runtime validation and operational checkpoints.

Enterprise implementation note

Enterprise User

Start with a small pilot — one domain, one team — with explicit ownership and a review cadence. Expand the conventions as more teams join.

Integrator note for enterprise contexts

Developer / Integrator

Use one API key per environment (development, staging, CI) and validate runtime behavior in CI before you rely on a model change.