API development and integration

What this actually solves

Somewhere in the business there is a person who moves data by hand. A lead arrives through the website form and they open the CRM and type it in again. An order lands in the store and they open the accounting software and type it in again. Nobody planned that job. It accumulated one system at a time, and it now costs hours every month plus a steady trickle of transposed digits in phone numbers and order totals — the kind of error nobody reports, because the person who made it is also the person who would have to admit it.

The other version of this request is the mirror image. You hold data that other people want to reach, and every request for it currently ends with somebody exporting a spreadsheet. What is needed is a documented way in, with keys, limits, and clear rules about what a caller may and may not see.

Both are the same discipline, and in both the code that moves a record from A to B is the easy part. Usually it is an afternoon. The difficulty is everything wrapped around it: what happens when the receiving system is unreachable for ten minutes, what happens when the same webhook is delivered twice, what a field is called on each side, and how anyone finds out six weeks later that the whole thing quietly stopped.

An integration that works only while both systems are healthy is not finished — it is a demo. What you are paying for here is the behaviour on the bad day.

What we do, and in what order

1. Read both sides' documentation in full, and confirm what it does not say. Not skim — read. Authentication method (API key, OAuth, bearer token), rate limits, pagination rules, which fields are genuinely required, and what the system returns when you send it something it dislikes. Anything the documentation does not answer gets asked before a line is written, because the alternative is guessing, and guessed endpoints are written with enormous confidence and are wrong. One to three days, longer when the far side is undocumented.
2. Map the fields and settle the rules that are yours, not ours. customer_name on one side is firstName and lastName on the other; a phone number optional here is mandatory there. The map gets written down and shown to you, and with it the decision that matters most — what should happen when a record already exists. Updating the existing contact and creating a second one are both defensible, and they produce very different CRMs a year from now. One to two days.
3. Write the failure behaviour before the happy path. Every integration carries the same three things: retry with a backoff, a durable record of whatever failed, and an alert so a human hears about it the same day. If the destination cannot be reached, the incoming record is stored on your side first and replayed later. It is never dropped because a third party was unavailable. Two to five days.
4. Build it, then test against real conditions without damaging real data. Requests exercised by hand in Postman or Insomnia first, so we know what the far side actually returns rather than what its documentation claims. Webhooks tested through ngrok or localtunnel, so the remote system can genuinely reach the machine the code is running on. Duplicate deliveries fired deliberately, to prove the same event arriving twice does not produce two customers. One to three weeks depending on how many endpoints are in scope.
5. Switch on logging and monitoring, then hand over. Integrations break silently. Nothing turns red; the leads simply stop arriving, and the discovery happens a month later when someone wonders why the pipeline looks thin. You get a log you can read yourself, an alert the moment the failure count leaves zero, and a short document naming every endpoint, every credential, and where each one lives. Two to three days.

What moves the price

The range is $1,500–$12,000 and where a job lands inside it is decided by three things.

How clean the other system is. This is the largest single factor, which is why the first question we ask is whether you can show us the other system's documentation. A modern, well-documented REST API with a maintained SDK can be a two-day connection. An older internal system with no documentation, whose original developer has left and whose current owner replies to email once a week, can absorb three weeks before any code is useful.

Whether data travels one way or both. One direction is a pipe. Two directions is a negotiation about which system is authoritative when the same record has been edited in both places since the last sync — a question with no sensible default, and one that has to be answered by you rather than by us.

Volume, and how fast it arrives. A contact form firing a few times a day needs very little. A system pushing thousands of records against a published rate limit needs queuing, batching and back-off, and those stop being refinements and start being the build.

What usually goes wrong

Only the happy path is written. The demo runs, everyone is delighted, the invoice is paid. Two weeks later the destination is unavailable for ten minutes, seven leads vanish without trace, and nobody notices until a customer rings to ask why nobody called back. This is the defining failure of integration work, and it is completely preventable — retry, record, alert, decided at the design stage rather than during the incident.

Duplicates are treated as an edge case. Webhook providers deliver more than once by design, and a timeout on your side does not mean the far side failed. Without an idempotency rule — usually a unique key on email address or order number — a redelivered event becomes a second contact. A CRM that quietly doubles its own records is worse than one that never received them, because now somebody has to work out which copy is true.

Credentials and limits are discovered in production. A token turns out to be scoped read-only on launch day. A sandbox rate limit that felt generous is a fraction of the live one. An OAuth token expires after ninety days and nobody built the refresh, so the integration works beautifully for a quarter and then stops. All three belong in step one, alongside the documentation, not in the first week of live traffic.