Skip to main content

Overview

Integrations.passthrough gives your code direct access to a provider’s raw REST API through the integration your agent is already connected to. The platform relays the call server-side over the agent’s own bound connection — your code never sees OAuth tokens or provider credentials, and what the call is allowed to do is exactly what the connection’s OAuth grant allows. Connected integrations already expose curated MCP tools to your agent. Passthrough is for everything those tools don’t cover: any endpoint the provider documents, with your own query parameters, headers, and JSON bodies.
It works everywhere your code runs — tools, jobs, webhooks, and pre/post processors — and every connected integration also auto-attaches a matching agent tool (see The auto-attached agent tool below), so the agent itself can make raw provider calls too.
Scope-gated by the OAuth grant. The provider enforces its own OAuth scopes on every raw call. A call outside the connection’s granted scopes comes back as the provider’s own 401/403 inside the response envelope — never as a thrown error. Reconnect the integration with the needed scopes to widen access.

Import

The wire types are exported too, if you want to name them explicitly:

Method

Integrations.passthrough(integrationType, request)

Make one raw provider API call through the agent’s connected integration.
string
required
The connected integration to call through, e.g. 'github', 'microsoft', 'linear'. Must match an integration the agent is connected to (see lua integrations).
IntegrationPassthroughRequest
required
The provider call to relay — see the fields below.
Returns: Promise<IntegrationPassthroughResponse> — the raw provider response envelope.

Request fields (IntegrationPassthroughRequest)

'GET' | 'POST' | 'PUT' | 'PATCH' | 'DELETE' | 'HEAD'
required
HTTP method of the provider call.
string
required
Provider API path after the provider’s base URL, e.g. 'repos/{owner}/{repo}/pulls/42/files' for GitHub or 'v1.0/me' for Microsoft Graph. A leading / is tolerated. Relative traversal segments (..) are rejected.
Record<string, string | number | boolean>
Query-string parameters (pagination etc.). Forwarded to the provider as-is. A query string embedded in path is merged in too.
unknown
Request body. Objects and arrays are sent as JSON (with Content-Type: application/json set for you); a string is sent verbatim — set your own Content-Type header for non-JSON payloads. Ignored on GET/HEAD.
Record<string, string>
Extra request headers forwarded to the provider. Authorization and other auth/hop-by-hop headers are managed server-side and cannot be overridden. See the limitation on Accept media-type overrides below.

Response envelope (IntegrationPassthroughResponse)

Error model: envelope vs thrown

There are two distinct kinds of failure, and they surface differently on purpose: Provider errors come back in the envelope. If the provider itself rejects the call — missing OAuth scope (403), not found (404), provider-side validation (422) — the envelope relays the provider’s own status and body so you can see exactly what the provider said. Nothing is thrown. Always branch on status:
Route-level failures are thrown. If the call never reaches the provider, Integrations.passthrough throws a plain Error with a human-readable message. The relay rejects such calls with one of these typed reasons:
The Code column is the relay’s typed rejection code. The Error thrown in sandbox code carries the corresponding human-readable message — the code token itself is not embedded in the message — so treat any throw as “the provider was never called” rather than string-matching on codes. The auto-attached agent tool does surface the typed code directly on route-level failures.

Guardrails

Admin enable switch

Passthrough is enabled per integration by default, and workspace admins can switch it off for any integration. A disabled integration rejects with passthrough_disabled.

Every call audited

Every passthrough call — including denied ones — is audit-logged with identifiers, status, and latency. Request and response bodies are never logged.

Per-agent rate limit

Calls are rate-limited per agent (default 120 calls per minute). Exceeding it rejects with passthrough_rate_limited — back off and retry.

Limitation: Accept-header media-type overrides

Custom request headers are forwarded, but Accept media-type overrides do not change what the provider returns — the relay normalizes content negotiation. For example, requesting a GitHub pull request with Accept: application/vnd.github.diff returns the standard JSON representation, not a unified diff.Use the provider’s JSON-native equivalent instead: GitHub’s GET repos/{owner}/{repo}/pulls/{n}/files returns each changed file with its patch — the per-file diff — as plain JSON. Non-JSON response bodies are unaffected: endpoints that natively return text or HTML (e.g. GitHub’s markdown renderer) round-trip intact as strings in data.

Examples

Microsoft Graph: profile and files

The generic Microsoft connector exposes relatively few curated tools — passthrough opens up the whole of Microsoft Graph through it.

GitHub: review a pull request

List a PR’s changed files — each carries its own patch (the per-file diff) as JSON — then post a review with a JSON body.

The auto-attached agent tool

Every connected integration also attaches one synthetic tool to the agent — named {integrationType}_passthrough, e.g. github_passthrough — alongside that integration’s curated tools. It takes an equivalent method / path / query / body / headers input (note: the tool’s body field is named body, where the SDK’s is data) and returns the same { status, headers, data } envelope, so the agent can reach any provider endpoint its connection allows without you writing a tool for it. The same guardrails (admin switch, audit log, rate limit) apply identically. If you’d rather the agent not have raw API access to an integration, a workspace admin can turn the integration’s passthrough switch off — that disables both the agent tool and Integrations.passthrough calls for it.

Integrations Command

Connect integrations, manage scopes, and set up triggers

LuaTrigger

Wake the agent when events fire in a connected integration

LuaWebhook

Receive external events with full control of the HTTP response

AI API

Generate AI responses from within your tools

See Also