Architecture
REST and MCP over the same business objects
Most platforms treat REST and MCP as separate worlds: REST is for application developers, MCP is for AI builders, and the two end up with their own data models, their own auth, and their own surfaces. That works until you want a human-built app and an AI agent to operate on the same record.
Slab5 starts from the other direction: REST and MCP are equal first-class interfaces over the same workspace data.
One data model
Every business object — leads, contacts, companies, deals, deal stages, invoices, payments, accounting accounts, journal entries, tasks, support tickets, CMS sites, CMS collections, CMS entries, marketing campaigns, marketing posts, assets, webhook endpoints, integration event types — has exactly one canonical representation. Whether you read it through REST or MCP, you see the same fields, the same validation, the same timestamps, the same audit trail.
One permission model
API keys are workspace-scoped REST credentials. MCP clients and OAuth grants are workspace-scoped agent credentials. Both carry explicit scopes. The same module-level checks gate access whether the caller is an app or an agent.
One audit log
A lead.created event in the audit log looks the same whether it was issued by a REST call from your backend or a create_lead MCP tool call from Claude. You can search the audit log by actor identity, by module, by resource type, by time — without caring which interface produced the event.
Why this matters
A single source of operational truth means you do not have to choose between an apps-only and an agents-only strategy. You can ship a portal for humans, a backend integration for your app, and an MCP-connected agent assistant against the same workspace — and none of them are working on a stale copy of each other's data.
Agent workflow
MCP tools 1:1 with REST endpoints. Same scopes, same audit trail.
API workflow
REST at api.slab5.com/v1. MCP at mcp.slab5.com/v1. Identical workspace data.
