Every quote for a business system contains one line that is priced too low. It sits near the bottom, it usually reads something like "connects to your accounting system," and it regularly turns out to cost more than three visible features put together.
We have said this twice already, in our custom software cost guide and again in our ERP implementation guide: integrations are the most commonly underestimated cost in the whole project. This is the article that explains why.
It is written for someone who is not technical. You have a website, an accounting system, a CRM, perhaps a POS, and staff who copy data between them by hand. A standard integration between two systems that both publish an API starts from around AED 1,500. A complex one, involving an ERP, a legacy system, or heavy data mapping, starts from around AED 4,000. Before either number matters, there is a cheaper question worth asking first [1].
Do you need an integration at all?
There are three ways to connect business systems: a ready-made connector, a scheduled file export, or custom code, and most businesses jump straight to the expensive one. Work down this list in order.
A ready-made connector. Platforms like Zapier, Make and n8n are pre-built code that already knows how to talk to common business software. The industry name for this category is integration platform as a service: a hosted service that lets people build connections between applications without writing the connection code themselves. In plain terms: somebody already wrote the hard part, and you configure it. If both your systems are mainstream and the logic is simple, this is the answer, and it costs a monthly subscription rather than a build fee. Zapier's free tier allows one hundred tasks a month on two-step workflows [2], Make's free tier gives a thousand credits a month [3], and n8n prices on executions rather than seats [4]. Entry-level paid plans on these platforms are a small monthly subscription.
A scheduled file export. One system produces a file, somebody or something imports it into the other. Nobody puts this on a slide, but it is genuinely fine in the right conditions: low volume, no urgency, an error that would be obvious, and one person who reliably owns the task. If a day of delay costs you nothing and the file is short enough to eyeball, a weekly export is not a failure of ambition. It is a rational choice you should keep making until one of those conditions stops being true.
A built integration. Custom code, written against the systems' APIs, running on a schedule or reacting to events. This is the right answer when the volume is high, when the logic branches, when one of your systems has no ready-made connector, or when a failure needs to be caught and recovered rather than noticed by accident.
Here is the test we use in discovery. How often does the data really need to move? How many records a month? What actually happens if it is wrong for a day? Does a connector already exist for both systems? Four questions, and they usually settle it before anyone opens a code editor.
One clarification worth making early, because it causes more confused conversations than any other. When someone asks whether a system "has an API," what they usually want to know is whether a ready-made connector exists for their specific tool. Those are different questions. Almost every modern cloud system has an API. Far fewer have a connector for the exact combination you need.
What an API actually is, without the jargon
An API is a defined way for one piece of software to ask another for data, or to tell it to do something, without either side knowing how the other is built inside. Think of it as a service counter. There is a list of things you can ask for, a required way to ask, and a predictable form the answer comes back in.
Most business software uses a style called REST, which moves data through standard web requests [5]. Worth knowing: plenty of systems advertised as REST APIs are really just web APIs following looser rules [5]. It rarely matters commercially, but it explains why two systems that both claim the same thing can behave quite differently.
Then there is the question of who starts the conversation.
Polling means your system asks, on a timer, whether anything has changed. Simple to build, works everywhere, and most of those requests find nothing. The delay is baked in. On Zapier, how often that check happens depends on your plan, from every fifteen minutes on the free tier down to every minute on the top tiers [2].
Webhooks work the other way round. The source system tells yours the moment something happens. Stripe describes this as pushing real-time event data to your endpoint as events occur, sent over HTTPS as a structured message [6]. Faster, fewer wasted requests, and it only works if the source system offers webhooks and your endpoint is reliably there to receive them. If your server is down for ten minutes, you need a plan for what happens to the events sent during those ten minutes.
Most real integrations use both. Webhooks for the things that need to be immediate, polling as a safety net to catch what the webhooks missed.
Why the connection is the cheap part of an integration
Making two systems talk is often a day of work. Making them talk correctly, every time, including at three in the morning when one of them is having a bad night, is the rest of the project.
Retries and duplicates. A request times out. Did it arrive? You do not know. Retry it and you might create the same invoice twice. Do not retry it and the invoice may never exist. The fix is an idempotency key, a unique identifier attached to the request so the receiving system recognises a repeat and does not act on it twice. Stripe caches the outcome of the first request with a given key and returns that same result for any repeat, holding the key for roughly a day [7]. That one mechanism is the difference between a retry that is safe and a retry that double-charges a customer.
Backing off properly. When something fails, hammering the other system immediately makes things worse. Stripe recommends spacing retries out with increasing gaps and adding a little randomness so retries do not all arrive together [8]. Make retries certain failures on a fixed escalating schedule, starting after a minute and stretching out to multi-hour intervals, then marks the run unresolved and waits for a person [9]. Notice what that means: even the platforms with automatic retries eventually hand the problem to a human. Somebody has to be that human.
Rate limits. Every serious system caps how many requests you can send. Stripe allows one hundred requests a second in live mode, with much tighter caps on specific operations such as creating invoices on a subscription [8]. GitHub allows five thousand an hour for an authenticated user and publishes headers telling you when to try again [10]. Zoho Books allows one hundred requests a minute with daily caps that vary by plan [11]. A sync-everything-every-five-minutes design can fail purely on volume, with no bug anywhere. That has to be designed for at the start, not patched in after the first outage.
Data mapping, which is where the real work lives. Integrating a CRM with an accounting system is mostly a mapping exercise, because two systems almost never agree on what a customer is. Your CRM has a contact, a person with a phone number. Your accounting system has a customer, which might be the company that person works for. One e-commerce order might need to become two things in an ERP: an invoice and a delivery note. Deciding all of that is not a technical task. It is a series of business decisions about how your company actually works, and it is the part that needs your finance person in the room, not just your developer.
What API and system integration costs in Dubai
System integration in Dubai starts from around AED 1,500 for a standard connection between two systems, and from around AED 4,000 where an ERP or a legacy system is involved.
| Scope | What it covers | From (AED) |
|---|---|---|
| Standard integration | Two systems that both publish an API, straightforward field mapping | 1,500 |
| Complex integration | An ERP, a legacy system, heavy mapping, or custom middleware | 4,000 |
| Larger integration work | Several systems, high volume, or compliance requirements | Scoped in discovery |
A complex integration commonly runs up to around AED 12,000. Beyond that, it stops being one integration and becomes a project, and we scope it in discovery rather than quoting from a table. Final pricing depends on scope.
Be clear about what these numbers are. They are our commercial positions, set to stay consistent with what we have already published for CRM implementation, WhatsApp Business API and workflow automation. They are not a survey of the UAE market, because no credible published benchmark for integration costs in this market exists. Treat any figure you see, including ours, as a starting position that discovery either confirms or corrects.
What matters more is where an integration sits relative to everything else. A focused first version of custom software starts from around AED 15,000. A focused first phase of an ERP implementation starts from around AED 20,000. An integration is an order of magnitude smaller than either. That gap is the argument for testing whether connecting the systems you already own solves the problem, before commissioning something new to replace them.
Then there is the ongoing cost, which is the part that gets left out. If a no-code platform runs the integration, its subscription continues for as long as the integration does, and it scales with your volume [2][3][4]. If the integration is custom, there is hosting and somebody's time. Either way, a business-critical integration needs a named owner and a support arrangement. That is not an upsell. It is the difference between an integration and a liability.
Where business system integrations go wrong
It fails silently. This is the default behaviour of an integration with no deliberate error handling. The step simply does not happen and nobody is told. It is telling that both major no-code platforms built failure tracking as a headline feature [9][12], because without it, a failed run is invisible.
Nothing is logged. Once a failure has happened, you need to know what happened and when. The general principle from AWS's own operational guidance is that logging, monitoring and reporting have to be built deliberately rather than assumed [13]. Applied to integrations, that means an unlogged failure surfaces days later as a missing invoice or an order that never reached the warehouse, with no way to trace back to the cause.
Nobody owns it. An automation built by a departed employee or a previous agency, running on someone's personal account, with error alerts going to an inbox nobody reads. Zapier's automatic replay feature is only available from the Professional plan upward, and while it is actively retrying it does not send error notification emails [12]. An integration can struggle quietly for a long time even on a platform that nominally handles retries.
The other side changes. Vendors update and version their APIs; that is normal. The risk is not that change happens, it is that nobody on your side is watching for it.
The temporary export becomes permanent. The weekly file was a stopgap. It worked. It never entered a budget, so it never got replaced, and now the business runs on it.
The UAE-specific parts of system integration
E-invoicing is pushing accounting systems to connect. The UAE's e-invoicing programme is built around structured invoice data exchanged electronically through accredited service providers, explicitly not PDFs, scans or emailed documents [14]. That is a system integration requirement by definition, because it is not something a person can keep doing by hand. What applies to your business, and when, is set out by the Ministry of Finance, and their portal is the place to check rather than any second-hand summary [14].
Payment gateways are already built for this. UAE gateways publish documented integration paths at several levels of effort. Telr offers a hosted payment page, an iframe option and a direct API integration, and notes that the direct API route requires PCI DSS certification [15]. Network International runs a developer portal with a sandbox, API keys and software kits in several languages [16]. Using a licensed gateway also keeps the regulatory burden where it belongs: providing retail payment services in the UAE requires a Central Bank licence across defined categories [17], which is exactly why you integrate with a gateway rather than building payment processing yourself. Our UAE payment gateway comparison covers the fee side of that decision.
Government portals vary. Dubai Pulse publishes datasets from Dubai government and semi-government entities with web API access alongside file downloads [18]. Beyond that, authentication and documentation quality differ by entity, and some services authenticate through UAE Pass rather than the developer-style keys commercial platforms use. Check the specific portal during discovery instead of assuming it behaves like a commercial API.
Data crossing borders. The UAE Personal Data Protection Law, Federal Decree-Law No. 45 of 2021, applies to processing personal data through electronic systems inside or outside the country, and sets out requirements for cross-border transfer and sharing of personal data for processing [19]. That is a set of conditions, not a blanket ban, and not the same thing as a rule that all commercial data must sit on UAE servers. If your integration sends customer data to an overseas platform, that provision is what applies, and it is worth confirming for your specific setup. Our PDPL compliance guide covers the wider obligations, and our cloud migration guide covers hosting region choices.
Real client stories
These are real situations from integration work we have done [20].
The build that turned into a connector. A business asked us to quote for a custom sync between their online store and their accounting system. Their volume was around forty orders a week and both systems were mainstream. We set up a no-code connection instead, configured the mapping, and handed over a documented flow. It cost a fraction of the build and it does the job. Recommending the cheaper answer is sometimes the most useful thing we do.
The invoice that appeared twice. A client inherited an order sync built by a previous developer. It worked most days. On days when the accounting system was slow, it created duplicate invoices, because a timeout triggered a retry with no idempotency key. Finding the cause took an afternoon. Cleaning up months of duplicate entries took considerably longer than building it correctly would have.
The export nobody replaced. A company had been exporting a sales file every Monday for four years. It was fine for the first two. By year four, the file had grown, the person who owned it had changed twice, and a mistyped date range put a month of revenue in the wrong period. We replaced it with a scheduled integration that logs every run. The build was not expensive. The reconciliation before it was.
How SKIMBOX approaches integration
We start by asking whether you need a build at all, because a ready-made connector or a scheduled export is often the right answer and it is a much smaller bill. When a build is right, we map the data before writing code, so the disagreement about what a customer is gets settled by your team rather than guessed at by ours. We build in safe retries and logging as standard rather than as an upgrade, we design around each system's rate limits instead of finding them in production, and we hand over documentation covering where the integration runs, who holds the credentials and who gets told when it fails.
A standard integration between two systems with published APIs starts from around AED 1,500. A complex integration involving an ERP, a legacy system or heavy data mapping starts from around AED 4,000. Larger work is scoped in discovery. Final pricing depends on scope.
See our product engineering services and app development services, or contact us to talk through what you are trying to connect.
For related reading, see our guides on digital transformation for UAE SMEs, workflow automation for UAE SMEs, and CRM implementation in the UAE.
References
[1] SKIMBOX - Internal experience scoping and building system integrations for UAE businesses, 2026. skimbox.co
[2] Zapier - Pricing and plan features, including update and polling frequency by tier. zapier.com/pricing
[3] Make - Pricing and credit-based plan structure. make.com/en/pricing
[4] n8n - Pricing, execution-based plans and self-hosted deployment options. n8n.io/pricing
[5] MDN Web Docs - REST glossary entry. developer.mozilla.org/en-US/docs/Glossary/REST
[6] Stripe Docs - Webhooks overview. docs.stripe.com/webhooks
[7] Stripe Docs - Idempotent requests. docs.stripe.com/api/idempotent_requests
[8] Stripe Docs - Rate limits and recommended retry behaviour. docs.stripe.com/rate-limits
[9] Make Help Center - Automatic retry of incomplete executions. help.make.com/automatic-retry-of-incomplete-executions
[10] GitHub Docs - Rate limits for the REST API. docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
[11] Zoho Books - API v3 documentation, authentication and rate limits. zoho.com/books/api/v3/
[12] Zapier Help - Autoreplay availability, behaviour and error notification handling. help.zapier.com/hc/en-us/articles/8496037690637
[13] AWS Well-Architected - Management and Governance Guide, integrated observability. docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/integrated-observability-partners.html
[14] UAE Ministry of Finance - eInvoicing programme, the official source for UAE e-invoicing requirements. mof.gov.ae/en/about-us/initiatives/einvoicing/
[15] Telr - Integration options, including hosted payment page, iframe and direct API. telr.com/integration
[16] Network International - Developer portal, sandbox and integration options. developer.network.global
[17] Central Bank of the UAE Rulebook - Retail Payment Services and Card Schemes Regulation. rulebook.centralbank.ae/en/rulebook/retail-payment-services-and-card-schemes-regulation
[18] Dubai Pulse - Dubai's official open data and API platform. dubaipulse.gov.ae
[19] U.AE Official UAE Government Portal - Data protection laws, Federal Decree-Law No. 45 of 2021. u.ae/en/about-the-uae/digital-uae/data/data-protection-laws
[20] SKIMBOX - Internal experience from integration projects delivered for UAE businesses, 2026. skimbox.co
