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.
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
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.
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:
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
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 ownpatch (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.
Related APIs
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
- LuaTool - Creating tools
- Jobs API - Schedule recurring provider calls
- Environment API - Configuration for your skill code

