What each one is
An existing connector is a ready-made link between two products. It may be a native integration offered by one of the vendors, an app from a marketplace, or a recipe on an automation platform. You configure it. You do not write it.
A custom integration is software written for your case. It reads from one system's API, applies your rules, writes to the other and deals with what goes wrong. It runs on infrastructure you control, and you or a partner maintain it.
The two options at a glance
| Existing connector | Custom integration | |
|---|---|---|
| Setup | Configuration, in hours or days | Design, build and testing |
| What it moves | The fields and records its maker chose | Whatever the APIs allow |
| Your business rules | Limited to the options provided | Written exactly as you need |
| When an API changes | The connector's maker updates it | You update it |
| Errors | Often a log and a retry. Details vary by product | Handled as you specify, with alerts and recovery |
| Cost shape | A subscription, often priced by volume | A build cost, then hosting and maintenance |
| Control | The maker decides what it does next | You decide |
When each one fits
Choose a connector when
- Both systems are widely used and a maintained connector exists
- Records map across with little or no change
- Volume is modest
- A delay or an occasional failed record is tolerable
- Nobody in the company can maintain integration code
Choose custom when
- Data must be transformed, combined or checked on the way
- One of the systems is in-house, old or unusual
- Volume would make per-task pricing expensive
- A lost or duplicated record means a lost order, a wrong invoice or a compliance problem
- The flow has several steps across more than two systems
Where connectors tend to stop
Connectors are built for the common case. These are the points at which real projects most often leave it. Test each one that applies to you before you rely on a connector.
| Need | What to check in the connector |
|---|---|
| Custom fields and objects | Whether it sees the fields you added, or only the standard ones |
| Two-way sync | What happens when the same record changes on both sides |
| Deletes and merges | Whether they travel across, or leave orphans behind |
| History | Whether existing records are loaded, or only new ones from today |
| Rules on the way | Whether you can filter, convert units or look up values |
| Failures | Whether you are told, what is retried and how you replay a failed record |
| Limits | API rate limits of each system, and the connector's own volume tiers |
| Order of events | Whether a payment can arrive before the order it belongs to |
The routes in between
| Route | What it means | Fits when |
|---|---|---|
| Native integration | A link built by one of the two vendors | It covers your fields and direction |
| Automation platform | Workflows assembled on a platform such as Make, Zapier or n8n | Flows are simple, volume is moderate and someone owns them |
| Integration platform with custom code | A platform for the plumbing, with your own code for the rules | You want monitoring and connectors, plus logic of your own |
| Fully custom service | Your own integration service and queue | Reliability, volume or unusual systems demand it |
A sound architecture often uses several of these at once. Standard flows run on connectors. The one flow that carries money or stock is custom, with proper error handling.
A worked example
An online store and its back office
The retailer is invented. It needs its store, its accounting system and its warehouse to work together.
- Store to email marketingNew customers should appear in the mailing tool. A standard connector does this. Decision, connector.
- Store to accountingOrders become invoices. The connector exists, but the retailer needs bundles split into components and tax handled by region. Decision, connector for customers and payments, custom for invoice lines.
- Store to warehouseThe warehouse runs an older system with a file-based interface. Stock must never be oversold. Decision, custom, with a queue, retries and an alert when a file is rejected.
Three flows, three answers. The retailer paid for custom work only where a mistake would cost real money.
A checklist for each data flow
Connector or custom
0 of 7 checkedIf every line is ticked, use the connector. Each line you cannot tick is a reason to look at custom work for that flow.
What to do next
List your data flows, one per line, with what moves, in which direction and what a failure would cost. Then run the checklist on each. Our comparison of real-time and scheduled sync covers the timing question.
Our system integration and API development pages explain how we build the custom side. You can also send us the list, and we will mark which flows we would leave to connectors.
Common questions
Are connectors reliable enough for business-critical data?
Some are. It depends on the connector, the maker and how it reports and recovers from errors. For data where a lost or duplicated record is costly, test failure cases deliberately, such as an API outage or an invalid record, and see what you are told and what you can replay.
What happens to a connector when one of the systems updates its API?
The connector's maker has to update it. Well-maintained connectors usually follow quickly, and abandoned ones break. Before relying on a connector, look at its update history and at who is responsible for it. With custom code the same job falls to you or your partner.
Is a custom integration always more expensive?
To build, yes. To run, not necessarily. Connector and automation platforms often charge by volume, and at high volumes a custom service on your own hosting can cost less each month. The comparison should use the volumes you expect in a year or two.
Can we start with a connector and replace it later?
Yes, and it is a sensible way to begin. A connector shows quickly what the flow needs and where it falls short. Keep a note of each limitation you meet. That list becomes the specification if you later build the flow yourself.
