Custom Integrations: Connecting Your Business Systems
How custom integrations connect CRM, ERP, finance and support systems: when to use iPaaS versus custom code, and how to keep integrations reliable.
A custom integrations build is code you own that moves data between systems on your terms. The alternative is a connector platform that does it for you with less control. Most organisations should use both: platform connectors for standard, low-risk flows, and custom code where the logic is specific to how your business works or where failure has a financial cost.
TL;DR
- Use a connector platform for standard flows. Write custom code where the logic is yours or the stakes are high.
- The cost of an integration is set by the worst system in it, not the best.
- Every integration needs an owner, a monitoring view and a documented recovery procedure.
- Sync direction and conflict rules must be decided before build, not discovered in production.
- Start with one flow that removes real manual work, prove it, then expand.
Custom code or a connector platform?
| Connector platform (iPaaS) | Custom integration | |
| Speed to first flow | Days | Weeks |
| Cost shape | Recurring subscription, often per task or per flow | Build cost then maintenance |
| Complex logic | Limited. Awkward beyond simple mapping | Unconstrained |
| Error handling | Generic retry, variable visibility | Designed for your recovery process |
| Volume economics | Can get expensive at high task volume | Predictable at scale |
| Ownership | Dependent on the vendor's roadmap and pricing | You own the code and the behaviour |
A sensible rule: if the flow is standard, low volume and failure is merely inconvenient, use the platform. If the flow encodes something specific about how your business works, runs at high volume, or failure costs money or breaches an obligation, write it. For SaaS products that need to offer connectors to their own customers, see how to build a plug and play integration system for your SaaS.
Decide these five things before any build
- Direction. One way or two way? Two way synchronisation doubles the design work and introduces conflicts.
- Source of truth per field. Not per system. It is common for one system to own the address and another to own the credit terms.
- Conflict rules. When both sides changed since the last sync, which wins, and is the loser recorded anywhere?
- Timing. Real time, near real time, or scheduled? Real time is not always better; batching is easier to reason about and cheaper to run.
- Volume and growth. Design for the record count in eighteen months, not the count today.
The parts people forget to scope
- Initial backfill of historical records, which often exceeds the ongoing sync in complexity.
- Deletion handling. Most integrations sync creates and updates and then silently ignore deletes.
- Rate limits and the behaviour required when they are hit. See how to use webhooks for real time order tracking for patterns on handling inbound events reliably.
- Credential rotation, and who is notified before a token expires.
- A monitoring surface someone actually looks at, with alerting when the failure rate crosses a threshold.
Common integration jobs in B2B operations
| Flow | Typical purpose | Watch for |
| CRM to ERP | Turn a closed deal into an order or invoice. Our CRM integration services handle this flow | Duplicate accounts and mismatched customer identifiers |
| Ecommerce to warehouse | Send orders for fulfilment, return stock levels | Oversell during the sync window |
| Support desk to product database | Show account context beside the ticket | Permissions, so agents see only what they should |
| Finance to data warehouse | Reporting and reconciliation, often requiring data pipeline engineering | Currency, timezone and period-close handling |
| Identity provider to application | Automated user provisioning via SCIM | Deprovisioning, which is a security requirement rather than a convenience |
Keeping integrations reliable after launch
Give every integration a named owner and a one-page runbook covering what it does, what breaks it, how to tell it is broken, and how to replay failed records. Review failure rates monthly rather than waiting for a complaint. Test against the partner's sandbox after any API integration services version announcement. Integrations degrade quietly, and the organisations that avoid outages are the ones that treat them as running services rather than completed projects. Our B2B software development services include ongoing integration support for exactly this reason.
Frequently Asked Questions
What is a custom integration?
It is purpose-built software that connects business systems using rules specific to your organisation, covering authentication, data mapping, scheduling, error recovery and monitoring. It differs from an off-the-shelf connector in that you control the behaviour, particularly around conflict resolution and failure handling.
When should we use an integration platform instead?
Use a platform when the flow is standard, the volume is modest and failure is merely inconvenient, for example pushing form submissions into a CRM. Write custom code when the logic encodes something specific about your business, when volume is high enough that per-task pricing hurts, or when a failure costs money.
How much does a custom integration cost?
It depends on the worst system involved rather than the count of systems. A documented REST API with a sandbox is a fraction of the cost of a legacy endpoint with no test environment and poor data quality. Estimate each integration individually and include the backfill of historical records.
What is the most common cause of integration failure?
Unclear ownership of data. When two systems both believe they own a record, you get overwrites and duplicates that are hard to unpick. Agreeing a source of truth per field, not per system, prevents most of it.
Should integrations be real time?
Not always. Real time suits actions users are waiting on, such as an order confirmation. Scheduled batches are cheaper, easier to reason about and simpler to recover when something fails. Choose per flow based on what the business actually needs.
How do you handle records that fail to sync?
Retry with exponential backoff and a cap, then move persistent failures to a dead letter queue where an operator can inspect, correct and replay them. Pair that with a scheduled reconciliation that compares both systems and reports drift, so nothing fails silently.
Who should maintain an integration after launch?
It needs a named owner, a runbook and a monitoring view. Whether that owner sits in your team or with your development partner matters less than the fact that someone is accountable and reviews failure rates on a schedule.
Can integrations break when a vendor updates their API?
Yes, and they do. Subscribe to the vendor's developer changelog, test against their sandbox when a version is announced, and prefer versioned endpoints where offered. Build integrations so that vendor-specific details live in one place rather than being spread through your codebase.
Systems that do not talk to each other?
Book a free 30 minute call. Tell us which two systems cause the most manual work, and we will map the flow, the conflict rules and the cost before you commit.