Skip to main content
A data connector is one call to your own system. The agent makes the call in the middle of the conversation. Look up an order, check an available time, create a case. The user waits a second or two and gets a real answer instead of a promise that someone will call back. You’ll find this on the agent under Data connector, at the bottom of the menu. Data connectors belong to the workspace, so the list shows all of your connectors, not only this agent’s. Click New connector. The panel has four steps: Request, Data, Agent, and Review.

Before you build one

Two questions decide whether this is the right tool. Does the agent need the answer during the conversation? If the information can wait, a summary after the conversation is simpler, and it can’t keep anyone waiting. Does the system answer quickly? More than two or three seconds is a long silence on the phone. If the system is slow, write something in Before the call, and set an honest Timeout in seconds.

Step 1: Request

Name is what the agent goes by when it decides whether to make the call. Write it for a colleague who has never seen your systems. “Check order status” is better than “Order API”. Description is internal, for your team. The agent doesn’t read it. Fill in Method and URL. Values from the conversation go in curly braces, for example https://example.com/api/v1/orders/{{order_id}}. Headers, query parameters, and body are set up in the fields below.

Data inputs

Under Data inputs, add each value the agent should find in the conversation before it makes the call. For each: Name, Format (Text, Number, or True or false), Description, and whether it’s Required. This matters more than it looks. With inputs declared, the agent fills them in one at a time. Without them, it has to put together a whole blob of JSON, and it gets that wrong more often.
The agent passes on whatever the user says to your API. Validate it on your own end.
Values the agent doesn’t need to find itself, such as the user’s phone number or the conversation’s language, don’t need to be inputs. Write them directly into the URL or body as {{caller_phone_number}} and {{language}}.

Test the call

Click Test to send a real call and see the response. If you don’t have a test environment, you can paste in a sample response instead, as JSON. We use it to build the field list on the next step.

Who can use it

Choose Only this agent or Every agent in the workspace. Sharing doesn’t turn it on for anyone. You add it to one agent at a time afterwards.

Step 2: Data

Restrict and shape shows the fields from the response. Tick the ones the agent may use. The rest doesn’t reach the conversation. Tick the box for:
  • What the agent should tell the user
  • What a later step in a workflow should use
Leave a field unticked if it’s irrelevant, or if you’d rather the agent couldn’t repeat it back.
The When the call works field is an instruction, not a filter. Writing “only mention the temperature” asks the agent to be discreet about data it can still see. If a field must not reach the agent, don’t tick it.

Step 3: Agent

Always fill in When the call fails. Otherwise the agent makes something up, and that’s exactly where users get told their order is confirmed when nothing was written at all. A good failure instruction says what happened, and what happens next.
If you turn off The agent may call this on its own, remember to add the connector to a workflow step. Otherwise it’s never called.

Step 4: Review

Read it through, and click Save connector.

In a conversation, or in a workflow

The same data connector behaves differently depending on where you use it. As an action on the agent, the agent decides when, based on the name. It fills in inputs from the conversation. As a step in a workflow, the workflow decides. It runs when the user reaches the step, and fills in the values from what the workflow has already collected. The Called directly column in the table shows which of the two applies. You can switch it directly in the list.

Keep an eye on it

The table has two columns that show whether the connector is working:
  • Health shows how the most recent real calls have gone.
  • Connector issues shows the latest failure. Click the column heading to bring the failures to the top. The text tells apart a real conversation, “Failed”, from a manual test, “Test failed”.
The row’s menu has Test now, Edit, Duplicate, and Delete. A connector a workflow is still using can’t be deleted. Take it out of the workflow first.

When something goes wrong

MCP servers

The card at the top of the page mentions MCP data connectors. It isn’t ready yet. The Add MCP server button is marked Coming soon and can’t be clicked.