Note: Operator is included as part of the Pro add-on. You'll need the Pro add-on to use it.
Setting up a Data Connector usually means reading API docs and filling in every field by hand. With Operator, you describe what Fin needs to look up or update, and Operator drafts a new connector or fixes one that isn't working. Use this article to learn what Operator can set up, how to review and test its proposals, and the limitations to be aware of.
Every change arrives as a proposal. You review it, approve each test call, and choose whether to publish it or save it as a draft. Operator can't change a connector or call an API on its own.
Note: To chat with Operator you need the Can access Fin Operator permission. To apply a connector change you also need Can manage Automation settings and inbound Workflows and Can manage data connectors and authentication tokens.
If you're new to Data Connectors, start with Add Data Connectors for Fin AI Agent.
How to build or fix a Data Connector with Operator
The whole process happens in an Operator chat, from the first request to the published connector.
Step 1: Ask Operator
In an Operator chat, describe what Fin needs. For example:
“Create a connector that looks up a Shopify order by its number.”
“Fin keeps saying it can't find the order. Can you fix the Get Order connector?”
Step 2: Operator investigates
Before it proposes anything, Operator can look things up in your workspace:
Search your connectors and read each one's full setup.
Read a connector's saved test response or mock response.
See which workflows and procedures use a connector.
Check recent success rates and run history. It sees status and timing, not what was sent or received.
List the attributes it can use in the request or as mapping targets.
List your authentication tokens by name and type. It never sees the secret.
Step 3: Review the proposal
The proposal appears in the chat as a Data connector card.
The header shows the connector name and a New, Live, Draft, or Paused badge. A rename shows the old name struck through.
API shows the method, URL, data inputs, headers, payload, test, and authentication tokens.
Data shows the response fields, Python code, and object mappings.
Fin shows the prompt Fin reads and the audience.
Security shows the customer authentication setting.
For an edit, the card shows what changes against the live version. Unchanged sections start collapsed, and each section shows how many lines were added and removed.
Authentication tokens are shown by name only.
Step 4: Approve the test
Before a test runs, Operator shows a card titled Test “connector name” with the values it will send.
Check the values. Nothing is sent until you click Run test. Cancel stops it.
The test calls the real API. The result shows as, for example, “Test passed (HTTP 200)” or “Test failed (HTTP 401)”.
Operator reads the response and uses it to set up the response fields.
Operator can also ask Fin a test question in a preview conversation, the way a customer would. This shows whether Fin picks the connector and how it uses the response. In a preview, Fin answers as if the chat's pending connector changes were already applied, and it uses the saved test response or mock rather than calling the API.
Important: Tests send real requests to the connected system. If a connector creates, updates, or deletes data, testing it makes that change. Use test records. Operator asks for your approval before every test.
Step 5: Apply the change
You choose how the change lands:
On a live connector, the main button is Publish. Save as draft (or Update draft, if a draft exists) is in the menu.
On a new, draft, or paused connector, the main button is Save as draft (or Update draft). Publish is in the menu.
Publish asks “Ready to publish?” first. It stays disabled until Operator's test has passed, unless the connector uses a mock response. An edit that leaves the request alone (URL, method, headers, body, inputs, and authentication tokens) keeps the connector's earlier passing test.
A deletion shows a red Delete button and a warning that it can't be undone.
The trash icon (Discard change) throws the proposal away.
Apply all applies every change in the chat. A new connector lands as a draft, and an edit keeps its current live or draft state.
If someone edited the connector while the proposal was pending, the card says “This change is based on an outdated version” and applying asks “Apply over newer changes?”. The newer edits are overwritten only if you click Apply anyway.
Step 6: After you apply
A “Changes applied successfully” message shows, and the chat logs “You applied 1 change” with the connector marked Published or Draft. Every applied change also appears in the teammate activity log as “Operator proposal applied”.
A published change works like any connector built by hand, and Fin starts using it in conversations straight away. A draft has no effect on conversations until it's published. Customers never see Operator or its proposals.
What Operator can set up
Name and description — Teammates see the description in the connector's settings.
The request — URL, method, headers, and body. The URL must be HTTPS.
Data inputs — The values Fin collects from the customer, such as an order number. Each input has a name, type, and description, is marked required or optional, and can have a default value.
Authentication tokens — Operator can attach or detach existing tokens. Each token is sent as its own header.
Response fields — Built from a test response or a mock response. They decide which fields Fin sees, what each one is called, its format, and how coded values are translated into words. A Python code block can reshape the response instead.
A mock response — A sample response body, used to build the response fields before the API can be tested.
Object mappings — Write response values to conversation, user, or custom object attributes.
How Fin uses it — Whether Fin can pick the connector on its own, the prompt Fin reads to decide when to use it, whether Fin can write through it, and an audience built from segments.
Customer verification — Whether Fin calls the connector only for customers who have passed identity verification.
Tip: Operator puts customer attributes, such as the customer's email, straight into the request rather than adding them as data inputs. That's the recommended setup. Every data input Operator adds is a value Fin collects from the customer.
Known limitations
Operator credits — Operator chats use Operator credits like any other Operator work.
You apply every change — Operator can't publish, save, or delete a connector itself.
Tests send real requests — If a connector creates, updates, or deletes data, testing it makes that change in the connected system. Use test records.
Tokens — Operator can't see the values of authentication tokens, and it can't create, edit, or delete tokens. Add a new token in Authentication settings, then ask Operator to attach it. Keep API keys in tokens, not in the URL or body, where Operator can read them.
Applying replaces unpublished draft edits — Operator builds its change on the live version. Applying it, whether with Publish or Save as draft, replaces any draft edits made in the editor since then. Publish or discard your own draft edits first.
Live connectors can't be deleted — Operator can delete only draft or paused connectors. To delete a live connector, pause it in its settings first. Operator can't pause, resume, duplicate, or archive connectors, or roll back to an earlier version.
MCP connectors — Operator can't edit, test, or delete connectors that come from an MCP server. Manage them in the MCP server's settings.
No templates — Operator can't install a connector from a template.
Input types — Operator can't add static input values, or list and object input types.
Releases — Connector changes from Operator apply straight to the connector. They can't be added to a Fin Release.
Fin preview — When Operator asks Fin a test question, Fin uses the saved test response or mock rather than calling the API. Pending deletions aren't previewed, and a change with no test response or mock has nothing to return.
Settings link — In the chat's “You applied” list, the connector name doesn't link to its settings page. Open the connector from your Data Connectors settings instead.
FAQs
Why is the Publish button disabled?
Why is the Publish button disabled?
There's no passing test on the latest version of the change. Changing the URL, method, headers, body, inputs, or authentication tokens clears an earlier test. Ask Operator to run a test, or use a mock response. Save as draft always works.
Why does a test fail with 401 when the connector works in conversations?
Why does a test fail with 401 when the connector works in conversations?
Tests carry no end user identity, so connectors that check who the customer is can't pass a test. Tokens of the USER type send their static test value instead.
What can Operator see in my connector?
What can Operator see in my connector?
Operator never sees authentication token values. It sees the URL, body, and code block in full, the same as your connector settings show you, and only the first four characters of header values. In test responses, any token or credential the API echoes back is masked.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts