API overview

The REST API is a first-class product surface alongside MCP. It uses the same workspace, module, permission, audit, usage, and error contracts as the MCP gateway.

Use REST for apps

Use REST when you are building an app, integration, headless CRM, Support, CMS, tasks backend, activity backend, billing-adjacent workflow, analytics backend, or server-side workflow. Use MCP when you are connecting an agent. Both operate on the same workspace data and permission model.

Customer applications should authenticate their own end users, then call Slab5 from their backend with a workspace-granted API key. Do not expose Slab5 API keys in browser clients or mobile apps.

In the hosted control plane, a shared Slab5 Team maps to a WorkOS organization behind the scenes. Developers can use a personal Slab5 tenant for individual work, then create or join Teams for shared workspaces and team administration.

Base URL

https://api.slab5.com/v1

API routes are versioned under /v1. Future breaking changes should use a new version rather than changing existing behavior silently.

Conventions

• API authentication uses workspace API keys with Authorization: Bearer YOUR_SLAB5_TOKEN.
• Credentials resolve to one tenant and one allowed workspace before module execution.
• Human control-plane workspace views require active membership in the requested workspace.
• Credential administration requires workspace owner or admin membership.
• Every route declares required scopes.
• Module routes require the module to be enabled for the workspace.
• New credentials cannot request scopes for modules that are disabled in the workspace.
• Reads and writes are filtered by tenant and workspace context.
• List endpoints support bounded result limits. Cursor pagination is.
• Exposed app-plane resources can include custom_fields JSON where the contract supports workspace-specific filtering and metadata.
• Billable operations can return billing pause or cap errors when usage balance is exhausted.
• Errors use a consistent envelope.
• Every response includes a request ID.
• Structured server logs redact credentials, tokens, and secret-like fields.

Request IDs

Every successful and failed response includes a request_id. Store this ID in client logs. It connects the API response to Slab5 audit logs, usage events, and support debugging.

{
  "data": {
    "id": "con_123",
    "name": "Jane Doe"
  },
  "request_id": "req_123"
}

See Request correlation for the full request ID, audit, usage, and support workflow.

Safe writes

Write requests should include an idempotency_key field in the JSON body. If a network retry happens with the same body and key, Slab5 returns the original result instead of creating duplicate records. Reusing the same key with a different body returns idempotency_conflict.

curl https://api.slab5.com/v1/contacts \
  -H "Authorization: Bearer YOUR_SLAB5_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Jane Doe","email":"jane@acme.com","idempotency_key":"contact_jane_doe_acme"}'

See Idempotency and retries for key design, retryable errors, and conflict behavior.