Web Development
API Development & Integration
The happy path takes a day. Everything after that is the reason integrations are quoted in weeks.
API work covers building APIs for others to consume and integrating with systems you do not control. The Nexclick designs for the failure cases first — rate limits, timeouts, partial responses, breaking changes — because integrations break at the other end and rarely give notice.
Is this you?
What usually prompts the call
- Two systems you rely on do not talk, so someone retypes data between them daily.
- An integration was built once and silently stopped working when the other side updated.
- You need to give a partner or a customer programmatic access to your data.
- Your team maintains a spreadsheet that exists only to move data between two tools.
What we do
The actual deliverables
Things that appear on an invoice, not adjectives.
- Map the data and the ownership
- Which system is authoritative for each field, and what happens when they disagree. Integrations fail on this question far more often than on technical grounds.
- Design for failure first
- Rate limits, timeouts, partial responses, duplicate deliveries and outages. The happy path is quick; the failure paths are what the estimate is actually for.
- Build the integration
- With retries, idempotency and dead-letter handling, so a transient failure does not silently lose a record.
- Reconciliation, not just synchronisation
- A way to detect and resolve drift between two systems. Any long-running integration will drift, and one with no reconciliation drifts invisibly.
- API design where you are the provider
- Versioning, authentication, rate limiting, pagination and documentation. An API without versioning is a promise you will break.
- Monitoring and alerting
- Failures surfaced within minutes. The worst integration failure is the silent one that nobody notices for a fortnight.
- Documentation for both sides
- What it does, what it assumes, and what to check when it breaks. Written for whoever is on call, not for whoever built it.
Comparison
The failure modes that decide an integration quote
Each of these is why integrations cost weeks rather than days. If a quote does not account for them, it is pricing the happy path and the rest will arrive as change requests.
| Failure mode | What happens without handling | What handling costs |
|---|---|---|
| Rate limiting | Requests rejected under load; records silently lost | Queue and backoff — a day or two |
| Timeouts | Half-completed operations, inconsistent state | Idempotency keys and retries |
| Duplicate webhook delivery | The same order processed twice | Deduplication on a stable identifier |
| Partial responses | Records created with missing fields | Validation before write, with a rejection queue |
| The other system is down | Data lost during the outage window | Persistent queue with replay |
| Breaking API change | Integration stops without notice | Version pinning plus monitoring |
| Field format change | Silent corruption rather than an error | Schema validation on every payload |
| Conflicting edits on both sides | One system quietly overwrites the other | A defined ownership rule per field |
| Records deleted at one end | Orphans accumulate at the other | Soft deletes and reconciliation |
| Gradual drift | The two systems disagree and nobody notices | Scheduled reconciliation with reporting |
| Authentication expiry | Integration stops overnight | Token refresh plus expiry alerting |
How it works
Step by step, with timeframes
Timeframes are typical rather than guaranteed, and they assume we get account access and approvals when we ask.
- 01Week 1–2
Map and specify
Data flows, ownership, volumes and failure modes. Includes reading the other system’s documentation properly, which frequently reveals the real constraint.
- 02Week 2–3
Prototype against the real endpoint
Against a sandbox or the live system with test data. Documentation and reality diverge often enough that this stage is not optional.
- 03Week 3–7
Build and handle failures
Integration built with retries, idempotency and reconciliation. Failure handling is typically the larger share of the work.
- 04Week 7–8
Monitor and hand over
Alerting configured, documentation written, and a period of supervised running before it is left alone.
What you get
Reporting and ownership
- A data map naming which system owns each field and what happens on conflict.
- Failure handling documented — retries, idempotency, what happens to a rejected record.
- A reconciliation method, so drift is detectable rather than silent.
- Monitoring that alerts on failures within minutes rather than at month end.
- Documentation written for whoever is on call, not for whoever built it.
Tools and platforms
- Node.js, Laravel or Next.js API routes
- REST and GraphQL
- Webhook infrastructure with retry queues
- Postman / Insomnia
- OpenAPI documentation
- Sentry or equivalent monitoring
Timeline
How long this actually takes
Six to eight weeks for a substantial integration, and the variable is almost always the system at the other end rather than ours. A modern documented API is quick. An older system with a nightly file export, no sandbox and inconsistent documentation can take twice as long. One thing worth saying before you commission anything: integrations are not build-and-forget. The other side will change their API, deprecate a version or alter a field, usually with limited notice. Budget for maintenance, because an unmaintained integration is a data-loss incident waiting for a release note.
Pricing model
Fixed-price project
Fixed price after a short scoping engagement, since the other system determines the effort. Ongoing monitoring and maintenance sits within a support retainer.
Questions
API Development & Integration questions
Why does a simple integration take weeks?
Because the simple part is a day. Rate limits, retries, duplicate deliveries, partial data and reconciliation are the rest, and skipping them produces an integration that works in testing and loses records in production. A quote that assumes only the happy path will be revised later.
Can we use Zapier or Make instead?
Often, and it is genuinely cheaper. Automation platforms handle standard connections between common tools well. Custom work earns its cost at higher volumes, where the logic is complex, or where reliability genuinely matters — a no-code automation quietly failing is harder to detect.
What happens when the other system changes their API?
The integration breaks, usually without warning. Version pinning delays it and monitoring detects it quickly. This is the main reason integrations need ongoing maintenance rather than being finished — an unmaintained one is a data-loss incident waiting for someone else’s release note.
Should we build an API for our own product?
If partners or customers genuinely need programmatic access, yes. If it is aspirational — building an API because it seems like something a product should have — the cost of versioning, documentation and support outlives the enthusiasm. Build it when someone specific is waiting for it.
How do you handle systems with no API at all?
File exchange, database access where permitted, or occasionally screen automation as a last resort. All are more fragile than an API and we will say so. Sometimes the honest recommendation is to change the system rather than build an integration around one that cannot support it.
Who owns the data mapping decisions?
You do, and we will insist you make them explicitly. Which system is authoritative for a customer’s address is a business decision, not a technical one, and integrations that fudge it produce disputes about which record is correct six months later.
Last reviewed 28 July 2026.
Tell us what you are trying to fix
A 20-minute call, no pitch deck. The Nexclick will tell you what we would do, roughly what it costs, and whether we are the right people for it.