API and system integration services

What an integration is for

Most businesses run five or six systems that were never designed to talk to each other: a store, a payment gateway, a courier account, an accounting package, a CRM, and WhatsApp on someone's phone. The gaps between them are filled by people. Orders are exported to a spreadsheet and keyed into Tally. Leads from the website are forwarded by email and typed into Zoho. Tracking numbers are pasted back into the store one at a time.

An integration replaces that copying with code. It reads a change in one system and writes the matching change in the other, with a record of what it did. The return is fewer typing errors, faster follow-up, and numbers that agree between systems at the end of the month.

If you want other businesses or apps to connect to your software, that is a different job: you need an API of your own. See custom API development.

The three ways to connect two systems

Pick the cheapest route that will hold up for your volume and your rules.

WavX does all three kinds of work. Setting up a vendor's connector properly is a small job: the right sync direction, matching product codes, mapping tax rates, and a test with real orders. Where the connector cannot do what the business needs, WavX builds the integration as a small service that you own. For the trade-offs between no-code tools and custom code, read Zapier vs n8n vs custom automation.

Systems WavX connects

The table lists the systems named across WavX's service pages and the guide for each on this site. It describes what WavX offers; it is not a record of past projects. WavX has not published an integration case study, so none is claimed here.

Systems not listed are not ruled out. Any system with a documented API, or a reliable export, can be connected. The first question is always what the system's own documentation allows.

What every integration WavX builds includes

The difference between an integration that works in a demo and one the accounts team can rely on is in four things. They apply whichever two systems are being joined.

1. Verified input. Incoming webhooks are checked against the sender's signature or shared secret before anything is written. A message that fails the check is logged and refused.
2. Duplicates do no harm. Vendors resend messages when they do not get a prompt reply, so the same order can arrive twice. Every record carries the source system's ID, and the integration checks for it before creating anything.
3. A scheduled check for what was missed. Webhooks can be lost. A job runs on a schedule, compares the two systems for the last day or week, and fixes or reports any difference.
4. Errors a person can read. "Product SKU TSHIRT-BLU-M has no matching stock item" on a screen your team can open, with a retry button, instead of a line in a server log.

Alongside those: a mapping screen so new products, tax rates or lead sources can be matched without a developer; API keys stored as secrets, not in the code; and a log of every exchange kept long enough to answer "did this order go across, and when?"

How an integration project runs

1. Map the data before writing code

The work starts with one real record from each side: an order and the voucher it should become, or an enquiry and the lead it should become. Each field is matched, and every case that does not match is written down: discounts, partial refunds, bundles, interstate tax, a lead with no email. Most integration problems are mapping problems, and they are cheaper to find on paper.

The project brief template has room for this. Two sample records, the list of systems and the volume per day are the most useful things to bring to a first call.

2. Confirm access and limits

Each system's API is checked for what it allows on your plan: rate limits, which objects can be written, how authentication works, whether there is a test environment. Some limits only appear on the vendor's pricing page, and some features need a higher plan. This is when the honest answer may be "the connector you already pay for can do this".

3. Build against test data

Where a vendor offers a sandbox or test mode, the integration is built there. Where it does not, testing is done with real records that are cancelled or deleted afterwards, agreed with you in advance.

4. Run in parallel

For accounting and stock, the integration runs alongside the manual process for an agreed period, and the results are compared. It takes over only when the two agree.

5. Hand over

You receive the code, the hosting account, a short document describing each data flow, and the list of vendor API versions the integration depends on. The document names who to call when a vendor announces a change, and which screen shows a failed record, so the integration does not depend on one developer's memory.

What it costs

A standalone integration is quoted after scoping. The cost depends on the number of data flows, whether they run in one direction or both, and how many exceptions the mapping has.

For planning, the software cost estimator carries third-party integrations as a ₹60,000 line item inside a larger build. A worked example from the same cost model:

The range is the cost model's spread of 15% below to 25% above the subtotal. It is a planning range, not a quote. Vendor fees (gateway charges, WhatsApp message charges, AI model usage, CRM seats) are paid to the vendor and are separate. Ongoing maintenance is budgeted at 15–25% of the build cost per year in WavX's published maintenance guide.

When not to hire anyone

• The vendor's connector already does it. If you sell on Shopify and ship every order the same way, connecting Shiprocket in its own panel costs nothing. Configure first; build only if it falls short.
• The volume is tiny. If five orders a day reach the accounts, a daily export and import by your accountant may cost less than building and maintaining an integration.
• The process itself is not settled. If the sales team has not agreed what a qualified lead is, automating the hand-off will move the confusion faster. Agree the rule first.
• A no-code connector covers it and failures are cheap. Sending a Slack message when a form is filled is a no-code job. Writing invoices into the books is not.

Related work

Integrations are part of most WavX builds: custom software and business systems, e-commerce development and Shopify integrations. When a sync has already broken, start with orders not syncing to Tally or your ERP.