How FloConnector works

FloConnector sits between your AI client and your vendors' APIs. It is a proxy that gives the client a clean, ready-to-use set of tools for each connector you turn on, without you wiring up any of the plumbing.

Your AI client
Claude, ChatGPT, …
Makes one tool call
FloConnector
The proxy
Auth, orchestration, analytics
Your vendors
50+ APIs
CRM, accounting, email, …

Composite tools, where they help

Most tools map to a single vendor action. But some jobs take several steps, and for those FloConnector offers composite tools: the client makes one call, and FloConnector's trusted harness makes the many underlying vendor calls it takes, threading ids from one step to the next.

Creating a deal from an email, for example, might resolve the contact, look up the right pipeline, and create the record. The client asks once; FloConnector does the sequence.

Why do this server-side?

Pushing every step into the model means more calls, more chances to thread an id wrong, and more tokens. Folding multi-step work into a single tool moves that into code we wrote and tested.

Failure is a ledger, not a crash

If a step in a composite fails midway, the harness does not throw a protocol error. It returns a structured partial-success ledger, what completed, where it stopped, what was produced, and what to do next, so the model can recover or report cleanly.

Big reads go through analytics

Some questions need a lot of data ("which leads went cold last month?"). Rather than pour thousands of rows into the model's context, FloConnector loads them into an ephemeral analytics engine, runs the query there, and returns just the answer. The raw data is discarded after the request.

Your credentials never reach the model

The three boxes above hide the part that matters most: your vendor tokens sit on FloConnector's side of the line and never travel to your AI client. The model asks for a job to be done by name. FloConnector fetches the token, calls the vendor, and hands back only the result.

flowchart LR

    subgraph CLIENT["Your AI client"]

      M["The model<br/><b>Sees tool names and results</b>"]

    end

    subgraph FLC["FloConnector"]

      E["Your endpoint"] --> H["Harness<br/><b>Makes the real calls</b>"]

      V[("Vault<br/>encrypted tokens")]

      H -.->|reads a token| V

    end

    subgraph VENDOR["Your vendors"]

      API["Xero, HubSpot, Gmail, ..."]

    end

    M -->|"one tool call"| E

    H -->|"authorised request"| API

    API -->|"result"| H

    H -->|"just the answer"| M

 

    class V accent

    class M good

A revoked connection stops working immediately, because the token lives here rather than in a config file on someone's laptop. And swapping which AI client you use changes nothing about the credentials.

What is stored

As little as possible. There is no persistent mirror of your vendor data. The one sensitive thing kept at rest is your vendor OAuth tokens, and those are encrypted app-side. Tool-call logs keep metadata for billing and support, not your payloads.

Next