Integrations
Integrations with a Vectara agent come in three flavors: feeding data in, giving the agent something it can call mid-turn, and routing messages to the agent from another surface.
A data source pulls records in on a schedule. A tool lets an agent reach out during a turn. A connector lets a third-party surface deliver messages to an agent and receive its replies. The three are independent (wiring up one doesn't imply the others), but most real applications use at least two.
Data sources
A data source is the input to a pipeline. The pipeline runs on a trigger, fetches new or changed records from the source, and hands each record to an agent session as its first input. One record becomes one session. Today the only first-class source is S3, with more on the way. For the data model, the trigger types, and the sync modes, see Pipeline concepts.
If your data lives somewhere a pipeline can't reach yet, vectara-ingest is the older path. It is a Python crawler library you operate yourself, with much wider source coverage and arbitrary customization, at the cost of scheduling and running it on your own infrastructure. Reach for a pipeline when one fits the source you have, and fall back to vectara-ingest when no first-class source covers it yet.
Tools
A tool is a capability an agent can call mid-conversation. Built-in tools cover corpus search, the web, artifact handling, and a handful of other primitives. Custom tools cover the rest.
The fastest way to expose a third-party REST API to an agent is web_get, the built-in HTTP fetcher. On paper an agent can already call any URL with it, but a generic tool is a poor tool: the LLM has to guess the endpoint, the headers, and the body, and gets the whole page back. With a focused name, a tight description, locked-down parameters, and an output transform, the same primitive becomes a purpose-built API client without writing any code. The recipe is in Wrap a REST API with web_get.
When web_get isn't enough (multi-step auth flows, response pagination, side effects you don't want to encode in a description), write a lambda tool or expose your service through MCP.
Connectors
A connector is a venue. It is the inverse of a tool: instead of the agent reaching out, a third-party surface delivers an event to the agent and the agent responds back through the same channel. A connector owns its webhook, its credentials, and the translation between the venue's message shape and an agent session.
The only connector type supported today is Slack. A Slack connector binds an agent to a Slack app and signing secret, exposes a webhook path under /v2/agents/{agent_key}/connectors/{connector_id}/input, and turns threads in your workspace into agent sessions. We add new connector types as customers ask for them, so if you need Teams, Discord, or a custom surface, tell us. For the configuration shape, see the agent connectors section of the API reference.