DashboardSign inStart your trial

Custom Integrations

Connect a service that isn't in the catalog: define a REST API or import an MCP server, then use it in your workflows like any other integration.

When a service you use isn’t in the catalog , you can add it as a custom integration. Custom integrations are workspace-private: only the workspace that owns them can see or use them, and once live they behave exactly like catalog integrations in the workflow builder.

#Availability

PlanCustom integrations
BusinessUp to 3 per year
EnterpriseCustom

Custom integrations aren’t self-serve. They’re built for your workspace with the Rills team, so reach out on a Business or Enterprise plan to get one set up. Business includes an allowance of three per year; Enterprise is scoped to your needs.

There are two ways to build one: from a REST API, or by importing an MCP server.

#Building from a REST API

Most services expose a REST API. To turn one into an integration, we define:

  1. Base URL, the root the API lives at (e.g. https://api.yourservice.com/v1).
  2. Auth type, one of API Key, Basic Auth, OAuth 2.0, or None (see auth types ).
  3. Operations, each action the integration can perform: HTTP method, path, parameters, and the request and response schemas.
  4. Connect-time config, any settings a user supplies when connecting (for example a subdomain or region), captured as a config schema.

Each operation becomes an Integration Action you can drop into a workflow. Operations can declare the scopes they need, the same scopes model as catalog integrations.

#Importing from an MCP server

If a service ships a remote MCP server, we can import it directly instead of hand-defining operations. You provide the server URL; the rest is discovered automatically.

Here’s what happens:

  • Tool discovery: Rills connects to the server and reads its tool list. Each tool becomes one Integration Action, named and described from the tool’s own metadata. There’s no manual operation mapping.
  • Auth setup: Rills reads the server’s published OAuth metadata (authorization and token endpoints, supported scopes). If the server supports dynamic client registration, Rills registers a client automatically the first time someone connects, with no client ID or secret to paste.
  • Connecting: when you connect, you authorize through the MCP server’s OAuth flow, the same log-in-and-grant-consent experience as any other OAuth integration. Tokens are refreshed automatically.

Imported tools work like any other integration action in the builder: pick the connection, map inputs, use the output downstream.

#Long-running tools

Some MCP tools kick off work that takes a while: generating an asset, running a batch job. When a tool reports that it runs as a background job, Rills handles it as a long-running step: it submits the job, then polls until the job finishes before the workflow moves on.

Long-running tools are billed the same as any other action, using workflow credits. Any files the job produces are saved to your workspace’s private storage so they stay available after the source link expires.

#Triggers vs. actions

Custom integrations provide actions, operations your workflow performs on demand. MCP-imported integrations map each tool to an action and don’t create event triggers. If you need a workflow to start when something happens in the external service, use a catalog integration that supports event triggers , or a scheduled trigger that polls on a cron.

#Limits

The per-plan counts above (three per year on Business, custom on Enterprise) are plan allowances, not runtime caps you’ll hit mid-workflow. Once a custom integration is live it has no special usage limits: it connects, executes, and bills exactly like a catalog integration. If you need more than your plan allows, talk to us about Enterprise.

#See also