Custom API Integration Services
A custom API integration is code that moves records between software your business already runs, like a CRM, an accounting tool and a store, through each product's published API and under rules written for your business. We map the fields, build the sync, and add the retries, duplicate checks and nightly reconciliation that keep both sides in agreement.
On this page
API integration services, built custom for your systems
An integration is finished when both systems agree about every record, not when the first test order goes through. So every engagement delivers the same seven pieces, whichever tools are involved.
- An integration map: every system involved, the records that move between them, and which system owns each field, so no field is ever written from both ends.
- Field mapping rules: how a CRM deal becomes an accounting invoice, including currencies, tax codes, units, custom fields and the default for a blank value.
- Connector code: the calls to each vendor's API, signed in through OAuth or keys that stay on the server.
- A sync engine: webhook receivers where a system pushes its changes, scheduled polling where it cannot, and a queue between them and the target.
- Failure handling: retries with growing waits for errors that can clear, a list of parked records for errors that cannot, and an alert to a named person.
- Reconciliation: a scheduled job that compares both systems and queues anything missing or different again.
- A runbook, then support or handover: how to replay a failed record, rotate a key or pause a sync, written for whoever runs it next.
The connections this work usually means
- Leads into the CRM: website forms, chat and booking tools creating contacts and deals in HubSpot, Salesforce or a CRM built for you.
- Store to back office: orders, stock and refunds moving between a Shopify or WooCommerce store and an ERP or warehouse system.
- Payments to accounting: payouts, fees and refunds from a payment provider matched to invoices in QuickBooks Online or Xero.
- Orders to shipping: labels, tracking numbers and delivery status passed between the order system and a shipping platform such as ShipStation.
- Transactional email: order confirmations, proofs and receipts sent through an email provider when a record changes.
- Ad platforms: enquiries reported back to ad accounts as conversions, server to server, so campaigns are judged on real leads.
The buyers are usually operations leads whose staff type orders from one screen into another, finance teams matching payouts to invoices by hand at month end, and SaaS teams whose customers want a connection to the CRM they already use. Regulated data changes the design, for healthcare records and for fintech payment flows alike.
Integration or a new API: which one you need
Each product you use publishes an API, a list of requests it will answer. An integration uses two or more of those APIs to keep records in step. A typical one: a deal marked won in the CRM creates the customer and an invoice in the accounting tool, and the payment that clears a week later marks the deal paid.
Custom means the rules are yours: which deals count, which tax code applies, what happens when the customer already exists under a slightly different name. A marketplace connector handles the common case the same way for everyone. A custom integration handles your case, including the custom fields a connector never maps.
Building an API is a different job. If partners or your own apps need to call your system, that is the work on our custom API development page. This page covers connecting systems that already exist and already publish APIs.
When one side has no API at all, as with many older in-house systems, there are three ways in: a read-only account on its database, files exchanged on a schedule, or a small API placed in front of it first. The choice depends on how fresh the data must be and who is allowed to touch the old system.
Five examples most businesses end up needing
- A website form or chat that creates a contact and a deal in the CRM, tagged with the page the visitor came from.
- A paid online order that becomes a sales receipt or an invoice in QuickBooks Online or Xero.
- A shipped order that pulls the tracking number back from the carrier and emails it to the customer.
- A payout from the payment provider, split into sales, fees and refunds and matched to the bank deposit.
- A new hire entered once in the HR system, which opens the accounts they need on day one.
What the other system speaks
- REST and JSON: HubSpot, QuickBooks Online, Xero and ShipStation, all in the vendor table below, take REST calls, so most integrations start here.
- GraphQL: Shopify has called its REST Admin API legacy since 1 October 2024 and requires new public apps to use its GraphQL Admin API from 1 April 2025, so a new store connector queries GraphQL.
- SOAP and XML: still the interface of many older ERP, payroll and finance products, and slower to map than JSON.
- Files: a CSV export dropped on an SFTP server each night, or EDI documents traded with large retail and logistics partners. Each file needs parsing, a check that it arrived whole, and a record that it was already loaded.
Five ways to connect two systems, and when each fits
Almost every integration uses one of five patterns, and the cheapest one that holds up under your volume is the right one. Custom code is not always the answer, and discovery with us can end in advice to switch on a connector instead.
| Pattern | How it works | Fits when | Stops fitting when | Who keeps it running |
|---|---|---|---|---|
| Marketplace connector | An app the vendor or a partner publishes, switched on in settings | Both tools are mainstream and the connector already maps the fields you use | You need a custom field, a rule of your own, or a fix the publisher will not schedule | The publisher; you can change only its settings |
| iPaaS: Zapier, Make or Workato | A hosted workflow: a trigger in one app runs action steps in others | Volume is modest, the mapping is simple, and someone in operations will own the workflows | The usage bill climbs with volume, the logic needs code and tests, or a failed run must be retried and reconciled rather than emailed | Your team, inside the vendor's platform |
| Direct code | A small service you own calls both APIs, started by a webhook or a schedule | Two or three systems, rules that need real code, or volume a per-step bill would punish | Many systems each talk to many others, so every new tool adds several links | Your developers or ours, in your repository |
| Middleware hub | One service every system connects to once; it holds the mappings, queue, logs and retries | Four or more systems, or one record that passes through several of them | There is a single pair of systems, where a hub only adds moving parts | Your developers or ours, in your repository |
| Shared database | Two applications you own read and write the same tables, so nothing is copied | Both applications are yours and run on one database | Either side is a vendor product you cannot change | Whoever owns both applications |
The links add up faster than people expect. Five systems wired straight to each other can need ten separate connections, each with its own credentials and its own ways to fail; through a hub they need five. That arithmetic, more than taste, is what moves a growing company from direct code to middleware.
How the three iPaaS tools bill
- Zapier counts a task each time an action step succeeds; triggers, filters and steps that error or halt are not counted, according to Zapier's help centre.
- Make bills in credits, and most module actions use one. Its pricing page says scenarios stop when a plan's credits run out, with incoming webhooks queued up to the plan's storage; the free plan has 1,000 credits a month.
- Workato publishes no list price. Its pricing page sells editions by quote, with a usage charge measured by capability and more than 1,200 prebuilt connectors.
Any of the three can be right. A workflow copying a few hundred form entries a month into a CRM rarely justifies code. These are the signs a workflow has outgrown its tool:
- Staff correct records by hand after runs the tool reported as successful.
- The same record arrives twice, and nobody can say which copy is right.
- The monthly task or credit bill grows faster than the business does.
- Renaming one field breaks a workflow nobody remembers building.
- An auditor asks who changed a record, and the run history no longer goes back that far.
Sync that survives retries, duplicates and outages
The vendors say it themselves: an event can arrive twice, out of order, or not at all. Stripe's documentation says so for payment events and Shopify's for store events. An integration that will be trusted with invoices is designed around those three failures from its first line of code, and the four habits below are how.
Webhooks for speed, polling as the backstop
A webhook pushes a change the moment it happens; polling asks on a schedule. Use webhooks where they exist, but never webhooks alone. Shopify retries a failed delivery up to eight times in four hours, expects an answer within five seconds, and removes the subscription if failures persist. Its best practices tell apps to run reconciliation jobs rather than rely on webhooks.
Where a system has no webhooks, poll for what changed since the last successful run. QuickBooks Online's change data capture call returns changes from the last 30 days, at most 1,000 objects per response, so a sync that stalls for a month cannot simply catch up.
Write once, however often the event arrives
Stripe advises logging the IDs of events already processed and skipping repeats. Its API also takes an idempotency key on every POST, so a retried request cannot create a second object; Stripe may prune a key once it is 24 hours old. Where the target offers no such key, write by the source record's ID, so a second delivery updates the record it already made.
Retry what can recover, park what cannot
- Timeouts, 429 and 5xx responses: retry with a wait that grows each time. QuickBooks Online asks callers to wait 60 seconds after a 429.
- 401 and 403: a key is wrong or revoked, and waiting will not fix it, so alert a person at once.
- Any other 4xx: the request itself is wrong, so park the record with its error code and fix the mapping.
- Out of order: Stripe and Shopify both say events can arrive in any order. Shopify sends the trigger time in a header; Stripe warns against ordering events by their creation time and points to its API for the current object.
Reconcile every night
A scheduled job compares both sides: counts and totals for the day first, then record by record for anything that changed. Missing or different records go back on the queue, and a short report says what was fixed. This is the check that finds the webhook that never came.
the webhook makes it fast, the duplicate check makes it safe to repeat, and the nightly comparison catches whatever the first three steps missed
For the hands-on side, three free tools on this site help: the UUID generator makes random idempotency keys, the timestamp converter reads the Unix times webhooks carry, and JSON diff shows exactly where two copies of one record disagree.
What seven common APIs allow, in their own words
Each vendor caps how fast you may call it and decides how it reports changes, and those limits shape an integration more than the language it is written in. We read the figures below from each vendor's documentation on 17 October 2026. They change, so a build checks them again during discovery.
| System | What its documentation says | What it means for the build |
|---|---|---|
| HubSpot (CRM) | Privately distributed apps: 100 requests per 10 seconds on Free and Starter, 190 on Professional and Enterprise; 250,000, 625,000 or 1,000,000 a day per account | The daily allowance is shared by every privately distributed app in the account, so a bulk import can starve the live sync |
| Salesforce (CRM) | Each API version is supported for at least three years, with at least a year's notice before it ends; versions 21.0 to 30.0 were retired in Summer '25, and REST calls to a retired version return 410 | Pin the version you build against, and treat each retirement notice like a renewal date |
| QuickBooks Online (accounting) | 500 requests a minute per company and 10 a second per company and app; after a 429, wait 60 seconds; query responses stop at 1,000 entities | Page through long lists, and keep an outage short, because change data capture looks back only 30 days |
| Xero (accounting) | Per connected organisation: 5 calls at once, 60 a minute and 5,000 a day; 10,000 a minute across the whole app; a 429 past either limit | Batch writes, and spread scheduled jobs across organisations rather than firing them at midnight together |
| Shopify (store) | Failed webhooks are retried up to eight times in four hours; an answer is expected within five seconds; apps are told not to rely on receiving every webhook, and order is not guaranteed | Answer fast, queue the work, skip repeated webhook IDs, and reconcile on a schedule |
| Stripe (payments) | Live events are retried for up to three days; the same event can arrive more than once and out of order; return a 2xx before any slow work | Log event IDs, fetch the current object, and send an idempotency key with every write |
| ShipStation (shipping) | 40 requests a minute per API key and secret, with headers giving the limit, the calls left and the seconds until it resets | Queue label and tracking calls, and never make one inside a checkout request |
Vendors can also charge for the calls themselves. On the same QuickBooks page, Intuit says apps in the Builder tier of its App Partner Program include 500,000 CorePlus API calls per workspace a month, with calls beyond that throttled. Ask about access fees and partner programmes before you commit to a design that polls every few minutes.
Integrations from our own work, and how each one fails safely
No outcome figures have been published for these builds, so none appear here. For our own systems we can show how each one handles the failures described above, read from the code itself. For a client build we name the parts and leave out how they are wired.
Our website, our ERP and an ad platform
The live chat on digitalheroesco.com feeds the ERP our team works from, and nothing is copied between them. Both run on one PostgreSQL database on Supabase, so a visitor's message is written straight into the tables the ERP's CRM inbox reads. Shared tables have one blind spot: nothing tells the ERP's AI copilot a row arrived, so the site makes a server call, authenticated with a shared secret, that wakes it.
A booking on our call booking page fans out three ways: an email to our team and a confirmation to the person booking, both sent through Resend, and a booking event in the analytics table behind the ERP's website report.
When an enquiry should count as an ad conversion, the site reports it to the ad platform's conversions API through an outbox, a table of pending deliveries, rather than a direct call, so an outage at the platform can never fail the enquiry:
- The conversion ID is claimed with a conditional database write, so a double click still yields one ID, and a unique index refuses a second delivery row for the same ad account.
- Each delivery gets five attempts, with waits that start at one minute and double up to a six hour cap; a job every 30 minutes sends whatever is due.
- Timeouts, 429s and server errors are retried. A rejected key or a malformed request is marked failed at once, because waiting will not fix either.
- Retries stop short of the platform's seven day limit on event age, rather than resending with a fresh timestamp that would misreport when the enquiry happened.
- One account with a missing key cannot hold up the other, and a visitor who withdraws consent has their pending deliveries cancelled.
SpeedyPrint, a print store in South Africa
We built SpeedyPrint for a South African client on Next.js 15, React, TypeScript and Supabase. Shoppers design their print in the browser or send a CSV file for a variable data print job, and every order carries its proofs, production files and status history, run from an admin panel with three roles. Two connections reach outside that stack: PayFast checkout with webhooks, and transactional email.
On Clutch, our profile shows 5.0 from 66 verified reviews (checked 13 October 2026).
This page names only integrations we can show in code: PayFast, Resend, Supabase, an ad platform's conversions API and our own ERP. Store work on Shopify runs through our Shopify practice, as a Shopify Select Partner, and is described on our Shopify app development page. For any other vendor in the table above, the build starts from that vendor's documentation, read during discovery.
What an integration costs to build and to keep
The published figures we found all come from companies that sell integration platforms, so read them as benchmarks with a motive. Merge, which sells a unified API, puts one API integration at $50,000 to $150,000 a year once engineering time, support time and partnership fees are counted. Its worked example assumes 150 hours to build and 300 hours a year to maintain, which with support tickets comes to nearly $50,000 for one integration.
Ampersand, another integration platform vendor, puts a mid-complexity build such as Salesforce or HubSpot at 150 to 250 engineering hours, with Workday and Epic at 400 or more. It argues the build is about 30 percent of an integration's lifetime work, and suggests 300 engineering hours a year per connector as a floor for upkeep.
To turn hours into money, the US Bureau of Labor Statistics puts the median software developer wage at $135,980 in May 2025. By our arithmetic that is about $65 an hour before benefits and overhead, so 150 to 250 hours of building is roughly $9,800 to $16,300 of salary alone, and 300 hours of yearly upkeep about $19,600.
The pattern changes the shape of the bill more than its size. An iPaaS charges for tasks or credits every month, so cost follows volume; code you own costs more up front and then mostly hours. Vendor charges sit on top of either, as the QuickBooks call allowance above shows.
We do not publish integration prices. A first conversation costs nothing and lasts 30 minutes, the written scope and quote arrive within 48 hours, and the build gets a fixed price after two weeks of discovery, billed as its own small engagement. For a rough number before that, our free integration cost calculator adds up build hours for each system you tick and multiplies them by a rate you choose.
What pushes an integration toward the expensive end
- A system with no webhooks, which needs scheduled polling and a record of where the last run stopped.
- Custom objects and fields on either side, each needing its own mapping and transformation.
- Two-way sync, where both systems can edit the same field and a conflict rule has to decide.
- Years of history to backfill before the live sync can start.
- Tight vendor limits, such as Xero's 5,000 calls a day per organisation.
- Regulated data: health records under a Business Associate Agreement, or card data kept off your servers.
- An older system reached through SOAP, file drops or its database rather than a modern API.
Six steps from a list of systems to a sync you can trust
Work that falls outside the written scope is priced and dated as a separate change request first, never added quietly to the bill.
- A call, then a written scope. Thirty minutes on which systems are involved, which records move and roughly how many a day. We book calls at least five days ahead, which gives us time to read your documents first, and you have the scope and quote within 48 hours.
- Discovery, two weeks. A map of each system the integration touches, down to which one owns each field, and a risk register naming how it can fail. Its outcome is either a fixed price or a recommendation to switch on a connector that already does the job.
- Architecture sign-off. Our CTO approves the design, including the pattern from the table above, before any engineer starts.
- Build. Work runs in one or two week sprints. A recorded demo of working code closes every week, with a short note of what went out and what slipped.
- Test and release. Our QA team checks each build before you are shown it, a rollback is rehearsed before the first release, and a larger system goes live in modules rather than all at once.
- Run it, or hand it over. A named team for integrations and incident support after launch, or a handover pack of runbooks, architecture notes and a walkthrough for your own team.
Integration builds are designed and code reviewed under our CTO, Divyansh Singh, who also leads the work behind this site's live chat. The engineering team is in Delhi and Lucknow, while our New York headquarters replies within the business day, between nine and six Eastern time.
A sync can fail at any hour, so the cover outside those hours matters as much as the build. Outside them, Delhi and Sydney cover production emergencies around the clock, and someone picks up an after-hours message within one to two hours.
Who holds the keys, the code and the data
An integration holds credentials to several of your systems at once, which makes it a tempting target. Two controls go into the ones we build:
- Keys stay on the server: vendor keys and tokens are held on the server, and no browser ever receives them.
- Logs keep codes, not payloads: our ad conversion outbox stores an error code rather than the vendor's response, because an error body can echo back the personal data that was sent.
Ask any builder for two more. Every webhook receiver should confirm the sender before it acts, by signature and, where the vendor publishes its server addresses, by source address too. And each vendor key should be requested with only the scopes the sync needs, read-only wherever the integration only reads.
Ownership is settled in the contract. Under our MSA, code written for your project is assigned to you once it is paid for in full, and it lives in repositories and cloud accounts that you own and pay for. The CRM, accounting and payment accounts were yours to begin with, so every key the integration uses can be revoked by you.
Health data adds paperwork before code. If the records include protected health information, we put a Business Associate Agreement in place for that work, run the integration on AWS, Azure or Google Cloud under the cloud provider's BAA, and can point to an independent firm's review of our HIPAA practices. The field map should then carry only the fields the workflow needs.
Seven questions to ask any integration vendor
Put the same seven to every firm or freelancer on your list. A vague answer to the second or third is the most expensive kind, because it surfaces as a wrong invoice months after launch.
- Which system owns each field, and what happens when both sides change it on the same day?
- What does your code do when the same webhook arrives twice?
- How will we find a record that never synced?
- Which errors do you retry, how many times, and who hears about it when the retries run out?
- How will you learn that a vendor is retiring the API version we depend on?
- Whose account does the workflow or service run in, and who can rotate its keys?
- If we stop working together, what do we need to run it ourselves?
Our answers to the first four are under sync design, the fifth under vendor limits, and the last two under keys and ownership. When a sync runs on a schedule, our free cron expression helper spells out in plain English when it will next run.
Questions buyers ask before connecting their systems
What are custom API integrations?
They are connections built for one business between two or more software products, using each product's API, so records move between them under that business's own rules. A deal won in the CRM can create the customer and invoice in QuickBooks Online, mapped to your tax codes, products and custom fields, which a ready-made connector usually cannot do. The plain words section has more examples.
How much do API integrations cost?
Benchmarks vary widely, and both main sources sell integration platforms. Ampersand puts a mid-complexity build at 150 to 250 engineering hours; Merge puts the full yearly cost of one integration at $50,000 to $150,000 once upkeep, support and partner fees are counted. Upkeep often costs more than the build. The cost section turns those hours into salary using federal wage data.
What are examples of API integrations?
Common ones include a website form that creates a contact and a deal in the CRM, a paid store order that becomes an invoice in QuickBooks Online or Xero, and a carrier's tracking number sent back to the order and emailed to the customer. Others match payment payouts to bank deposits, or open a new hire's accounts in every tool from one HR record.
What are some popular API integration companies?
They fall into three groups. iPaaS vendors such as Zapier, Make, Workato and MuleSoft sell platforms your own team builds workflows on. Unified API vendors such as Merge sell one API that covers many tools of one kind. Services firms, ourselves included, build and run integrations for you in code you own. Which fits depends on your volume and how custom your rules are.
How long does a custom API integration take?
For one pair of mainstream systems, plan in weeks rather than months. Ampersand's 150 to 250 engineering hours for a Salesforce or HubSpot build is about four to six weeks of one engineer working 40 hours a week. With us, the first two weeks are discovery, after which work runs in one or two week sprints, with a recorded demo of working code at the end of the first. Each extra system, custom object or backfill adds time.
Should an integration use webhooks or a scheduled sync?
Both. Webhooks bring a change within seconds, but vendors say deliveries can fail or arrive twice: Shopify retries a failed one up to eight times over four hours and can then drop the subscription. A scheduled job that asks for changes since the last run, plus a nightly reconciliation, catches what the webhooks miss. Where a system offers no webhooks, the schedule is the only route.
What is the difference between API integration and middleware?
An API integration is the connection itself: code that calls two systems' APIs and moves records between them. Middleware is a layer in the middle that many integrations share, holding the mappings, queue, logs and retries in one place. Two systems rarely need it. Four or more usually gain from it, because each system then connects once instead of to every other.
When is a no-code tool like Zapier enough?
When volume is modest, the mapping is one field to one field, and a missed or doubled record is an annoyance rather than a wrong invoice. Zapier bills each successful action and Make bills credits for module actions, so the cost follows your volume. Move to code when staff fix records by hand after runs, or when the monthly bill grows faster than the business.
What happens when a connected system changes its API?
The integration breaks unless someone is watching. Salesforce, for example, supports each API version for at least three years and gives at least a year's notice, and REST calls to a retired version fail with a 410 error. Pin the version you build against, track each vendor's retirement notices, and budget for upkeep every year. After launch, a named team of ours can do that watching for you.
Who owns the integration code and the vendor keys?
You do. Under our MSA the code written for your project becomes yours on full payment, and it lives in repositories and cloud accounts registered to you and billed to you. The keys are issued from your own CRM, accounting and payment accounts, so you can revoke any of them at any time, and you can remove our engineers' access whenever you like.
Last reviewed .
List the systems you use, and we will map the sync
Tell us which tools are involved, which records should move between them, and roughly how many a day. Thirty minutes on a call is enough for us to send a written scope and a quote within 48 hours; the fixed price follows discovery. Book a call with an integration engineer.
Why work with Digital Heroes
115 people in New York, Delhi, Lucknow, London and Sydney, shipping ecommerce, web, software and mobile work for founder-led brands. Senior engineers only, no account-manager relay, and the same team from kickoff to launch.
- Shopify Select Partner, as listed in the Shopify Partner Directory
- Tier 1 registered supplier on the United Nations Global Marketplace, which requires audited company documentation
- Top Rated Plus on Upwork, the bracket for the top 3% of talent by client outcomes
- 397 public five-star-weighted reviews across four Fiverr gigs, from clients in 36 countries
- DUNS verified business, No. 650878346, so procurement can check us before signing
- Listed by Clutch in Top 1000 Global B2B Companies and Top Web Designers 2024
- Verified profiles on GoodFirms, DesignRush, Digital.com, AppFutura and TopDevelopers
- 2,000+ brands built across 40+ countries, with $50M+ in client revenue scaled
More from Divyansh.
Chief Technology Officer · Lucknow · 50 posts on the site
Published .
