Integration is where delivery gets real.
Anyone can call an API in a demo. Production is about what happens when the other system is slow, wrong, or briefly gone.
The problem
Most of the genuinely hard work in modern software is not building a feature. It is making two systems that were designed separately agree about the same fact, continuously, while both keep changing.
That work is where projects actually fail. A payment that posted twice. An inventory count that drifted. A webhook that arrived out of order at 2am and nobody noticed for a week.
We treat integration as a first-class engineering problem with its own failure modes: idempotency, retries with backoff, reconciliation, and alerting that tells you the truth. Every integration ships with a way to detect and repair drift, because every integration eventually drifts.
- Idempotent operations, so a retry cannot double-charge or double-post
- Reconciliation jobs that detect drift rather than waiting for a customer to find it
- Ordered and replayable event handling, not fire-and-forget webhooks
- Alerting on the business fact, not just on the HTTP status
What this covers
API integration
Payments, ERP, EHR, logistics, identity, and the long tail of internal systems.
Data pipelines
Moving and reshaping data with the lineage to prove what happened.
Reconciliation
Automated drift detection between systems that must agree.
Failure design
Retries, backoff, dead-letter handling, and idempotency keys.
Load behavior
Verified against the volume and burst pattern you actually see.
Secrets and access
Credential handling that survives an audit.
The other half: getting answers out
Moving data correctly is the first job. The second is that somebody in your business wants a number, and right now they either ask an engineer or they trust a spreadsheet that has been wrong since March.
We build the reporting layer as part of the product rather than as a project that starts after it. That means a warehouse or a reporting store fed by the same pipelines, metrics defined once so two dashboards cannot disagree, and lineage you can follow backwards when a figure looks wrong. The definition of a metric is the deliverable. The chart is the easy part.
Where the question is genuinely exploratory we will say so, and we would rather connect your existing tool to a clean model than sell you a dashboard build you did not need.
- A reporting store fed by the same pipelines, so operational and analytical data cannot drift apart
- Metric definitions written once and shared, so two dashboards cannot disagree about revenue
- Lineage from the number on the screen back to the row that produced it
- Event tracking designed with the product, because retrofitted analytics measure the wrong things
- Your existing BI tool connected to a clean model where that is the cheaper answer
Koombea's expertise in integrations with other systems and APIs has provided the knowledge necessary to solve many integration issues, which has been critical to our success.
What drives the estimate
Integration work is where fixed-bid pricing gets tested, because half the cost lives in the other party's system and none of it is visible from a feature list. We size it from the failure modes rather than from the endpoint count.
The single biggest driver is whether the partner system is well-behaved. A documented, versioned, idempotent API with a sandbox is a fraction of the cost of an undocumented SOAP endpoint that returns HTTP 200 with an error in the body.
- Whether a sandbox exists, because testing against production is a cost and a risk
- How the partner behaves on failure: does a retry duplicate, and can you tell
- Whether events arrive ordered, and what you must do when they do not
- Volume and burst pattern, which decide whether queues and backpressure are needed at all
- Whether the two systems must agree continuously or can reconcile nightly, which is an architecture decision, not a preference
The layers underneath
Queues and caching
Redis for caching and queueing, with background workers sized to the burst pattern rather than the average.
Observability
Datadog for application and infrastructure monitoring, CloudWatch where the workload is AWS-native.
Secrets and access
A managed secrets store with least-privilege access, chosen against your environment rather than ours.
Contract tests
Tests that fail when a partner changes their payload, before your customers find out.
Security in the pipeline
Dependency scanning, static and dynamic analysis running as gates rather than as an annual review.
Infrastructure as code
Terraform and Docker where the engagement includes provisioning, so an environment is reproducible.
Questions worth asking
The system we need to integrate with has no documentation. Now what?
Who owns it when the partner API changes and something breaks?
Do you build the reconciliation, or do we?
Can you work with our data team rather than around them?
We already have a BI tool nobody uses. Is that a data problem?
Four systems, one reconciled store
Jamar's store integrates pricing, inventory, payments and product data through STEP, with location-based price segmentation for a regional pricing model.
Bring us the backlog.
In 30 minutes, we will show you what a Pod would ship first and how we would price it.