Enterprise

Enterprise documentation focuses on control, governance, and repeatable architecture evolution. Mockomat Enterprise is designed for organizations that need maximum isolation, compliance capabilities, and the ability to scale domain modeling across multiple teams.

Enterprise Priorities

Enterprise teams operate under different constraints than individual developers or small teams. The key priorities are:

• Isolation and clear boundaries — strict separation between tenants, projects, and data.
• Controlled API exposure — private endpoints with authenticated access for every consumer.
• Reproducible architecture states — the ability to recreate or audit any model state at any point.
• Auditable change flow — visibility into who changed what, when, and why.
• Compliance readiness — data handling practices that meet regulatory requirements.

ent-01-tenant-isolationMissing

Tenant and runtime isolation model overview.

Tenant Isolation

Every Enterprise customer operates within a dedicated tenant that provides strict boundaries at every level of the system.

Data Isolation

• Separate MongoDB collections — each tenant's mock data is stored in isolated collections, never mixed with other tenants.
• Tenant-scoped queries — every database query is automatically filtered by tenant ID, preventing cross-tenant data leakage.
• Independent project spaces — projects within a tenant share no data or configuration with projects in other tenants.

Runtime Isolation

• Per-tenant schema generation — GraphQL schemas are generated independently per project within the tenant.
• Isolated API endpoints — each project gets its own endpoint path, scoped to the tenant's access controls.
• Independent rate limiting — request limits and throttling are configured per tenant, not shared globally.

Configuration Isolation

• Custom session limits — enterprise tenants can set their own concurrent session and API actor limits.
• Custom idle timeouts — session and actor idle timeout values are configurable per tenant.
• Custom rate limiting — request rate limits can be adjusted to match the organization's usage patterns.

ent-01b-isolation-architectureMissing

Data, runtime, and configuration isolation layers.

Governance Model

A practical governance approach ensures that domain modeling stays consistent and high-quality as the organization scales.

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 validate changes before they are promoted to production use.
• Consumers — frontend developers and integrators who query the mock API but do not modify the model.

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 indicators
• Query naming — consistent pluralization for list queries, singular for detail queries

Document these conventions and distribute them via internal blueprints so every team starts with the same standards.

Review Gates

Establish review checkpoints at key stages:

Stage	Review Focus	Who Reviews
Model change	Naming consistency, attribute completeness, relation correctness	Domain owner
API exposure change	Operation surface, query naming, pagination defaults	Domain owner + integrator
Pre-export validation	Runtime behavior, filter/sort correctness, relation traversal	Domain owner + QA
Post-export review	Generated code quality, module boundaries, DTO coverage	Development team lead

Runtime Validation Criteria

Define what "ready" means for each entity before it can be promoted:

• All required attributes have stable, non-null values
• All relations resolve correctly in preview
• Filter and sort operations work on all configured fields
• Pagination produces clean page boundaries
• No unresolved hints or warnings remain

ent-02-governance-controlsMissing

Governance controls across modeling and runtime stages.

Team Collaboration

Enterprise plans support multi-user teams with role-based access control.

User Roles

Role	Capabilities
Admin	Full access: create/delete projects, manage team members, configure tenant settings
User Admin	Manage team members, assign roles, view audit logs
User	Create and edit projects, run preview, export backends
Guest	Read-only access to shared projects and preview

Concurrent Session Management

Enterprise tenants support up to 50+ concurrent sessions (configurable). Each authenticated browser session counts toward the limit.

Session behavior:

• Sessions are tracked in Redis with configurable idle timeouts.
• When a session is idle beyond the timeout period, it is automatically released.
• When the session limit is reached, new login attempts are blocked until a session becomes available.
• Admins can view and manage active sessions.

API Actor Limits

For external API consumption, Enterprise tenants can configure concurrent actor limits per API key:

• Default: 20 concurrent actors per tenant
• Per API key: Configurable limits per key for different consumers or environments
• Actor tokens: Each external consumer receives a time-limited actor token that counts toward the concurrency limit
• Automatic cleanup: Expired actor tokens are automatically released

ent-02b-team-collaborationMissing

Team member management and role assignment.

Custom Datasets

Enterprise customers can upload and use proprietary datasets alongside Mockomat's built-in data sources.

Upload and Mapping

1. Upload data — provide your dataset in a supported format (CSV, JSON).
2. Metadata extraction — Mockomat scans the dataset and generates metadata (field names, types, sample values).
3. Map to attributes — use the uploaded data as a mapping source (just like OFF_FIELD) for any attribute in your model.
4. Isolated storage — custom datasets are stored in tenant-isolated collections, never shared with other tenants.

Use Cases

• Industry-specific data — use real product catalogs, employee directories, or inventory data for more realistic mock APIs.
• Compliance testing — test with data that matches your production schema shape without using real production data.
• Demo preparation — create mock APIs with branded, realistic data for client presentations.

ent-03b-custom-datasetsMissing

Custom dataset upload and mapping workflow.

Security and Compliance

Enterprise plans include enhanced security features for organizations with strict compliance requirements.

Authentication

• JWT authentication — all management API access requires valid JWT tokens.
• API key authentication — external consumers authenticate with project-scoped API keys.
• Actor tokens — time-limited tokens for concurrent API consumer management.
• SSO/SAML integration — planned for organizations that require centralized identity management.

Access Control

• Role-based access — granular permissions based on user role (admin, user admin, user, guest).
• Project-level permissions — control who can access, edit, or export specific projects.
• Tenant-level isolation — all access is automatically scoped to the tenant boundary.

Data Protection

• No production data required — mock APIs use synthetic or dataset-backed data, never real customer information.
• Tenant-isolated storage — each tenant's data is stored separately and inaccessible to other tenants.
• Encrypted communication — all API traffic uses HTTPS.
• Audit logging — track access patterns, model changes, and export events (planned).

Compliance Considerations

• GDPR readiness — synthetic data eliminates PII concerns in development environments.
• Data residency — on-premise deployment option for organizations with data sovereignty requirements.
• Retention policies — configurable data retention for session and usage data.

ent-03c-security-overviewMissing

Enterprise security and compliance feature overview.

On-Premise Deployment

For organizations that require complete control over their data and infrastructure, Mockomat offers an on-premise deployment option.

What you get:

• A self-hosted Mockomat instance running on your own infrastructure
• Full data sovereignty — all data stays within your network
• Custom domain and SSL configuration
• Integration with your existing authentication systems
• Direct database access for advanced use cases

Requirements:

• Docker-compatible hosting environment
• MongoDB, MariaDB, and Redis instances (can be managed services or self-hosted)
• Node.js runtime (v20+)

Pricing: $1,000 setup + $199/month maintenance (includes updates and support).

Runtime and Operational Expectations

Enterprise teams should treat runtime behavior as an explicit quality surface with measurable standards.

What to Expect

• Deterministic enough for collaboration — the same query produces the same structural shape every time, so team members can rely on consistent behavior.
• Transparent enough for review — every runtime decision (filter resolution, relation lookup, sort order) is traceable to model configuration.
• Flexible enough for controlled iteration — models can evolve without breaking existing consumers, as long as changes are validated through preview first.

Operational Best Practices

1. Define validation criteria per entity before assigning it to a team.
2. Include runtime checks in review processes — treat preview validation as a mandatory step.
3. Version your model exports — keep a history of generated backends tied to model snapshots.
4. Monitor API usage — track request patterns, error rates, and response times across endpoints.
5. Establish an update cadence — schedule regular model reviews to keep domain definitions aligned with evolving business requirements.

ent-03-enterprise-runtimeMissing

Enterprise runtime validation and operational checkpoints.

Enterprise implementation note

Enterprise User

Adopt a domain catalog with explicit ownership and a change-review cadence. This is the foundation for scaling architecture without losing clarity. Start with a small pilot (one domain, one team) and expand governance practices as you onboard additional teams.

Integrator note for enterprise contexts

Developer / Integrator

Build integration pipelines around stable model snapshots and documented runtime checks to reduce deployment surprises. Use versioned API keys per environment (development, staging, production) and validate runtime behavior in CI before promoting changes.