Connector

What is a connector?

A connector is a ready-made piece of software that talks to one specific system, so you do not have to write that conversation yourself. You point Fivetran's HubSpot connector at your CRM, give it permission, and your contacts, deals and companies start landing in the warehouse. The HTTP calls underneath are none of your business.

The word covers two related things. In a data tool, a connector reads a source or writes to a destination. In an automation platform, it is the block you drop into a flow: Microsoft describes a Power Platform connector as what lets the underlying service talk to Power Automate, Power Apps, Logic Apps and Copilot Studio, by exposing actions such as create a file and triggers such as when a new item is added.

People mix up the connector and the API it uses. The API is the door the vendor leaves open. The connector is the software that knows how to walk through that door every fifteen minutes for three years while nobody is watching.

What a connector does on every run

The job list is short and none of it is glamorous, which is exactly why buying it usually beats writing it.

• Authenticate. Sign in with OAuth or an API key, then refresh the token before it expires with no person in the loop.

• Discover the schema. Ask the source which objects and fields exist today, instead of assuming last year's layout.

• Read only what changed. Airbyte defines the cursor field as the column the cursor lives in, usually something like updated_at. Each run asks for the rows above the highest value the previous run saw, and the first run, having no cursor, reads everything.

• Page through the results. Ask for records a page at a time and keep asking until the source says there is nothing left.

• Stay under the rate limit. HubSpot allows a private app on a Professional account 190 requests per 10 seconds, and the daily budget of 625,000 requests is shared by every private app on that account.

• Map the types. A string in JSON becomes a date, a number becomes a decimal with the right precision, and something has to happen when the source starts sending a different shape.

• Write down its state. Record the cursor value it reached, so a failed run is something you resume instead of something you restart.

Each piece is easy on its own. Together, running unattended, they are most of what an integration actually costs. A REST call you can write in ten minutes is not the same thing as software that survives a renamed field, an expired token and a 429 at three in the morning, and then tells you which of the three it was.

Source, destination and action connectors

Source connectors read. They pull from your CRM, your accounting package, a database or a file store and hand rows to the pipeline. Everything above about cursors, paging and state belongs to this shape.

Destination connectors write. They load those rows into a warehouse or lakehouse, create the tables, upsert on a primary key, and decide how a delete in the source shows up. Fivetran has three answers to that last one: soft delete mode flags the row as deleted, live mode keeps an exact copy of the source table, and history mode keeps every version of the row.

Action connectors in an automation platform do neither in bulk. They fire a trigger or perform one operation: create a file, send a message, look up a customer. A flow may call five of them per event, and not one of them keeps a cursor.

So read the number on a vendor's homepage with care. A platform with 300 source connectors and one with 1,000 action connectors count different things, and neither number says whether the two systems you care about are covered properly.

A maintained connector versus your own API script

Both read the same API and land the same rows. They part company on one dimension: who does the work on the day the vendor changes something.

With your own script, that is you. A field gets renamed, a parameter becomes required, the paging style changes, the OAuth scopes get tightened. The script is fine until it is not, and the colleague who wrote it may have left two jobs ago.

With a maintained connector, that is the vendor's job. Airbyte puts the difference straight into its support levels. Its own connectors get few breaking changes and an upgrade window when one is needed. Marketplace connectors come from community members, with no support, no SLA, and backward-incompatible changes possible without notice. A connector you build yourself carries no guarantee that it is production ready.

Microsoft draws the line by publisher instead. A verified publisher owns the service behind the connector; an independent publisher does not, so any member of the public can submit a connector for a service they use. Both pass the same review, so what differs is who you can hold to account when the service underneath moves.

For an SME the rule is short. Buy for the systems everybody uses: your CRM, your accounting package, your webshop, your ad platforms. Build only where your source is genuinely unusual, or where the maintained connector stops short of what you need. Building it is the short part, owning it lasts as long as you use the source.

What to check before you trust a connector

Connectors are not interchangeable, and the differences only surface once you depend on them. Six questions, roughly in the order they bite.

1. Which objects and fields does it cover? A connector rarely covers the whole API. Put its documented table list next to the objects your reports need.

2. Does it read incrementally, and on which column? Airbyte names the failure mode outright: if records change without the cursor field being updated properly, the sync will not pick them up. A bulk update run straight against the source database stays invisible forever.

3. How does it handle deletes? A deleted record can vanish from the destination, get a deleted flag, or sit there forever. Airbyte only propagates deletes when the source emits them, which in practice means change data capture.

4. What happens to custom fields? Custom properties and custom objects are often treated differently from standard ones, and this is where CRM connectors disappoint most often.

5. How far back does the first load go? Several CRM connectors cap the first load at a historical window you set in months rather than pulling everything. Put that on twelve, and the three-year trend your board wants in January is a problem you discover in January.

6. What does it do when the vendor changes the API? Airbyte checks the source schema before each sync, treats new and removed columns as non-breaking, and pauses the connection for manual review when a primary key or a cursor disappears. Fivetran instead gives you three settings: allow all new data, allow new columns, or block all new data. No default is right for everyone, and somebody has to choose.

A worked example: the CRM connector and the custom field

A wholesaler runs HubSpot. Sales added custom properties to deals, and for eighteen months the monthly report has split won revenue by lead source. Then in June somebody renames the property from "Lead source" to "Acquisition channel". Inside HubSpot nothing breaks, the historical values are still there under the new label. In the warehouse the connector sees a new column. Renaming a custom field does not normally trigger a re-read of the history, so the new column starts filling from the rename onward and you have to start a historical sync yourself to backfill it.

So the report keeps running, with a channel on every deal from June onward and nothing before that, and no error anywhere. The first reading is "we have far fewer attributed deals than last year", the second is "marketing stopped tagging leads", and the true answer costs somebody an afternoon and a look at two columns. That is the shape of the cost: not a broken pipeline, but a quiet gap in a number people already trusted.

Connectors for AI agents

The same argument is now running one layer up. An agent that has to reach your systems meets the problem integration platforms met a decade ago: every system has its own API, its own authentication and its own vocabulary, and one bespoke bridge per system per agent does not scale.

The Model Context Protocol is the standardisation attempt, and it borrows the word for the same reason. Its specification calls the client a connector inside the host application, and takes its inspiration from the Language Server Protocol, which did for editors and programming languages what MCP is trying to do for AI applications and tools.

A data MCP server is the agent-facing version of a source connector: it sits in front of a database or a business application, authenticates once, keeps the caller away from the raw credentials, and hands the model a short list of tools instead of a connection string. What changes is the failure mode. A warehouse connector that misses rows leaves a gap you can find by counting. An agent that misses rows gives somebody a confident answer with the gap already inside it.