SERVICE
API development and integration
The layer that decides whether your systems cooperate or merely coexist.
What this actually is
An API is a contract other software depends on, which makes it different from internal code: you cannot quietly change it, and every mistake in its design is inherited by everyone who integrates.
Integration work is mostly about failure. The happy path is an afternoon. What takes the time is what happens when the third party is down, when a webhook arrives twice, when a token expires mid-batch, and when a rate limit appears at the worst possible moment.
What we do
API design
Resources, versioning, pagination and errors that tell the caller what to do — designed before implementation, because the contract is the product.
Integration
Third-party systems wired in with auth, retries, backoff and idempotency, so a duplicate delivery does not become a duplicate charge.
Data synchronisation
Keeping systems consistent, including the conflict rules for when two of them disagree.
Documentation and testing
OpenAPI specs, contract tests and a sandbox, so integrators do not need a call to get started.
The stack
What it connects to
Integration surface is the honest driver of effort — ten systems is not ten times one system.
- Payment providers and ledgers
- ERP and CRM systems
- Carrier and logistics APIs
- EMR systems over HL7 v2 and FHIR
- Message queues — Kafka, RabbitMQ, SQS
- Webhook delivery with replay
How a project runs
Contract design
3–5 days
The API surface agreed and documented before anything is built against it.
Implementation
2–6 weeks
Endpoints with auth, validation, pagination and errors that are actionable.
Integration
1–4 weeks
Third-party systems connected, with the failure paths deliberately exercised.
Hardening
1 week
Rate limiting, monitoring, replay and a documented rollback.
Where teams use it
Platforms
A public API your customers build against, which means versioning and deprecation policy from day one.
Ecommerce
Catalogue, order and fulfilment sync across storefronts and marketplaces that disagree about stock.
Finance
Payment and ledger integrations where idempotency is the difference between a bug and a refund.
Healthcare
HL7 v2 and FHIR interfaces to EMR systems, where the standard is a starting point and every site differs.
Logistics
Carrier APIs, each with its own auth, rate limits and definition of a tracking event.
When this is the wrong answer
A public API is a permanent commitment. Once customers depend on it you cannot change it freely, and versioning is cheaper to design in than to retrofit.
Integration effort scales with the number of systems and their quality, not with your feature list. A single badly documented partner API can outweigh everything else in the project.
Real-time sync is much harder than periodic sync and is often not needed. Ask what actually breaks if the data is five minutes old — frequently the answer is nothing.
Proof
Multi-tenant restaurant SaaS: 132 endpoints, 9 languages
Complete restaurant operating system — POS, kitchen displays, QR ordering, inventory, reservations, analytics — with an AI booking agent.
Frequently asked questions
REST or GraphQL?
REST for public APIs and simple resource access — it is cacheable and universally understood. GraphQL where clients need varied shapes of the same data and over-fetching is a real cost. Mixing both is legitimate and common.
Can you integrate with a system that has no API?
Often — through database access, file exchange, or as a last resort screen scraping. Each is progressively more fragile, and we will tell you where on that scale you are landing.
How do you handle a third party going down?
Retries with backoff, circuit breakers, queued writes and explicit degraded behaviour. The design question is what your product should do while the dependency is unavailable, and that is a product decision as much as a technical one.
Who owns the code?
You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.
What does it cost?
We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.
How do you version an API?
Decided before launch, because retrofitting is painful. Usually URL versioning for breaking changes with a deprecation window long enough that integrators can actually act on it.
What if the third party has no sandbox?
It happens more than you would hope. We build a recorded mock from real responses so failure paths can be exercised without waiting on someone else's test environment.
How do you stop duplicate processing?
Idempotency keys on every write path. Webhook deliveries repeat and networks retry; a payment integration without idempotency is a refund waiting to happen.
Can you document an API we already have?
Yes — generating an OpenAPI spec from the real behaviour rather than the intended behaviour, which regularly turns up endpoints nobody remembered shipping.
How do we start?
A scoping call, then a short written proposal with scope, sequence and the assumptions it rests on. If we think you should not do this, or should do a smaller version first, that is what the proposal says.
Can our team take it over afterwards?
That is the intended end state. Standard technology, decisions documented as they are made, and handover sessions with your engineers. If a system can only be maintained by us, we built it wrong.
Related
Before you choose anyone
Written to be useful whether or not you hire us — including the parts that argue against hiring an agency at all.
How to choose an AI development company
ReadAI agency vs in-house team
ReadCustom AI vs off-the-shelf
ReadOffshore vs local AI development
ReadAI Voice Agents: The Complete Guide for Businesses (2026)
ReadRAG vs Fine-Tuning: Which Does Your Business Need?
ReadHow Much Does AI Development Cost in 2026?
ReadAPI Development & Integration — tell us the scope
Tell us what you are building. We reply within one business day.