Connector

Programs rarely speak the same language. An accounting system stores its data differently than an online shop, and both differ from a chat program. A connector is a ready-made link that mediates between two such systems. It knows how to ask one system for data and how to reshape the result so that the other system understands it. Think of it like a travel adapter for a power outlet: the electricity is the same, only the shape of the plug doesn’t fit, and the adapter solves exactly that problem. The core of a connector, then, is not the actual work itself, but the translation in between.

Why nobody builds every connection from scratch

Without connectors, every company would have to program every connection itself. Anyone wanting to hook an AI tool up to their email system, their customer database, and their cloud storage would face three separate build projects. Each of these takes weeks and then has to be maintained afterward. Connectors are prefabricated building blocks that reduce this effort to just a few clicks.

For software companies, this is a solid selling point. A product with 200 ready-made connectors is more attractive to customers than one with twenty, even if it’s not better in any other respect. That’s why connector counts regularly show up in press releases and quarterly reports. They serve as a measure of how well a piece of software fits into an existing IT landscape.

But there’s a downside too. Anyone who connects many systems via connectors makes themselves dependent on their providers. If a major service changes its interface, the connector suddenly stops working. This happens regularly in practice and can bring entire workflows to a halt for hours.

What happens between request and response

Almost every modern system offers what’s called an API. This is a fixed list of requests that another program is allowed to make, such as “give me all invoices from May.” The connector uses this list. It first logs in, then makes the request, and receives the response.

The response comes back in a fixed data format that usually doesn’t fit the target system. So the connector reshapes it: it renames fields, converts dates into a different format, and discards whatever isn’t needed. Then there’s the unglamorous but important matter of error handling. If a server doesn’t respond or a limit is reached, a good connector waits briefly and tries again.

It’s important to distinguish this from the API itself. The API is the door that a system offers. The connector is the one who knows how to walk through that door and repackages the goods on the other side. A common misconception is therefore to equate the two. A single API can be used by many different connectors.

Connectors in AI products and in healthcare

Connectors are currently most visible in AI assistants built for businesses. A language model on its own only knows what it saw during training. Only through connectors does it gain access to a company’s current documents, tickets, and spreadsheets. Providers such as Microsoft, Google, or Salesforce advertise exactly this.

The technical term also turns up in a completely different context. In Germany, the small device that connects doctors' offices to the healthcare system’s telematics infrastructure is officially called a “Konnektor” (connector). When news reports mention a “connector swap,” they’re referring to this hardware and to costs running into the hundreds of millions. The basic idea is the same: a standardized link between two worlds.

In everyday private life, people usually encounter connectors without ever naming them. When a fitness app sends its data to the phone’s health app, or an online shop automatically reports orders to the shipping provider, there’s a connector behind it every time. You only notice it once it fails.