--- title: Nango API Integration on Truto slug: nango category: iPaaS canonical: "https://truto.one/integrations/detail/nango/" --- # Nango API Integration on Truto **Category:** iPaaS **Status:** Generally available ## MCP-ready AI tools Truto exposes 53 tools for Nango that AI agents can call directly. - **list_all_nango_integrations** — List all integrations in Nango. Returns: created_at, updated_at, name. - **get_single_nango_integration_by_id** — Get a single Nango integration by its unique key. Returns: created_at, updated_at, data. Required: id. Use the include query parameter to retrieve webhook_url or credentials. - **create_a_nango_integration** — Create a new integration in Nango. Returns: created_at, updated_at, data. Required: unique_key, provider. - **update_a_nango_integration_by_id** — Update an existing Nango integration by its unique key. Returns: created_at, updated_at, data. Required: id. - **delete_a_nango_integration_by_id** — Delete a Nango integration by its unique key. Returns: data. Required: id. - **create_a_nango_connect_session** — Create a short-lived (30 minute) connect session in Nango for the Connect UI auth flow. Returns: token, connect_link, expires_at. Optional tags are copied onto the created connection and included in auth webhooks. - **nango_connect_sessions_reconnect** — Create a reconnect session in Nango to re-establish a connection with new credentials or manually refresh a token. Returns: token, connect_link, expires_at. Required: connection_id, integration_id. Only connections originally created with a connect session are compatible. - **list_all_nango_connect_session** — Retrieve a Nango connect session with its allowed integrations and default connection configurations. Returns: token, connect_link, expires_at. - **nango_connect_session_bulk_delete** — Delete a Nango connect session. Returns an empty 204 response on success. - **create_a_nango_connection** — Create (upsert) a Nango connection for which you already have credentials. Returns the connection object including id, connection_id, provider, provider_config_key, created, credentials, metadata, tags, and errors. Required: provider_config_key, credentials. - **list_all_nango_connections** — List Nango connections without credentials. Returns per connection: id, connection_id, provider, provider_config_key, created, metadata, tags, and errors. - **get_single_nango_connection_by_id** — Get a specific Nango connection with its credentials by id. Returns the full connection object including id, connection_id, provider, provider_config_key, created, credentials, metadata, tags, and errors. Required: id, provider_config_key. - **update_a_nango_connection_by_id** — Edit a Nango connection by id, updating its tags or webhook URL override. Returns: success. Required: id, provider_config_key. - **nango_connections_set_metadata** — Set (replace) custom metadata for one or more Nango connections. Pass an array of connection IDs to update multiple connections at once — if any ID is invalid the entire operation is aborted with no changes made. Returns: connection_id, provider_config_key, metadata, error. Required: connection_id, provider_config_key, metadata. - **delete_a_nango_connection_by_id** — Delete a Nango connection by id. Returns: success. Required: id, provider_config_key. - **nango_connections_bulk_update** — Edit custom metadata for one or more Nango connections, overriding only the specified properties without replacing the entire metadata object. Pass a single connection ID string or an array of IDs to update multiple at once; if any ID in an array is invalid the entire operation is aborted with no changes made. Returns: connection_id, provider_config_key, metadata, error. Required: connection_id,… - **list_all_nango_connection** — List nango connections (without credentials). Returns each connection's id, connection_id, provider, provider_config_key, created, metadata, tags, and errors. Optionally filter by connectionId for an exact match, search for a partial match, or tags to match all specified tag key-value pairs. - **get_single_nango_connection_by_id** — Get a specific nango connection with its credentials by id. Returns: id, connection_id, provider_config_key, provider, errors, end_user, metadata, connection_config, tags, created_at, updated_at, last_fetched_at, credentials, created, error. Required: id, provider_config_key. - **create_a_nango_connection** — Add a nango connection for which you already have credentials using the deprecated `/connection` endpoint. Returns an empty 200 response on success. Required: provider_config_key. Supply credential fields appropriate to the auth type (OAuth2, OAuth1, Basic, API Key, etc.). - **nango_connection_set_metadata** — Set custom metadata on one or more nango connections using the deprecated `/connection/metadata` endpoint. Replaces the entire metadata object. Returns: connection_id, provider_config_key, metadata, error. Required: connection_id, provider_config_key, metadata. Pass an array of connection IDs in connection_id to update multiple connections at once. - **nango_connection_set_metadata_legacy** — Set metadata on a single nango connection using the legacy path-based endpoint. The request body is a free-form metadata object whose keys and values replace the connection's metadata. Returns an empty 201 response on success. Required: connection_id. - **nango_connection_update_metadata_legacy** — Update custom metadata for a specific Nango connection using the deprecated per-connection path endpoint. Only overrides specified properties without replacing the entire metadata object. Returns the updated metadata as user-defined key-value pairs. Required: connection_id. Deprecated — prefer the bulk_update method targeting /connection/metadata. - **delete_a_nango_connection_by_id** — Delete a specific Nango connection by id (deprecated endpoint; use /connections/{connectionId} instead). Returns: success, error. Required: id, provider_config_key. - **nango_connection_bulk_update** — Update custom metadata for one or more Nango connections (deprecated endpoint; use /connections/metadata instead). Only overrides specified properties without replacing the entire metadata object. Returns: connection_id, provider_config_key, metadata, error. Required: connection_id, provider_config_key, metadata. If one connection_id in an array is invalid the entire operation is aborted. - **list_all_nango_functions** — List functions deployed to a Nango integration, optionally filtered by type or name. Returns each function's id, name, type, enabled, last_deployed, and source. Required: unique_key. - **get_single_nango_function_by_id** — Get a single deployed function by id. Returns the function's id, name, type, description, enabled, last_deployed, and source. Required: unique_key, id. - **nango_functions_get_code** — Get the TypeScript source code of a deployed function. Returns: type, code, data. Required: unique_key, function_id. - **delete_a_nango_function_by_id** — Delete a deployed Nango function and enqueue its async teardown. Returns: success, added, updated, deleted. Required: unique_key, id, type. Functions managed by nango deploy (repo source) cannot be deleted. - **nango_functions_compile** — Compile TypeScript function source code into bundled JavaScript. Returns: added, updated, deleted. Required: code. - **nango_functions_create_dryrun** — Start an asynchronous dry run of TypeScript function source code against a Nango connection without deploying it. Returns: id, status, created_at, added, updated, deleted. Required: integration_id, function_type, code, connection_id. - **nango_functions_get_dryrun** — Get the status and result of an asynchronous function dry run in Nango. Returns: id, created_at, updated_at, data. Required: dryrun_id. - **nango_functions_create_deployment** — Deploy a function to an existing Nango integration using submitted TypeScript source code (type: function) or a provider template (type: template). Returns: id, status, created_at, added, updated, deleted. Required: type, integration_id, and either function_name, function_type, and code (for type: function) or template (for type: template). - **nango_functions_get_deployment** — Get the status and result of an asynchronous function deployment in Nango. Returns: id, created_at, updated_at, data. Required: deployment_id. - **nango_scripts_get_config** — Get configuration for all integration functions in Nango. Returns: data. Pass format=openai to receive the configuration in OpenAI function-calling format instead of the standard Nango format. - **list_all_nango_records** — List synced records from Nango for a given data model, ordered by modification date ascending. Returns: id, _nango_metadata. Required: model. The filter parameter accepts added, updated, or deleted; a response may contain fewer records than the limit when records have a large size. - **nango_records_prune** — Prune synced record payloads for a given connection and model using cursor-based pagination — empties the record payload while preserving metadata. Returns: count, has_more. Required: model, until_cursor. When has_more is true, make another request with the same until_cursor to continue pruning. The limit parameter (batch size) defaults to 1000 with a maximum of 10000. - **nango_sync_trigger** — Trigger a one-off execution of specified sync(s) in Nango for a given connection, or for all applicable connections if no connection is specified. Returns: success, added, updated, deleted. Required: provider_config_key, syncs. - **nango_sync_start** — Start the schedule of specified sync(s) in Nango for a given connection, or for all applicable connections if no connection is specified. The sync executes immediately upon starting and then continues at the configured frequency. If the schedule was already started, this has no effect. Returns: success, added, updated, deleted. Required: provider_config_key, syncs. - **nango_sync_pause** — Pause the schedule of specified sync(s) in Nango for a given connection, or for all applicable connections if no connection is specified. Returns: success, added, updated, deleted. Required: provider_config_key, syncs. - **nango_sync_get_status** — Get the status of specified sync(s) in Nango for a given connection, or for all applicable connections if no connection is specified. Returns: id, connection_id, name, variant, status, type, finishedAt, nextScheduledSyncAt, frequency, latestResult, recordCount, checkpoint. Required: provider_config_key, syncs. - **nango_sync_bulk_update** — Override a sync's default execution frequency for a specific connection in Nango, or revert to the default frequency by passing null for frequency. Returns: frequency, added, updated, deleted. Required: provider_config_key, connection_id, sync_name, frequency. Min frequency is 30 seconds. - **list_all_nango_environment_variables** — List environment variables configured in the Nango dashboard. Returns: name, value for each variable. - **create_a_nango_sync_variant** — Create a new sync variant for a specific connection in Nango. Returns: id, name, variant, added, updated, deleted. Required: name, variant, provider_config_key, connection_id. The variant name cannot be 'base' (protected). - **delete_a_nango_sync_variant_by_id** — Delete a sync variant for a specific connection in Nango. Returns: success, added, updated, deleted. Required: name, id, provider_config_key, connection_id. - **nango_actions_trigger** — Trigger an action for a Nango connection. When triggered synchronously, returns the action's result data (max 10MB). When triggered asynchronously via the x_async header, Returns: id, statusUrl, your-properties. Required: action_name, connection_id, provider_config_key. - **list_all_nango_proxy** — Forward a GET request to an external API through the Nango Proxy. Returns the external API's response body, headers, and status code exactly as received (opaque passthrough). Required: any_path. - **create_a_nango_proxy** — Forward a POST request with a JSON body to an external API through the Nango Proxy. Returns the external API's response body, headers, and status code exactly as received (opaque passthrough). Required: any_path. - **nango_proxy_bulk_update** — Forward a PUT request with a JSON body to an external API through the Nango Proxy. Returns the external API's response body, headers, and status code exactly as received (opaque passthrough). Required: any_path. - **nango_proxy_bulk_partial_update** — Forward a PATCH request with a JSON body to an external API through the Nango Proxy. Returns the external API's response body, headers, and status code exactly as received (opaque passthrough). Required: any_path. - **nango_proxy_bulk_delete** — Forward a DELETE request to an external API through the Nango Proxy. Returns the external API's response body, headers, and status code exactly as received (opaque passthrough). Required: any_path. - **list_all_nango_providers** — List all available Nango providers. Returns: name, display_name, auth_mode, logo_url, categories, proxy, authorization_url, authorization_url_encode, access_token_url, token_url_encode, token_url, authorization_params, scope_separator, default_scopes, token_params, authorization_url_replacements, authorization_url_fragment, redirect_uri_metadata, token_response_metadata, docs,… - **get_single_nango_provider_by_id** — Get a single Nango provider by id. Returns: name, display_name, auth_mode, logo_url, categories, proxy, authorization_url, authorization_url_encode, access_token_url, token_url_encode, token_url, authorization_params, scope_separator, default_scopes, token_params, authorization_url_replacements, authorization_url_fragment, redirect_uri_metadata, token_response_metadata, docs,… - **nango_providers_list_templates** — List template functions available in the Nango catalog for a provider. Returns: name, type, description, scopes, input, returns, json_schema, runs, auto_start, track_deletes. Each item is a sync or action template function with its input/output schema and schedule. Required: provider. ## How it works 1. **Link your customer's Nango account.** Use Truto's frontend SDK; we handle every OAuth and API key flow so you don't need to create the OAuth app. 2. **Authentication is automatic.** Truto refreshes tokens, stores credentials securely, and injects them into every API request. 3. **Call Truto's API to reach Nango.** The Proxy API is a 1-to-1 mapping of the Nango API. 4. **Get a unified response format.** Every response uses a single shape, with cursor-based pagination and data in the `result` field. ## Use cases - **Ship an agentic tool-calling layer for your AI product** — Let your users connect their own SaaS accounts and expose those integrations as secure, credential-scoped tools your LLM agents can invoke. Use action triggers to run write operations inside each tenant's permissions without ever exposing raw OAuth tokens. - **Offer native integrations without owning OAuth infrastructure** — Give your customers a one-click connect flow to any of 900+ third-party APIs while offloading OAuth, token refresh, retries, and rate limiting. Your team ships integrations instead of maintaining credential storage. - **Power scheduled data syncs into your product's backend** — Run incremental syncs on a schedule to pull your customers' CRM, HRIS, or ticketing data into your own database, vector store, or search index. Ideal for RAG pipelines, analytics, or building a local cache of records. - **Support deeply customized enterprise environments** — Deploy per-customer sync and action functions that handle bespoke custom fields, custom objects, and non-standard endpoints. Enterprise buyers get the exact data model they need without you writing rigid unified schemas. - **Proxy real-time API calls through a single unified auth layer** — Route live CRUD requests through a proxy that injects the correct end-user credentials at request time. Query native provider APIs directly without maintaining a normalized cache. ## What you can build - **Embedded Connect flow for end-user authentication** — Generate short-lived connect sessions server-side and render an in-app flow that maps each of your users to their own integration credentials. - **Auto-generated LLM tool schemas** — Fetch script configs in OpenAI function-calling format so your deployed actions become tools your agents can call with zero manual schema authoring. - **Per-tenant scheduled syncs with pause/resume controls** — Start, pause, and bulk-tune sync schedules per connection so you can offer different data freshness SLAs across pricing tiers. - **Async write actions with status polling** — Trigger long-running write operations asynchronously and poll for completion, letting your product offload retries and rate-limit handling entirely. - **Records API-powered ingestion pipelines** — Pull added, updated, and deleted records incrementally into your warehouse or vector DB, and prune stale data when a customer disconnects. - **Custom integration builder for enterprise deals** — Deploy customer-specific TypeScript sync and action functions on demand to support bespoke fields, objects, and endpoints for high-value accounts. ## FAQs ### How do end users authenticate their third-party accounts? You create a connect session server-side, then render the connect flow in your app. Once the user completes it, a connection is created that securely stores and refreshes their credentials, and you reference it by connection ID for all subsequent API calls. ### Can we support custom fields and custom objects? Yes. Because integrations are code-first TypeScript functions running on a managed runtime, you can define syncs and actions that read and write any custom fields or objects the underlying API supports — you're not constrained to a fixed normalized schema. ### How is data freshness controlled? Syncs run on a schedule you configure per connection. You can start, pause, trigger on demand, and bulk-update sync configurations, which lets you offer different refresh frequencies to different customer tiers. ### How do we expose integrations to an LLM agent? Deploy your actions as functions, then fetch the script config in an OpenAI-compatible tool-calling format. The resulting JSON schema can be passed directly to your model as available tools, and each invocation runs scoped to a specific user's connection. ### Are rate limits, retries, and token refresh handled automatically? Yes. The platform manages OAuth token refresh, retries, rate-limit backoff, and pagination for supported providers, so proxy calls, syncs, and actions don't need that logic reimplemented in your codebase. ### Can we run long-running write operations without blocking our app? Actions can be triggered asynchronously, returning an execution ID you can poll for status. This offloads retry and error-handling burden while keeping your user-facing surface responsive. ## Related reading - [Truto vs Nango: Code-First vs Declarative SaaS Integrations](https://truto.one/blog/truto-vs-nango-code-first-vs-declarative-saas-integrations/) — Compare the architectural differences between Nango's code-first integration framework and Truto's declarative unified API for B2B SaaS engineering teams. - [Merge vs Nango vs Alloy Automation: 2026 Architecture Comparison](https://truto.one/blog/merge-vs-nango-vs-alloy-automation-2026-architecture-comparison/) — Pass-through vs cache vs code-first unified APIs for real-time enterprise data. Workload decision matrix, cost models, and procurement checklist for 2026. - [Merge vs Nango: What's the Difference? (2026 Comparison)](https://truto.one/blog/what-is-the-difference-between-merge-and-nango-2026-comparison/) — Merge is a store-and-sync unified API with rigid schemas. Nango is a code-first framework where you write TypeScript. Here's what each costs at scale. - [Top 5 Nango Alternatives for B2B SaaS Integrations (2026)](https://truto.one/blog/top-5-nango-alternatives-for-b2b-saas-integrations-2026/) — Evaluating Nango alternatives? Compare the top 5 integration platforms for B2B SaaS in 2026 across architecture, pricing, and enterprise readiness. - [Truto vs Nango: Why Code-First Integration Platforms Don't Scale](https://truto.one/blog/truto-vs-nango-why-code-first-integration-platforms-dont-scale/) — A technical teardown of Truto vs Nango for engineering leaders. Learn why code-first platforms create technical debt and why declarative architecture scales better.