Integration approaches

Integration approaches are often framed as a technical decision, API capability, data structure, or system compatibility. In practice, this is only part of the discussion. Most integration strategies are determined primarily by available resources (time, budget, ownership, and internal capability) rather than pure technical feasibility.

In nearly all cases, multiple approaches are technically viable. The deciding factors tend to be:

• Who will build and maintain the integration
• How much ongoing support capacity exists
• Whether the integration is reusable across customers
• The cost of long-term ownership vs short-term delivery

This document outlines the three main integration approaches within Xledger, clarifying not just how they work technically, but also how responsibility, scalability, and support models differ between them.

Ad-hoc/Custom integrations

The below outlines Xledger scope in the case of a custom integration

Custom integrations are typically driven by specific customer or partner requirements where no reusable or strategic solution exists.

See Zapier, Power Automate.

Scope and Ownership

• Developed, owned, maintained, and supported entirely by the customer or partner
• Xledger provides:
  • API documentation
  • Guidance during design
  • Support for its own APIs and import mechanisms only

There is no responsibility on Xledger for the connector, transformation logic, or operational reliability of the integration.

Technical Detail

APIs act purely as access points to data. They:

• Require authenticated requests
• Return structured responses
• Do not initiate any process themselves

To make them useful, a connector layer is required. This is typically implemented as an ETL process:

• Extract - Pull data from source systems or Xledger APIs
• Transform - Map, validate, and reshape data into the required format
• Load - Push data into the destination system (or back into Xledger)

Key point:

APIs are passive. Without a calling application or service, no integration occurs.

Implications

• Maximum flexibility
• Highest implementation effort
• Ongoing maintenance burden sits outside Xledger
• Suitable for niche or one-off use cases

Strategic integrations

The below outlines Xledger scope in the case of a strategic integration

Strategic integrations are identified as high-value, repeatable use cases across multiple customers and are delivered centrally.

See documentation on existing native integrations.

Scope and Ownership

• Designed, developed, and maintained by Xledger
• Connector is built and hosted using Cyclr (iPaaS)
• Fully supported through Xledger support channels

Technical Detail

The integration includes:

• Pre-built connectors to third-party APIs
• Standardised data mappings
• Managed execution (scheduling, retries, logging)

Cyclr acts as:

• The orchestration layer (coordinates workflows by managing the order, timing, and dependencies of processes) 
• The transformation engine (converts and restructures data from one format or schema into another) 
• The runtime environment (provides the infrastructure and resources required to execute code and run applications)

This removes the need for customers to build their own ETL pipelines.

Support Model

• Issues raised via Xledger support
• Routed to UK Integration Team where required
• Centralised monitoring and maintenance

Implications

• Lower customer effort
• Scalable across multiple clients
• Reduced flexibility compared to custom builds
• Dependency on Xledger roadmap and prioritisation

Product Integrations

The below outlines Xledger scope in the case of a product (or built-in) integration

Product integrations go one step further than strategic integrations. Instead of relying on an external connector platform, the integration capability is built directly into the Xledger application.

See documentation on some of our product integrations.

Scope and Ownership

• Fully designed, developed, hosted, and supported by Xledger
• Delivered as native product functionality

Technical Detail

In this model:

• The application itself becomes the connector
• No external ETL or iPaaS layer is required
• Data exchange is embedded into core system workflows

This often involves:

• Direct API consumption within the product backend
• Built-in validation and processing logic
• UI-level configuration for users

Support Model

• Managed entirely through Xledger support
• Escalated to R&D teams when required

Implications

• Highest level of reliability and integration depth
• Minimal setup for customers
• Least flexible (tied to product release cycles)
• Highest development cost internally