API development and system integration services

The cost and timeline depend on the number of systems, the quality of their APIs and documentation, data flow complexity, and testing requirements. The ranges below are indicative; the final estimate depends on the agreed project scope.

API integration uses application programming interfaces (APIs) to pass data or trigger actions between software. For example, an online store can send order details to a payment service through an API.

System integration covers a wider business process. It links the systems involved so information can move from order placement to fulfilment without staff entering the same details again.

API integration describes one way systems communicate; system integration covers the broader process they support.

Custom API development creates an interface that lets a product or system share selected data and functionality with other software. The work may include REST API design and implementation, along with connections to internal systems or third-party platforms.

Testing, documentation and deployment may also form part of the project. The final scope depends on what the API needs to provide and how it will be used.

Use a ready-made connector when it supports both systems and the steps your process requires. For a standard connection between common platforms, it is often quicker to set up.

Choose a custom API integration when the connector cannot handle how your data needs to move or the rules your process follows. This gives you more control over the connection, with development and maintenance to plan for.

Some projects use both: a ready-made connector for standard tasks and custom development for specific requirements.

A missing API does not automatically rule out integration. UKAD first assesses the existing system, its available interfaces, and technical constraints to determine whether data can be exchanged reliably.

If there is no suitable interface, the system may need modernisation before integration is feasible. UKAD can assess options for modernising a legacy application, including gradual changes that keep the existing platform in use.

The right approach depends on how current the data needs to be for the next business process and what the connected systems support.

Real-time or near-real-time synchronisation suits processes that depend on recent updates. Scheduled synchronisation is appropriate when data can be processed at set intervals, such as for reporting or reconciliation. The update frequency should reflect the business need; real-time processing does not guarantee zero delay.

Some integrations combine both approaches: time-sensitive updates are processed promptly, while scheduled checks reconcile the data across systems. Microsoft’s guidance also distinguishes synchronous, asynchronous, and batch patterns, and recommends choosing according to business requirements and system capabilities.

UKAD’s information security practices are supported by its ISO/IEC 27001:2022 certification. For each integration, data protection measures are selected according to the systems involved, the personal data being processed, and the client’s requirements.

Depending on the project, safeguards may include limiting the data transferred and restricting access. Where UKAD processes personal data on the client’s instructions, the parties’ roles and responsibilities are documented contractually.

Testing depends on the systems involved and the project requirements. It may include checking API responses, data mapping, access controls and key business workflows, as well as how the integration handles timeouts or unavailable services. The required checks are agreed before release. Monitoring and post-release support depend on the project scope.

An outage can interrupt or delay data exchange, while a breaking API change may cause some requests to fail. Depending on the API and the business process, the integration may use controlled retries or queued processing to handle temporary failures.

When a provider changes its API, the connection may need updates and testing. UKAD can assess the impact and agree on the required changes; ongoing monitoring and maintenance depend on the project scope.

Ownership depends on the project agreement. In a typical integration:

• Custom source code and documentation created for the project are transferred to the client.

• Third-party and open-source components stay under their own licences.

• UKAD’s pre-existing tools and libraries are covered by separate terms in the contract.

Repository access and handover arrangements are agreed in the project agreement.

To scope an API or system integration project, UKAD reviews the business process, the systems involved, and the information that needs to pass between them. Available API documentation or sample data helps clarify the integration approach. Update frequency, hosting, security, and data protection requirements also inform the project scope, estimate, and timeline.

Access to a sandbox or test environment may be needed to validate APIs or data flows. The access required depends on the systems and project scope, and is agreed before credentials are shared.

UKAD can deliver a defined integration project or provide engineers to work alongside your existing IT team. The engagement model depends on the systems involved, the expertise required and the project goals.