Skip to content

Rig documentation

Rig is a data context engine. It connects to your data warehouse, builds a context layer describing what the data means (tables, columns, metrics, business terms, usage rules and joins), and makes that context and the warehouse available to people and AI agents under your workspace's access controls.

This site documents the interfaces you can build against.

Interface Use it to Start here
MCP server Let an AI agent or MCP client explore the context layer and run governed, read-only SQL MCP server
Workflow triggers Start a workflow from your own systems over HTTP and collect the result Webhooks and callbacks
Ingestion Load data from SaaS tools, databases and files into a warehouse on a schedule Connectors and ingestion
Context and metrics Read and maintain metric definitions and the context layer, and bring in dbt models Data models
People directory (SCIM 2.0) Keep the people directory in step with your identity provider API reference

Base URLs

Region Base URL
Europe https://app.rig.so
United States https://app.us.rig.so

A workspace lives in one region. Use the base URL you sign in at. Organisations with a dedicated deployment use that deployment's hostname instead.

Workspace-scoped paths start with your workspace identifier, written {client_id} in this documentation. It is the first path segment of the application URL after you sign in. The examples use jaffleshop, a demonstration workspace.

What is stable and what is preview

Each operation in the API reference is labelled.

  • Not labelled Preview: workflow triggers, the MCP server and the SCIM endpoint. These authenticate with an API token, OAuth or a request signature and are intended for integration.
  • Preview: operations that authenticate with a signed-in user session. They are the operations the Rig application itself uses. They are live, but paths and response shapes may change, and they do not accept API tokens.

There is no version prefix in API paths today.

Conventions

  • Requests and responses are JSON (Content-Type: application/json) unless stated otherwise. SCIM uses application/scim+json.
  • Errors return a JSON body with error and request_id, and usually detail; request validation failures (422) omit detail. On the workflow trigger endpoints detail is an object whose error field is a machine-readable code; the exception is 423 WORKSPACE_PAUSED, whose code is at detail.error_code (and in the top-level error). SCIM errors use the SCIM error format.
  • Every response carries an X-Request-ID header. Send your own X-Request-ID to have it echoed back, and quote it when you contact support.
  • Requests are rate limited. A request over the limit receives 429. See Authentication.
  • List endpoints do not share one pagination scheme. Where a list is limited, the operation documents a limit parameter. SCIM uses startIndex and count.