Custom API vs off-the-shelf integration

Use an existing connector when it genuinely fits

If a supported connector moves the right data at the right time, provides enough filtering and exposes failures, it is normally the sensible first choice. It can reduce build time and give the business a route that another administrator can understand.

A straightforward example is creating a CRM record from a standard form when the connector supports every required field and duplicate behaviour is acceptable. Bespoke code would add maintenance without necessarily adding value.

Recognise when the workflow and connector do not match

A low-cost connector becomes expensive when staff repeatedly correct its output. Missing fields, weak duplicate controls, limited triggers, poor error visibility and manual reformatting all indicate that the apparent saving is being paid back through operational work.

Before replacing it, confirm whether the platform can be configured differently. A field change or supported webhook may solve the problem without a custom service.

• The connector cannot apply required business rules.
• Records must be combined from several sources.
• The timing of updates affects customer or financial outcomes.
• Failures need audit evidence and controlled replay.
• The workflow supports an internal application or AI service.

Use middleware when translation and control are the missing pieces

Middleware sits between systems to validate, transform and route information. It is useful when the platforms can exchange data but disagree about field structure, identifiers or workflow logic. The middleware becomes a controlled boundary rather than forcing every system to understand every other system.

This can be implemented with an automation platform, a small managed service or custom code. The choice depends on complexity, transaction volume, internal capability and how important the connection is to day-to-day operations.

Build a custom API for a defined capability

A custom API is appropriate when an internal application, dashboard or AI workflow needs controlled access to specific business operations. It can expose a stable contract even when the systems underneath it are more complicated.

That contract should define authentication, permissions, payloads, validation, rate considerations and failure responses. An API without documentation and operational ownership is only another hidden dependency.

Compare total cost, not just build cost

Consider licences, implementation, testing, monitoring, changes, support and the staff time spent correcting problems. A connector with monthly fees may still be cheaper than custom ownership. A custom layer may be justified when it removes persistent manual work or supports an important product capability.

The decision should also account for vendor risk. Check API limits, authentication changes, support commitments and whether the platforms permit the intended use.

Use a staged decision

Start with the lightest approach that can be tested safely. Define the conditions that would justify moving to middleware or a custom API, such as unacceptable correction rates, missing controls or new application requirements.

This keeps the technical route proportionate and ensures custom development is solving an evidenced constraint rather than an imagined future problem.