Integrations

​

How an integration is connected

​

Unified.to integrations

• Tools. Finalizing an agent connection creates an MCP server named after the integration type and activates it, so the agent has the integration’s operations on its next turn; lua integrations mcp activate|deactivate --connection <id> activates or deactivates it, and lua integrations mcp list shows it. A personal connection is mounted on each of your private agents instead.
• Events. lua integrations webhooks create --connection <id> --object <type> --event created|updated|deleted subscribes to an event such as task_task.created or task_task.updated; lua integrations webhooks events --integration <type> lists what an integration emits. Each delivery wakes the agent in a background turn carrying the payload, on the channel integration:<type>; payloads over 50,000 characters are truncated. Delivery is at most once: the platform acknowledges the event on receipt, retries nothing, and deduplicates nothing, so a provider that redelivers an event wakes the agent again. To run your own code instead, pass --hook-url with a webhook or trigger URL. For integrations without push, the provider polls at --interval <minutes> and the events arrive the same way. Subscriptions can be paused and resumed per webhook or per connection.
• Raw API access. Integrations.passthrough(type, { method, path, query?, data?, headers? }) calls the provider’s REST API through the agent’s own connection and returns { status, headers, data }. Provider errors, a provider’s own 429 included, come back in status rather than as exceptions, and the platform adds the authorization itself. When the agent has no connection of that type or passthrough is disabled for the integration, the call throws an IntegrationPassthroughError. The platform allows 120 passthrough calls per minute per agent, counting calls from your code and from the model’s <type>_passthrough tool alike; above that the call throws with status 429 and code passthrough_rate_limited and no retry-after value, so wait before calling again. Every passthrough call is logged by the platform for support and abuse review, never with bodies; the log isn’t readable through the CLI or API.

import { LuaTool, Integrations } from 'lua-cli';
import { z } from 'zod';

export default class GetPullRequestDiffTool implements LuaTool {
  name = 'get_pull_request_diff';
  description = 'Fetch the diff of a pull request in the connected GitHub account';
  inputSchema = z.object({ repo: z.string(), number: z.number() });

  async execute(input: z.infer<typeof this.inputSchema>) {
    const res = await Integrations.passthrough('github', {
      method: 'GET',
      path: `repos/${input.repo}/pulls/${input.number}`,
      headers: { Accept: 'application/vnd.github.diff' },
    });
    if (res.status !== 200) throw new Error(`github ${res.status}`);
    return res.data;
  }
}

​

Catalog integrations

​

Integrations and MCP servers

​

When to use it

• The agent must read or write a known SaaS: connect it and use the provisioned tools.
• The agent should react when something changes there: subscribe to the event, then route it to the agent, a webhook, or a workflow.
• You need an endpoint the integration’s tools do not expose, or a raw response body such as a diff: Integrations.passthrough inside a tool.
• The shop runs on Shopify or WooCommerce: connect it in the admin dashboard and let the integration own the catalog and basket.
• Don’t hand-write tools or a LuaMCPServer for a system the catalog covers.

​

Limits

​

Next steps