Start a Project
AEO & GEO

Custom API Integration Services: A Practical Setup Guide

19 min read
Adam Khaled

Adam Khaled

Founder, Web25

Custom API Integration Services: A Practical Setup Guide

Quick answer: Custom API integration services connect your website, store or business software through their APIs, so data moves between them without retyping. A provider plans the data flow, builds and secures the connection, tests it, and watches it after launch. You only need custom work when a ready-made connector or automation tool cannot cover your process.

Key takeaways

  • An API is the door one program offers to another, and an integration is the work of making two programs use those doors to share data.
  • Use the cheapest option that covers your real workflow: a built-in plugin, an automation tool, a prebuilt connector, and only then custom code.
  • Decide which system owns each field before anyone writes code, because most sync bugs start there.
  • A good integration is safe to retry, logged, tested without live data, and watched after launch.
  • Budget for the time after launch, because the systems on both sides keep changing.

Table of contents

If your website, store, CRM and accounting software each keep their own copy of your data, someone on your team is probably moving it between them by hand. This guide explains what custom API integration services include, when a cheaper option is enough, how a good integration is built, and what to ask before you hire anyone.

What do custom API integration services include?

Custom API integration services are the work of planning, building, securing, testing and looking after a connection between two or more systems when no ready-made connection fits. An API (application programming interface) is the set of rules a program offers so other programs can read or change its data. You may also see this work sold as API development and integration services.

The result is that an order placed in your store can reach your accounting software, or a lead from your website can reach your CRM, without anyone retyping it. The table shows what the work usually covers.

Custom API integration services flow: a source system sends data through an integration layer with queue, retries and logs to a target system
StageWhat happensWhat you should get
Discovery and data mapThe provider lists the systems, the data that moves and the system that owns each fieldA written map of every flow
BuildCode is written that reads from one API and writes to another, with rules for errorsA working connection and its code
SecurityAccess is limited to what the sync needs, and secrets are stored outside the codeCredentials in your own accounts
TestingThe connection is tried in a sandbox and in a dry run before it touches live recordsTest results you can read
Monitoring and fixesAlerts, logs and a scheduled check run after launchSomeone who is told when it fails

Do you need a custom integration or is a ready-made one enough?

Most businesses do not need custom code for their first integration. Start with the simplest option that covers your real workflow, and move up only when it stops fitting.

OptionBest forWatch out for
Built-in plugin or app from your platformCommon pairs, such as a store and a popular accounting toolFixed behavior, and flows that stop at the edge of what the plugin supports
Automation tool, such as Zapier, Make or Pabbly ConnectLight flows, for example a form entry creating a CRM contactPlan limits that grow with volume, and limited control over errors
Prebuilt connector, such as Celigo’s NetSuite app for ShopifyStandard flows between well-known systemsA subscription, and limits when your process is unusual
Custom integrationUnusual rules, software without a connector, or full control over errors and logsBuild and maintenance cost, so it needs documentation and tests

If you only need a form entry to land in a spreadsheet or CRM, an automation tool is the right answer, and paying for custom code would waste money. Custom work starts to pay off when one of these is true:

  • Your process has custom fields, approval steps or several warehouses that a standard flow ignores.
  • One of your systems has no ready-made connector, or only exposes old formats such as XML.
  • Your volume is high enough that request limits need careful scheduling.
  • You need your own logs, alerts and rules for what happens when a record fails.

What can a custom API integration connect?

A custom API integration can connect any two systems that expose some way to exchange data, and the jobs fall into a few common groups. Each group has its own typical data and its own traps.

Integration jobData that usually moves
Online store and ERPOrders, customers, stock levels, fulfillments
Online store and accounting softwareInvoices, payments, tax, refunds
Website and CRMLeads, contacts, deal status
Payment gatewayPayments, refunds, payment status
Website and internal softwareBookings, customer records, availability
Older desktop softwareStock and orders through files or XML

For a worked example of the first row, read our Shopify NetSuite integration guide, or the Odoo WooCommerce integration guide if your store runs on WooCommerce, or the Xero WooCommerce integration guide if your books are in Xero. For a WooCommerce store with NetSuite behind it, read the NetSuite WooCommerce integration guide. If your ERP is Microsoft Dynamics 365, read the Dynamics 365 ecommerce integration guide. For the last row, see the Mirael3D POHODA case study. Our backend and API service page covers the rest.

How do you set up a custom API integration in 8 steps?

To set up a custom API integration, define what must sync, give each field one owner, study the API limits, map the data, secure access, build with safeguards against duplicates and failures, test without live data, and go live with monitoring. The steps below follow that order.

Step 1: Define the job and the finish line

Write down which event starts each sync and what a correct result looks like. For example, an order placed in the store appears in accounting once, with the right customer and totals. If you cannot describe the finish line in one sentence, the project is not ready to build.

Step 2: Give every field one owner

Decide which system is the source of truth for each type of data. When two systems can both change the same field, they will eventually disagree, and one will overwrite the other. A single owner for each field prevents that.

Step 3: Read the API documentation and limits

Before designing anything, check how the other system handles logins, versions, request limits (often called rate limits) and a test environment. When you send too many requests, a server may answer with an HTTP 429 status, and MDN notes that it may include a Retry-After header telling you how long to wait. Your code needs to respect that.

Step 4: Map the data

List how a record in one system becomes a record in the other, matching items by a stable key such as a SKU and never by name. Map tax, currencies, statuses and locations too. This is the slowest step and the one most often rushed, so mistakes here show up later as records in the wrong place.

Step 5: Secure access

Use OAuth 2.0 where the other system supports it. The OAuth 2.0 standard lets an application obtain limited access to a service. Give the integration only the permissions it needs, and keep secrets in protected settings, not in the code.

Check who can reach which record, too. OWASP’s 2023 list of API security risks puts broken object level authorization first, which means an API that lets one customer’s request touch another customer’s data.

Step 6: Build with safeguards

Make every write safe to repeat. Stripe’s documentation explains that an idempotency key lets you retry a request after a connection error without performing the same operation twice. The same idea works in any integration: store the other system’s record number, and skip anything that already exists. Payments are where a duplicate write costs real money, so see our guide to payment gateway API integration.

Do not rely on webhooks alone. Shopify’s documentation says webhook delivery is not always guaranteed and recommends reconciliation jobs that periodically fetch data to catch what was missed. Add a scheduled job that compares both systems and reports any difference.

Step 7: Test without live data, then do a dry run

Test in a sandbox where one exists. Then connect to the live system with writes switched off, and read the logs line by line to see what the integration would have done. Only after that, switch writes on.

Step 8: Go live with monitoring

Set alerts for failed records, name one person who receives them, and write down what to do when one arrives. Watch the first week closely. An integration that touches money or stock needs an owner after launch, not only before it.

What did a real integration teach us?

Web25 built a custom WooCommerce and POHODA integration for Mirael3D, a store selling 3D-printing filament. POHODA is accounting software popular in Slovakia and Czechia, so this is a different pair of systems from most stores, but the lessons carry over. The full Mirael3D POHODA case study has the details.

  • Test examples did not match real traffic. Simplified examples did not match the XML the client’s real installation sent, so the team started validating every generated document against the software vendor’s published schema before each deployment.
  • A stock field meant something different from its name. The first version trusted a stock field that looked like “available”, but it did not subtract orders that had been received and not yet processed. The website sold the last unit and a stock push then restored the old quantity, so the item was oversold. The fix calculates sellable stock from the raw physical quantity minus committed orders, and never goes below zero.
  • Dry run came before live. Writes were off until the final log had been checked line by line, and the full audit of 129 matched products found no stock discrepancies.
  • Risky actions stayed behind a switch. Cancelled orders were handled through an off, log-only or live setting, and products with no match went to a draft queue instead of being published.

This is one project on one pair of systems. Treat it as an example of method. Your systems will behave differently.

What does a custom API integration cost?

Custom API integration services have no honest single price, because the cost depends on a few factors you can list before you ask anyone for a quote. A standard flow between two documented systems is a small job. Several flows, unusual rules and old software make it a larger one.

FactorPushes the cost up when
Number of flowsYou sync orders, stock, invoices, refunds and customers, not just one of them
Quality of the APIDocumentation is thin, the API is old, or only files and XML are available
Custom rulesThere are approval steps, custom fields or several locations
VolumeHigh traffic needs queues and careful scheduling around request limits
Test environmentNo sandbox exists, so extra care is needed to protect live records
MonitoringYou want alerts, logs and someone who fixes issues after launch

Ask for any quote to be split into discovery, build, testing and monitoring, so you can compare offers on equal terms. Budget for the time after launch as well. Integrations are one of the cost drivers in our guide to how much a website costs, and our guide to website maintenance packages explains how ongoing care is usually priced.

How do you choose an integration provider?

Choose a provider of custom API integration services who can explain how the integration fails and recovers. The questions below help you find that person.

AskA good answer sounds like
Could a ready-made connector do this?A direct yes or no, with reasons. A provider who never says “use a connector” may be selling code you do not need.
Who owns the code and the credentials?You do, and you get repository access and documentation.
How will you test without risking live data?A sandbox where possible, then a dry run with writes switched off.
What happens when a record fails?It is logged, retried safely, and reported to a named person.
What happens when the other system changes its API?A plan for watching version changes and a price for updating.
Can I see a similar project?A real case study with the limits of the result stated honestly.

What breaks an integration after launch?

Most breakage after launch comes from change on either side, not from the original build. These are the changes to plan for.

  • API version changes. Shopify, for example, releases a new API version every three months, and supports each stable version for a minimum of 12 months. An integration pinned to one version needs a review at least once a year.
  • Expiring or revoked access. OAuth access tokens can expire or be revoked, so the integration needs a way to renew them and an alert when it cannot.
  • Changed fields. A new required field or a renamed status in either system can stop a sync without any error on your website.
  • Growth. A sync that is fine at ten orders a day can hit request limits at a few hundred, so check the numbers when your volume changes.

How Web25 helps

Web25 is our agency. This guide covers it alongside alternatives.

If a plugin, automation tool or connector covers your flows, we will tell you to use it. If your process is unusual, Web25 builds custom integrations between websites, online stores and accounting or business software, and keeps them monitored afterward. Our backend and API service page explains how we work, and the Shopify NetSuite integration guide walks through one pairing in detail.

FAQ

A REST API gives you fixed addresses, one per type of record, and each address returns a set shape of data. A GraphQL API lets you ask for exactly the fields you want in one request. On Shopify the choice is made for you, because its documentation says new public apps must be built exclusively with the GraphQL Admin API.

Often yes. Some older programs exchange data through files or their own formats instead, and POHODA, the accounting program in our case study, trades stock and order data with internet stores through XML documents sent over HTTP. A good provider reads the vendor's documentation first and builds around what the software really supports.

Middleware is the code that sits between two systems and translates and routes data. It receives a request from one side, checks it, converts it to the format the other side expects, and passes it on. In the Mirael3D project, a custom WordPress plugin played this role between POHODA and WooCommerce.

It depends on how many data flows you need and how well the other system's API is documented. In the Mirael3D project, the connector was built in isolation on 20 and 21 August 2026, ran in dry-run mode from 25 August, and went live on 30 August. Refinements continued until 6 September, and that is one project, so use it as a reference point only.

That should be agreed in writing before work starts. Ask for access to the code repository, the documentation and every credential the integration uses, so you can move to another developer later without rebuilding. Credentials should belong to your accounts, not to the provider's.

Not if it is built properly. Well-built integrations run in the background, using a queue, so a visitor never waits for another system to answer. A poorly built one that calls an outside system while the page loads can slow checkout, so ask where in the process each call happens.

Yes, if it is designed for it from the start. In the Mirael3D project, shop-specific rules sit in a configuration layer, which prepares the same connector for future sister storefronts. Adding a store then means adding settings, not writing a new integration.

What to do next

List the systems you want to connect and the data that should move between them, then check whether a plugin or connector already covers that list. If it does not, or you want a second opinion before you choose, book a discovery call.


Written by Adam Khaled, Founder, Web25. Last updated October 2026.

More from the blog

Custom API Integration Services: A Practical Setup Guide | Web25 Blog