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.
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
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
Our delivery approach
- 01Map the real data flowsIncluding the spreadsheet someone emails on Fridays. Undocumented paths are usually load-bearing.
- 02Design contracts firstInterfaces are agreed and versioned before implementation, so neither side is guessing about the other's behaviour.
- 03Assume failureIdempotency, retries with backoff, dead-letter handling and replay are designed in. Integrations fail; the question is whether they fail quietly.
- 04Instrument 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.
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
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
Official documentation
Official video channels
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
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.
Related services.
Talk to our experts about api & systems integration.
Tell us where you are. A specialist will read it and reply within one business day.
