An integration connector is a prebuilt, reusable adapter that packages access to one external application or protocol, including its authentication, endpoints, data schemas and error handling, and exposes it to an automation platform as ready-made triggers and actions. In integration work within automation, connectors let a workflow read from or write to a system such as a CRM, an ERP or a file store without anyone coding raw API calls.
A connector sits between the generic workflow engine and the specific target system. The engine knows how to run steps, pass data and retry; the connector knows how a particular service expects requests to be signed, paginated and throttled. That separation of concerns is what makes low-code integration, iPaaS products and embedded integration possible at scale.
How an integration connector works
An integration connector translates platform-neutral operations into the concrete calls a target system understands. When a workflow step says “create contact”, the connector builds the HTTP request, attaches the stored credential, maps the input fields to the target schema, sends the call, interprets the response and returns a normalized result or a classified error.
Internally, most connectors share the same building blocks, summarized in the table below.
| Component | What it does | Typical implementation |
|---|---|---|
| Connection definition | Stores how to authenticate | OAuth 2.0, API key, basic auth or certificate |
| Triggers | Start a workflow on an event | Webhook subscription or scheduled polling |
| Actions | Perform an operation in the target | Create, read, update, delete or search calls |
| Schema metadata | Describes fields and types | Static definitions or dynamic discovery |
| Pagination handling | Retrieves large result sets | Cursor, offset or link-header paging |
| Throttling logic | Respects rate limits | Backoff on HTTP 429 responses |
| Error mapping | Classifies failures | Retryable versus permanent errors |
Triggers deserve special attention. A webhook-based trigger registers a callback with the target system and reacts within seconds, while a polling trigger queries for changes at an interval, often between one and fifteen minutes, and must track a cursor or timestamp so that it neither misses nor duplicates records.
Types of integration connectors
Integration connectors are usually classified by what they connect to and by who builds and maintains them. Both dimensions affect reliability, depth of coverage and long-term cost.
| Connector type | Connects to | Best fit |
|---|---|---|
| Application connector | A specific SaaS or enterprise product | Standard business workflows |
| Protocol connector | HTTP, SFTP, SMTP, database drivers | Systems without a dedicated connector |
| Database connector | Relational or document databases | Bulk reads and writes, change capture |
| Event connector | Message brokers and event streams | High-volume or asynchronous flows |
| Custom connector | An internal or niche API | Gaps in the vendor library |
| Unified API connector | A category of apps behind one model | Products integrating many similar tools |
Ownership matters as much as type. Vendor-certified connectors are maintained by the platform provider and tend to keep pace with API version changes. Community connectors extend coverage quickly but vary in quality. Custom connectors, often generated from an OpenAPI description, give full control but make the organization responsible for every future change in the target API.
Integration connector compared with related integration approaches
A connector is a building block, not an architecture. It is therefore useful to separate it from the integration patterns and platforms in which it is used.
| Concept | Scope | Relationship to connectors |
|---|---|---|
| API integration | Any program-to-program exchange | Connectors are a packaged form of it |
| Point-to-point integration | Direct link between two systems | Can be built with or without connectors |
| iPaaS | Hosted integration platform | Ships a library of connectors |
| Enterprise service bus | Central messaging backbone | Uses adapters, an older name for connectors |
| Unified API | One API for a software category | Replaces many connectors with one |
| Integration runtime | Execution environment | Hosts and runs connector code |
The term adapter is close to a synonym and is common in enterprise service bus and message-oriented middleware products. In modern low-code tools the same idea is marketed as a connector, an app or an integration, but the function is identical: encapsulate one system’s interface behind a standard contract.
Choosing and configuring an integration connector
Choosing a connector means checking whether it covers the objects, operations and events a workflow actually needs, not just whether the target application’s name appears in a catalog. Many connectors expose only the most common endpoints, and a missing operation can force a fallback to a generic HTTP step.
- Operation coverage: confirm that required actions, triggers and custom fields are supported.
- Authentication model: prefer OAuth 2.0 with scoped permissions over long-lived shared keys.
- Trigger mechanism: webhooks give lower latency and fewer API calls than polling.
- Limits and quotas: compare connector throughput with the target API rate limits and platform task quotas.
- Versioning policy: check how the maintainer handles deprecated API versions.
- Escape hatch: make sure a raw HTTP action exists for operations the connector lacks.
Configuration should use a dedicated service identity rather than a personal account, store secrets in the platform’s credential store and grant only the scopes the workflow requires. Field mapping should be explicit, with clear handling for empty values, date formats and time zones, because silent type coercion is a frequent source of corrupted records.
Limitations and failure modes of connectors
Connectors hide complexity, and hidden complexity can fail silently. The convenience that makes them attractive also makes it harder to see what happens on the wire when something goes wrong.
| Symptom | Likely cause | Remedy |
|---|---|---|
| Sudden authentication failures | Expired or revoked OAuth token | Monitor connections and alert on reauthorization |
| Missing records | Polling cursor skipped updates | Use webhooks or overlap the polling window |
| Duplicate records | Retries without idempotency | Use upsert actions or idempotency keys |
| HTTP 429 errors | Rate limit exceeded | Batch requests and apply exponential backoff |
| Field not available | Static schema outdated | Refresh metadata or use dynamic schema |
| Broken flows after an update | Target API version retired | Track deprecation notices and test upgrades |
A further risk is lock-in. Workflows built on proprietary connectors are hard to migrate, because each connector encodes vendor-specific behavior. Keeping business logic in data mapping and workflow steps, rather than in connector-specific features, limits that dependency.
The idea in brief
An integration connector is like a travel plug adapter. Your device works the same everywhere, but every country has a different socket. The adapter handles the shape of the socket so you do not have to rewire the device.
In the same way, an automation tool works the same for every workflow, and the connector handles the details of each application: how to log in, where to send requests and how to read the answers. You plug it in and use it, instead of building the connection yourself.
A practical scenario
An online retailer with a team of four operations staff wants every paid web order to appear in its accounting system and its warehouse tool within minutes. Writing custom code for three APIs would take weeks, so the team uses an integration platform with ready-made connectors for the shop, the accounting package and the warehouse system.
The shop connector’s webhook trigger fires on each paid order. A data mapping step converts line items and tax codes, the accounting connector creates an invoice with an upsert action keyed on the order number, and the warehouse connector creates a pick list. The connections run under a dedicated service account with only the scopes these steps require.
The workflow processes several hundred orders a day with a typical delay of under a minute. When the accounting vendor later retires an old API version, the platform updates the certified connector, and the workflow keeps running without changes from the retailer’s team.