Skip to main content
Connectors let Nash reach outside the Nash platform. Once you connect an external system, your Nash agents can call it as a tool — pulling a file, posting to an API, or running a capability your own service exposes — right inside a conversation or an automated run.

​
When to use this

Use a connector when the work you want Nash to do depends on a system Nash doesn’t manage on its own. For example:
  • Letting Nash read or create files in a shared drive while it works.
  • Calling one of your internal APIs (a pricing service, an inventory lookup, a ticketing system) as part of a delivery investigation.
  • Giving Nash access to capabilities you already expose through your own tooling.
If everything you need is already inside Nash — deliveries, jobs, providers, analytics — you don’t need a connector for it. Connectors are specifically for third-party and self-hosted systems.

​
How it works

A connector is an external system you turn on for your organization. Each connector contributes one or more tools — individual actions the agent can take (for example, “search files” or “create a record”). When a connector is active, its tools become available both in regular chat and to your custom agents on their scheduled or automated runs. There are three kinds of connector:
Connector typeWhat it isHow you authorize it
Prebuilt catalog connectorA ready-made integration Nash maintains. You install it and grant access.A secure sign-in (OAuth) consent flow with the third-party provider.
Custom connectorYour own REST API, described to Nash so it can call your endpoints.A static API key or token you supply, stored securely.
Self-hosted tool serverA tool server you run yourself that Nash connects to and imports tools from.None, or an API key header you provide.
A few things hold true across all three:
  • Connectors are scoped to your organization. What you connect is isolated to your org — another org can’t see or use it.
  • By default, every active connector is available to every agent. You can narrow this per agent (see Scope connectors to a specific agent).
  • Write actions still go through confirmation. When a connector tool would change something in the external system, Nash treats it the same way it treats other destructive actions — it pauses and asks for your approval before running, unless you’ve configured it to auto-execute.
  • Some Nash analytics capabilities are always available and don’t need to be connected — they’re built in.
Connecting and managing connectors is an admin-level capability. You’ll need the permission Nash uses for managing AI-agent configuration (typically held by org owners and admins). One exception: an admin can let individual members connect their own account for certain prebuilt connectors (see below).

​
Prebuilt catalog connectors

Nash maintains a catalog of prebuilt integrations you can install without writing any configuration. You browse the catalog, install the one you want, and then complete a sign-in (OAuth) consent flow with the provider to grant Nash access. After you consent, Nash holds the connection and keeps it refreshed so the agent can use it on demand. When you install a catalog connector you choose how it’s shared:
  • Org-wide — one shared connection that every agent in your org can use.
  • Per-user — each person connects their own account, so the agent acts as that individual user.
1

Open the connectors catalog

Go to your organization’s connector settings and browse the available prebuilt connectors.
2

Install the connector you want

Install it and pick the sharing scope — one shared org-wide connection, or a per-user connection where each member authorizes their own account.
3

Grant access

Nash hands you a secure authorization link to the provider. Open it, sign in, and approve the access Nash is requesting. You’re returned to Nash once consent is complete.
4

Use it

The connector’s tools are now available to your agents. If a connection ever expires or is revoked on the provider’s side, you can re-authorize it from the connector’s settings.
If you want members to be able to connect their own accounts without admin help, an admin can enable per-user self-install for a specific catalog connector. After that, members can authorize their own account for that connector even without the admin permission.

​
Custom connectors (your own API)

If the system you want to reach isn’t in the catalog, you can describe your own REST API to Nash and expose specific endpoints as agent tools. This is the most flexible option and a good fit for internal services. A custom connector has two layers:
  1. The integration — the base URL of your API plus how Nash should authenticate (an auth header and the secret value to send). The secret is stored securely and is never shown back to you; you can rotate it later.
  2. The tools — one per endpoint you want to expose. For each tool you give it a name and description, the HTTP method and relative path (with placeholders for parameters), the parameters it accepts, and whether the action only reads data or also changes it.
You can test a tool before relying on it, so you can confirm it behaves as expected with sample inputs. You can also pause an integration to switch it off temporarily without deleting it, and disable individual tools you don’t want exposed.
1

Create the integration

Provide your API’s base URL and the authentication details (the header name and the secret token or key Nash should send). Nash stores the secret securely.
2

Define one or more tools

For each endpoint, name the tool, describe what it does, set its method and path, declare its parameters, and mark whether it reads or writes data. The read/write classification is what tells Nash when to ask for confirmation before running.
3

Test before relying on it

Run a test call with sample arguments to confirm the tool returns what you expect.
4

Let agents use it

Once defined, the tools are available to your agents alongside everything else.
Mark each tool’s read-or-write classification carefully. Tools you mark as changing data (write or destructive) are gated behind confirmation by default, so a person approves them before they run. A tool left mis-classified as read-only could take an action without that checkpoint.

​
Self-hosted tool servers

If you already run your own tool server that speaks a standard streaming tool protocol, you can point Nash at it and Nash will import the tools it exposes. Each imported tool arrives for review: you approve the ones you want, optionally adjust its name, description, and whether it’s treated as read or write, and reject the rest. Only approved tools become available to agents. If your server’s tools change later, you can re-import to pick up the differences and review what changed. You can pause or remove a self-hosted connection at any time.
Self-hosted tool servers and custom connectors are newer capabilities and are still maturing. If you don’t see these options yet, check with your Nash contact about availability for your organization.

​
Scope connectors to a specific agent

By default, a custom agent inherits every active connector in your org. When you want an agent to use only a subset — for example, a scheduled reporting agent that should reach your analytics API but nothing else — you can set per-agent connector access:
  • Turn whole connectors on or off for that agent.
  • Disable individual tools within a connector you’ve granted (available for custom connectors and self-hosted tool servers).
This lets you keep a broad connector library at the org level while still giving each agent a focused, intentional toolset.

​
How the agent uses connectors

You don’t have to tell the agent which tool to call. When a connector is active, its tools are part of the agent’s toolset, and the agent decides when a request warrants reaching out to that system. In chat, it will use a connector tool the same way it uses any other capability — and if the action changes something, it surfaces a confirmation for you to approve first. In automated runs, the same applies: a custom agent on a schedule can use connector tools as it works, subject to whether you’ve set it to report only or to take actions on its own.

​
FAQ

Managing connectors — installing, authorizing, creating custom ones, and scoping them to agents — requires the permission Nash uses for managing AI-agent configuration, which is typically held by org owners and admins. Members can connect their own account for a catalog connector only when an admin has enabled per-user self-install for it.
Yes. Secrets — OAuth tokens, custom API keys — are stored securely and are never displayed back to you after you enter them. For custom connectors you can rotate the stored secret at any time. All connections are isolated to your organization.
Connector tools that change data are treated like any other action Nash takes: they go through a confirmation checkpoint before running. You see what the agent intends to do and approve or decline it. You control this through the same settings that govern Nash’s other actions.
A connector adds its tools to the agent’s toolset. If you want a tighter setup for a particular agent, scope its connector access so it only sees the tools relevant to its job.

Custom agents

Define reusable agents and choose which connectors each one can use.

Scheduling and automated runs

Put connectors to work in agents that run on a schedule or on events.

Guardrails & confirmations

Control which connector actions auto-run and which need approval.

Knowledge

Give agents reference material to ground how they work.