The short answer
API development is building the interface your own software exposes, so another system can read and write your data safely. API integration is the other direction: connecting your system to somebody else's, usually a payment provider, a CRM, an accounting package, a courier, a booking channel or an ERP. Most of that work is REST, because nearly every provider ships a REST API and a usable client library. GraphQL earns its place when several different front ends need different slices of the same data. Webhooks handle the events you cannot sit and poll for, like a payment settling at two in the morning.
We do both, and we keep them alive afterwards. A custom API layer with the integrations built around it typically lands , quoted fixed before any code is written, on a 50/25/25 payment plan. A single integration bolted onto a system that already works is a slice of that, not the whole figure. And the honest part, which most quotes leave out: your code is rarely what fails. The third party is the risk, and most of the engineering described below exists to absorb their outages, their rate limits and their version changes without your business noticing.
The third party is the risk, not your code
Every broken integration we have been called in to rescue was broken by something outside the client's building. A provider halved a rate limit and told nobody. A sandbox that never returned the error the live system returns, so the first real failure was also the first time anyone had seen it. A webhook delivered twice, hours apart, because the first response timed out after the order had already been created. A v1 endpoint marked deprecated in a changelog nobody had subscribed to, then switched off on a Tuesday.
You cannot prevent any of that. You can only build so it does not take your business down with it. Most of the engineering on a serious integration is not the happy path at all, it is what happens on the unhappy one.
An integration is not finished when the first call succeeds. It is finished when it survives the provider's next bad day.
This is also why integration work is recurring rather than one and done. Providers ship changes on their own schedule, not yours. Somebody has to be watching when they do, and that is a support arrangement, not a heroic weekend.
What we build, and what is included
- REST APIs with versioned routes, one consistent error shape and real HTTP status codes, not a 200 with the word failed buried in the body.
- GraphQL where multiple clients genuinely need different shapes of the same data, with query depth and cost limits so one careless client cannot flatten the server.
- Webhook receivers with signature verification, replay protection and an idempotency key on every write, so a duplicate delivery does not create a duplicate order or a second charge.
- Outbound webhooks for your own customers and partners, with signed payloads, a published retry schedule and a delivery log they can inspect themselves.
- Authentication that fits the provider: OAuth 2.0, API keys or signed requests, with credentials in a secret store rather than committed into the repository.
- Documentation your next developer can use: an OpenAPI or GraphQL schema, a working Postman collection and a short written guide, handed over as part of the build rather than sold back to you later.
- A staging environment pointed at the provider's sandbox, so nobody is testing against live money or live customers.
The integrations we handle most often are payments, accounting, CRM, logistics, booking channels and internal ERP. Payment work has its own page if that is your case: payment gateway integration. If the API you need does not exist yet because the system it should sit on has not been built, that is custom software development first and integration second, and we will say so rather than quote you an API for a system that is not there.
Retries, rate limits and versioning: the parts that decide whether it holds
Retries, backoff and a dead letter queue
Failed calls retry with exponential backoff and jitter, capped, and anything that still will not go through lands in a dead letter queue a human can inspect and replay. A provider outage becomes a queue that drains when they come back, not a morning of lost orders nobody can reconstruct.
Idempotency, so nothing happens twice
Every write carries an idempotency key. Send the same request twice, through a retry or a duplicate webhook, and it takes effect once. This single detail is the difference between a resilient integration and one that quietly double charges customers whenever the network hiccups.
Rate limits honoured, not discovered
We honour Retry-After, keep our own token bucket on this side of the wire, and queue rather than hammer. Where the provider supports batching or bulk endpoints we use them, because the cheapest way to stay inside a limit is to make fewer calls.
Versioning and change monitoring
We pin the provider's API version explicitly rather than riding whatever is current, subscribe to their changelog, and version our own API so adding a field never breaks your existing clients. Inside a version, changes are additive only.
Then the part that gets skipped everywhere: we alert on silence as well as on errors. An integration that has stopped receiving webhooks entirely looks perfectly healthy on a dashboard that only counts failures, and that is exactly how a business goes three weeks without noticing.
What API development and integration cost
Two things set the price before we write a line: how many systems are talking, and how good the other side's documentation is. A provider with a clean OpenAPI spec, a working sandbox and honest error codes can halve an estimate. A provider with a PDF from 2019 and a support email address pushes it the other way. So we read the docs before quoting, not after.
| Type of work | Price | What moves it |
|---|---|---|
| One provider integrated into a system that already works | A slice of the build, not a full project | Number of endpoints, sandbox quality, one direction or two |
| Custom API layer plus the integrations around it | Systems involved, data volume, auth model, reconciliation rules | |
| Rescuing an integration somebody else left broken | Quoted after we read the existing code | How much is salvageable, whether the provider has since moved version |
| Ongoing monitoring, retries and version upkeep | a month | Number of live integrations, alert response expected, how often the provider ships |
Why this sits below a London or New York agency quoting identical scope: our operating costs are lower where the work is done, not our standards. Same frameworks, same code review, same test suite, same queueing and rate limit handling any competent team would write. The real comparison most buyers are making is a Western agency at three to five times this, or a marketplace freelancer who is cheaper and gone by the time the provider ships v2. We are the third option, affordable and still reachable in month nine when the API changes. If you are weighing that up properly, read freelancer versus agency.
Fixed quote before work starts, on a 50/25/25 plan: half to begin, a quarter at review, a quarter on handover. 29 live builds behind us.
How we work
- We read their documentation first. Before the quote, not after it. We check whether the sandbox actually works, whether errors are documented and whether the endpoints you need exist at all. Occasionally this ends with us telling you the integration you want is not possible as described.
- We map the data flow on one page. What moves, in which direction, how often, what the system of record is when the two sides disagree, and what should happen on failure. Most integration disputes are really disagreements about that last question, settled too late.
- We build against the sandbox, on staging. Your live data and live customers are not a test environment.
- We run in parallel before we switch. Where the provider allows it, the new integration runs alongside the old process and we compare outputs for a period before anything is turned off.
- We hand over the keys and the docs. Credentials are yours, in your accounts. Schema, Postman collection and a short runbook come with the build.
- We stay on for the changes. Monitoring, alerts on silence, and version upkeep as a monthly arrangement, because the provider is not finished shipping.
If the work is larger than one integration and you need people on it consistently rather than a single project, hiring a development team is usually the cheaper structure.
How to choose an integration developer
Almost anyone can make the first successful API call. Judge candidates on the failure cases instead, because that is where your money actually goes. Four questions worth asking before you sign anything.
- What happens if the provider returns a 500 halfway through a batch? You want to hear about queues, retries and where the failed items go. Vagueness here is the whole answer.
- How do you stop a duplicate webhook creating a duplicate record? If idempotency does not come up unprompted, they have not run an integration that mattered.
- Who holds the API keys and where do they live? Correct answer: your accounts, a secret store, rotatable without a developer.
- What happens in month seven, when v2 lands? Somebody has to be watching, and you need to know who and on what terms before the deprecation email arrives.
Then decide honestly what you are optimising for. Cheapest per hour usually costs most per year, because the person who wrote the integration is unreachable when it breaks. The middle path is a team with lower operating costs and the same engineering discipline, which is the argument behind outsourcing software development to Africa rather than choosing between an expensive agency and a disappearing freelancer.
Frequently asked questions
How much do API development and integration services cost?
A custom API layer with the integrations built around it typically lands . A single integration added to a system that already works is a slice of that rather than the full figure, and ongoing monitoring and version upkeep run as a monthly retainer. We read the provider's documentation before quoting, because the quality of their sandbox and docs moves the price more than anything on our side. Every project is a fixed quote before work starts, on a 50/25/25 payment plan.
Can you integrate with a system your team did not build?
Yes, and most of our integration work is exactly that. We read the existing code and the provider's documentation first, tell you what is salvageable and what is not, then quote fixed. We also take on rescue work where a previous developer left an integration half finished or broken by a version change.
What happens when the third party changes their API?
We pin their version explicitly rather than riding whatever is current, subscribe to their changelog, and alert on silence as well as on errors so an integration that quietly stops delivering gets noticed the same day. When a breaking change is announced we schedule the migration before the deprecation date. This is what the monthly support arrangement covers, and it is the reason integration work is recurring rather than one and done.
Should we use REST or GraphQL?
REST for most cases, because nearly every provider speaks it, caching is simpler and your next developer will already know it. GraphQL is worth it when several different clients need different shapes of the same data and you are tired of building a new endpoint for each one, but it needs query depth and cost limits or a single client can overload the server. We recommend based on how many consumers your API will actually have, not on fashion.
How long does an integration take?
A single well documented provider, one direction, into a system that already works is usually a matter of days to a couple of weeks. A two way sync between two systems, with reconciliation rules for when they disagree, is measured in weeks. The provider's sandbox quality changes that estimate more than the code does, which is why we read their documentation before giving you a timeline.