Use Cases

Overview

Monospace is the governed API layer for every app, person, and agent across your organization's systems. These use cases represent the most common ways teams adopt Monospace — from building a single application against an existing database to running backends, AI agents, and partner access from one platform.

Most teams start simple and grow. Connect a database and build an application against the generated API. Then add workspaces, AI agents, or external partners as requirements evolve.

Application Development

Connect an existing database and get a REST API, a TypeScript SDK, and an MCP endpoint, all governed by one permission model. Monospace introspects your schema, maps collections and fields, and exposes an API with authentication, filtering, and field selection built in. No code generation, no ORM configuration, no boilerplate.

Connect one or more data sources, or start without one on the workspace's built-in database. Give each application its own service account, so its access is scoped to the data it uses rather than inherited from whoever built it.

The Studio gives non-technical teams the same live data your applications use. They edit items, work with the data model, or ask the Assistant to find, summarize, or change data in natural language.

Common scenarios:

• Building new applications against existing production data
• Building the internal tools teams have been waiting on
• Replacing spreadsheets and old databases that have become a burden
• Exposing legacy databases to modern frontends or mobile apps

Build an Application →

Backend Consolidation

Instead of standing up and maintaining a separate backend for every team, client, or brand, give each one its own workspace on a single Monospace instance. Authentication, permissions, filtering, and field selection come with the generated API, so every backend you move onto Monospace is one less service to write and maintain.

Each workspace has its own members, roles, data sources, and data model, and its own API under /api/{workspace}. Workspaces connect to the same shared database or to separate physical databases when data isolation is required at the infrastructure level. Adding a team or client means creating a workspace, not deploying another instance.

Settings > Organization > Workspaces lists the workspaces in your organization. Each workspace sets its own name, logo, and primary color in Workspace Settings, so client and brand workspaces stay distinct.

Examples of operational domains managed through Monospace:

Common scenarios:

• Platform teams running backends for many product teams
• Agencies and software vendors managing a separate backend per client
• Multi-brand organizations sharing infrastructure but not data
• Franchise or partner models where each entity needs its own workspace
• Consolidating backends inherited through an acquisition

Multiple Data Sources in One Workspace

A workspace connects multiple physical databases into a single API. Query your orders database alongside your inventory database without ETL pipelines or data replication — an application that needs an order and its stock level asks once instead of calling two services.

Cross-database relationships link collections across different connectors. A customer record in one database can relate to order history in another, and both resolve in a single API call — the basis for unifying customer data from several systems into a single view (Customer 360).

AI Agent Governance

AI agents get access to live business data through the same governed API as your applications. Rather than giving AI systems raw database access, Monospace governs which items agents can read, create, update, and delete through the same role-based access control used for human users.

Each workspace has its own MCP endpoint for tools like Claude, OpenAI, and Cursor. An agent authenticates with an API key and acts with exactly that key's permissions, so each agent gets its own scope and can be revoked independently. Read, write, and schema tools each require the matching permission, and the ai:mcp entitlement controls who can connect at all.

Common scenarios:

• AI agents querying operational data to answer support questions
• Automated workflows that read and update items based on business rules
• LLM-powered applications that need structured, governed data access

Configure MCP →

External Data Sharing

Give customers and partners controlled access to your data through a governed API. Each party sees and updates only the items they're entitled to.

Many organizations hold data that external parties want to access, but the data isn't curated or accessible in a way that lets partners self-serve. As a result, each new relationship turns into a manual, integration-heavy project.

Monospace sits on top of your existing databases as a federation and governance layer. Each partner is assigned a role whose policies define exactly which collections, fields, and items it can read and write, enforced through the same role-based access control used everywhere else. Adding a partner is a permissions and configuration change, not a new integration.

Common scenarios:

• Offering partners and customers governed, self-serve access to curated datasets
• Letting external contributors update the items they're responsible for
• Replacing per-partner custom integrations with a single governed API layer
• Letting partner systems query curated data on demand instead of fielding manual data requests

Next Steps

• Introduction — Understand what Monospace is and how it works
• Installation — Set up your first workspace
• Build an Application — Build an app against a workspace's API
• Data Model — Learn how collections, fields, and relations work
• Access & Permissions — Configure role-based access control
• MCP Guide — Connect AI tools to your data