API & systems integration

Making systems that were never designed to talk to each other exchange data reliably.

What is it?

Most enterprise problems are integration problems wearing a costume. We connect ERP, CRM, warehouse, finance and third-party systems with interfaces that handle the unglamorous realities: partial failure, retries, schema drift, and the batch job that occasionally sends the same record twice.

For a technical reader

Integration work is mostly about failure semantics. Any interface between two systems will at some point deliver twice, deliver late, or deliver something that does not match the schema. The design questions are therefore: is the operation idempotent, what is the retry policy, where do poison messages go, and how is a replay performed without double-posting. Synchronous REST is right for request/response with a user waiting; events are right when several consumers care and the producer should not need to know about them.

Our services

Integration architectureA target design covering which systems are the source of truth, what moves synchronously, what moves as events, and where the boundaries sit.
API design and buildVersioned REST or GraphQL interfaces with documented contracts, authentication and rate limiting.
ERP and SaaS connectorsConnecting Oracle, SAP, Salesforce, Dynamics and line-of-business systems, including the ones with awkward or legacy interfaces.
Integration remediationTaking over a brittle set of existing interfaces and making them observable, retryable and documented.

What’s covered

REST and GraphQL design
Versioned, documented contracts with backwards-compatibility rules agreed up front
Event streaming
Kafka, SNS/SQS or equivalent where systems need to react rather than poll
ERP and CRM connectors
Oracle, SAP, Salesforce, Dynamics and the long tail of line-of-business systems
File and EDI transfer
SFTP batches, EDI documents and the fixed-width formats trading partners still send
Gateway, auth and limits
API gateway with authentication, rate limiting and per-consumer quotas

Business problems we solve

Data disagrees between systemsUsually no agreed source of truth and silent sync failures. We establish ownership per entity and make every transfer observable.
Integrations fail quietlyA nightly job stops and nobody notices for a week. Per-interface monitoring and alerting makes failure loud.
Point-to-point sprawlEvery new system means several new bespoke connections. A clear integration pattern stops the connection count growing quadratically.
Nobody knows what talks to whatUndocumented interfaces make every change risky. We produce a current-state map including the informal paths.

Our delivery approach

  1. 01
    Map the real data flowsIncluding the spreadsheet someone emails on Fridays. Undocumented paths are usually load-bearing.
  2. 02
    Design contracts firstInterfaces are agreed and versioned before implementation, so neither side is guessing about the other's behaviour.
  3. 03
    Assume failureIdempotency, retries with backoff, dead-letter handling and replay are designed in. Integrations fail; the question is whether they fail quietly.
  4. 04
    Instrument every hopYou can see what moved, when, and what did not. Debugging an integration without that is guesswork.

Solutions & project types

Examples of the work we take on in this area. These describe project shapes, not named client engagements.

ERP to e-commerceOrders, inventory and pricing flowing between a storefront and the ERP, with reconciliation and replay.
CRM and finance alignmentCustomer, contract and invoice data kept consistent between CRM and the finance system.
Partner and EDI onboardingStandardised onboarding for trading partners sending EDI or flat files on their own schedules.
Legacy system facadeA modern API in front of an older system so new applications need not learn its interface.

Technologies & platforms

API

  • OpenAPI / REST
  • GraphQL
  • gRPC
  • Webhooks

Gateways

  • Kong
  • AWS API Gateway
  • Apigee
  • Azure API Management
  • Oracle API Gateway

Eventing

  • Apache Kafka
  • AWS SNS / SQS
  • Azure Service Bus
  • RabbitMQ

Integration platforms

  • MuleSoft
  • Oracle Integration Cloud
  • Boomi
  • Workato

Formats & transport

  • JSON
  • XML
  • EDI X12 / EDIFACT
  • SFTP
  • CSV / fixed width

Security

  • OAuth 2.0
  • OIDC
  • mTLS
  • JSON Web Tokens
Learn this field

Where to start with api & systems integration.

Secondary to the work itself, but genuinely useful if you are building the skill. Every link goes to official documentation or an official channel.

Beginner

  • HTTP verbs, status codes and headers
  • JSON and schema validation
  • Write and consume a simple REST API
  • Authentication basics: API keys versus tokens
  • Read an OpenAPI specification

Intermediate

  • OpenAPI-first design and contract testing
  • OAuth 2.0 flows and when each applies
  • Idempotency keys and safe retries
  • Message queues and consumer groups
  • Pagination, filtering and versioning strategies

Advanced

  • Event-driven architecture and schema evolution
  • Exactly-once semantics and why it is usually at-least-once plus idempotency
  • Saga patterns for distributed transactions
  • Backpressure and rate limiting under load
  • Observability across service boundaries

Certifications

  • Confluent Certified Developer for Apache Kafka
  • MuleSoft Certified Developer – Level 1
  • Oracle Cloud Infrastructure Developer Professional
  • AWS Certified Developer – Associate

Practice projects

  • Design an API contract in OpenAPI before writing any implementation
  • Add idempotency keys so a duplicate request cannot double-post
  • Put a queue between two services and handle poison messages
  • Build a replay tool that reprocesses a date range safely
  • Add per-interface dashboards showing volume, latency and failures
FAQs

Questions we get asked.

Do we need an integration platform?

Not always. A handful of interfaces are often better as plain services you own. Platforms earn their licence cost at higher interface counts or where business users need to build flows themselves.

REST or events?

Both, for different jobs. Request/response with a user waiting is REST. One thing happening that several systems care about is an event. Forcing everything into one style is where integration designs go wrong.

Can you work with our existing middleware?

Yes. Replacing working middleware is rarely the first recommendation. More often the gap is monitoring, error handling and documentation around what already exists.

How do you handle a system with no API?

Options in order of preference: a supported export, a database view, file transfer, then UI automation as a last resort. We will say when the honest answer is that the integration will be fragile.

Start the conversation

Talk to our experts about api & systems integration.

Tell us where you are. A specialist will read it and reply within one business day.