Third-Party Integration Services in India
Your product depends on software you do not control. Our third party integration services in India cover the whole relationship: vendor API assessment before you commit, rate limits and quotas handled properly, outages that degrade instead of taking you down, and an exit plan for the day you switch vendors.
The Part of Your System You Do Not Own
Count the outside services your product calls. For most companies past their second year the honest answer is somewhere between fifteen and sixty, and nobody has the list. Payments, email, SMS, the CRM, the helpdesk, accounting, e-signature, calendar, storage, the identity provider, analytics, a shipping carrier or three, a KYC provider, a tax engine, an enrichment API someone added for a campaign in 2021 and never removed.
Every one of those is a piece of your system running on someone else's roadmap. They decide when the authentication scheme changes. They decide when a field becomes optional. They decide what their uptime looks like on the Tuesday your biggest customer is onboarding. You inherit all of it, and the only thing you control is how your side reacts.
This is the difference between third party integration work and the rest of engineering. Internal code fails in ways you can reproduce. A vendor integration fails because a company you have never met deployed something on a Thursday. Third party integration work is built around that fact rather than around the happy path, because the happy path takes a week and the rest takes the following three years.
What buyers describe when they first call us is rarely "we need an integration". It is closer to: the sync between our app and HubSpot has been broken since someone rotated a key and we found out from a customer. Or: our invoicing stopped because the accounting vendor retired the API version we were on and the email went to a person who left. Or: we have eleven Zapier zaps holding the business together and one of them is on the ex-marketing manager's personal account.
None of those are hard engineering problems. They are ownership problems wearing an engineering costume, and they are what this page is about.
What Third Party Integration Work Actually Covers
A scoped engagement usually has five parts. Not every project needs all five, and we would rather cut one than pad the estimate.
Discovery and the integration inventory
We find every outside call your systems make, including the ones running from a spreadsheet macro or a cron job on a box nobody logs into. Sources are your codebase, your outbound firewall or egress logs, your SaaS billing, and a short interview with each team about tools they pay for. The billing list is the one that surprises people: finance is often the only department with a true picture of how many vendors you depend on.
The output is a written register, one row per integration, with the vendor, the direction of data flow, the authentication method, where the credentials live, who owns it on the business side and who owns it in engineering. Roughly half the projects we scope change shape after this step, because the estate is bigger than anyone believed.
Vendor assessment before commitment
If you have not yet chosen the vendor, this is where the money is. Two tools that look identical in a feature comparison can differ enormously in how expensive they are to live with. We read their API documentation, their changelog, their status page history and their terms, and we write a short verdict per vendor covering the things a sales demo will not tell you.
Build
The connector itself, with retries, idempotency, signed webhook verification, structured logging and metrics from the first commit rather than after the first incident. Vendor specific code stays behind an interface your application talks to, which matters later for the same reason a plug matters more than a soldered wire.
Operational readiness
Alerting on error rate and on the specific symptom that predicts a broken integration, which is usually a sudden drop in successful calls rather than a spike in failures. Dashboards that show the last successful sync per vendor. A runbook per integration written for the person on call at 3am who has never seen this code.
Handover and the registry your team keeps
We hand over the register as a living document with the deprecation dates being tracked, the credential rotation schedule, and the owner for each row. If your team cannot add the next vendor without us, we have done the job badly.
How Do You Assess a Vendor's API Before You Commit?
Nobody regrets the vendor whose API was boring. The regret comes from the one with the beautiful marketing site and the API that pages twenty five records at a time with no cursor.
Here is what we actually check, in the order we check it, because the early items disqualify vendors fast and cost fifteen minutes.
The changelog tells you the most
Open the vendor's API changelog before the documentation. A vendor who publishes dated entries, marks things deprecated ahead of removal, and describes the migration is a vendor whose behaviour you can predict. A changelog that stops eighteen months ago, or does not exist, means every change will arrive as a surprise in your error logs. Stripe versions its API by date and lets each account stay pinned until you deliberately upgrade, which is close to the best case. Plenty of vendors do the opposite and roll everyone forward at once.
Authentication and credential lifecycle
OAuth 2.0 with refresh tokens, an API key, mutual TLS, or a signed JWT. What matters more than the scheme is the lifecycle. Do refresh tokens rotate, and does the vendor invalidate the old one immediately, which will break you if two processes refresh at once? Can you hold more than one active key so rotation does not need downtime? Are scopes granular enough to give a connector read access without handing it the ability to delete? Vendors that moved from static API keys to scoped app installs, as HubSpot did, made everyone's estate safer and everyone's migration painful.
Webhooks, or the lack of them
If a vendor has no webhooks you will be polling forever, and polling costs you rate limit budget, latency and money. If they do have webhooks, check three things: are payloads signed with a shared secret so you can verify origin, does the vendor retry on your failure and for how long, and can you replay a missed event from their dashboard or an API. A webhook you cannot replay means an hour of your downtime is permanent data loss.
Error semantics
Read the error documentation, then trigger a few real errors in the sandbox. You want distinct machine readable codes, not a 400 with a prose message that changes wording between releases. The specific thing to look for is whether you can tell a retryable failure from a permanent one. If a temporary vendor problem and an invalid customer record both return the same 500 with a generic body, your retry logic will hammer requests that were never going to succeed.
Pagination, filtering and bulk access
Cursor pagination survives a dataset changing underneath you. Offset pagination does not, and on a busy table it will silently skip or duplicate records during a long backfill. Ask whether there is an incremental filter, usually an updated-since parameter, because the alternative is re-reading everything on every sync. Ask whether a bulk export exists at all. Some vendors offer a proper bulk API and some expect you to page a million records through the same endpoint you use for one.
The status page and its history
Subscribe to it before you sign, not after. Read six months of incident history and pay attention to how the vendor writes when things go wrong. Detailed post-incident notes suggest an engineering culture that will tell you what happened. A status page that stayed green through an outage you remember tells you something too.
We write this up as one page per vendor with a verdict and the specific risks. It goes to whoever is signing, because the decision is commercial as much as technical, and because a vendor with a weaker feature set and a stronger API is often the cheaper choice over three years.
Reading a Rate Limit Policy Properly
Most teams read the number and stop. The number is the least interesting part. What you need to know is the shape of the limit, what it is scoped to, and what the vendor does when you cross it.
The shape
A fixed window resets on the clock, which means everyone hammers the API in the first second after the reset and you are competing with them. A sliding window smooths that. A leaky bucket, which Shopify uses on its REST admin API, gives you a burst capacity that drains at a steady rate, so short spikes are fine and sustained load is not. Cost-based limits are different again: Shopify's GraphQL API charges points per query, so one deeply nested query can cost more than fifty simple ones and your request count tells you nothing.
Each shape needs different client behaviour. A leaky bucket rewards a token bucket on your side that mirrors theirs. A fixed window rewards jitter so your retries do not all land on the same second.
What the limit is scoped to
This is where teams get caught. Is the limit per API key, per user, per connected account, per organisation, or global across the vendor's whole platform? If it is per connected account, adding customers scales your budget with you. If it is per app across all your customers, your two hundredth customer degrades the experience of the first one hundred and ninety nine, and you will not see it coming until it happens. Salesforce allocates API requests per org per rolling day, which behaves nothing like a per-second limit and needs planning at the month-end batch rather than at the request.
What happens at the boundary
The good vendors return 429 with a Retry-After header telling you exactly how long to wait. Honour it. Do not implement your own guess when the vendor has told you the answer. Some vendors return 429 with no header, some return a 403, and a few queue your request and return success late, which is the worst case because your timeout fires and you retry a request that was going to succeed.
Also check whether sustained abuse gets your key suspended rather than throttled. That difference decides whether a bad deploy causes a slow afternoon or a support ticket and a day of downtime.
Quotas that are commercial, not technical
Plenty of limits are billing lines dressed as engineering constraints. Monthly API call allowances, per-seat caps, extra charges above a threshold, or a lower tier that quietly excludes the endpoint you need. Get the current numbers from the vendor's pricing page and their contract rather than from a blog post, because they change, and put the growth projection next to them. An integration that works fine at your current volume and needs a plan upgrade at three times the volume is a fact your CFO should hear before launch rather than after.
On our side the standard build includes a client-side limiter set below the vendor's ceiling, exponential backoff with jitter on 429 and 5xx, a queue for anything that can be deferred, and a metric for how close to the ceiling you are running. That last one is what lets you find out you are at eighty percent of quota in a planning meeting rather than during a launch.
Sandboxes, and What to Do When There Isn't One
A good sandbox is free, self-service, seeded with realistic data, and behaves like production including the errors. Stripe's test mode is the reference point most engineers have in mind, with test card numbers that trigger specific declines on purpose.
Plenty of vendors fall short of that in ways worth knowing before you plan the work. Some give you a sandbox only on an enterprise plan, so evaluating the integration requires buying it first. Some make you request one from a partner team, with a wait measured in weeks. Some hand you an empty tenant with no seed data, which means a day of manual setup before you can test anything. Banking, insurance and logistics vendors are frequently the strictest here, and certification against their test environment can be a scheduled process with a queue.
The sandbox that lies is worse than no sandbox. If the test environment runs an older API version, or skips the fraud checks, or returns instantly where production takes four seconds, your tests pass and production surprises you. We check version parity explicitly and note it in the vendor assessment.
Working without one
When there is genuinely no usable sandbox, the options in rough order of preference are these. Record real responses once against a throwaway production account and replay them locally, which is what tools like VCR-style HTTP fixtures were built for. Write a contract test against the vendor's OpenAPI specification if they publish one, so a schema change breaks your build rather than your customers. Stand up a stub server, WireMock or Mockoon or a small service of your own, that models the endpoints you use plus the failure modes you care about. Then run a thin smoke test against real production on a dedicated low-privilege account, on a schedule, so you learn about vendor changes from your own alert rather than from a customer.
All of those are compromises. Say so in the estimate rather than pricing the work as if a sandbox existed.
Breaking Changes You Do Not Control
Every integration you own is a maintenance commitment on someone else's schedule. That is the cost line nobody puts in the original estimate, and it is why an estate of forty integrations needs a person's attention permanently rather than occasionally.
The four ways vendors change under you
A version retirement is the loudest and the easiest to plan for, assuming you saw the notice. Salesforce retires older API versions on a published schedule; if you are pinned to a version from four years ago, there is a date in the future when your integration stops. That date is knowable today.
An authentication migration is the most expensive. Moving from an API key to a scoped OAuth app, or from OAuth 1.0a to 2.0 as Xero required of its ecosystem, touches your credential storage, your consent flow, your onboarding and often your database schema. Budget weeks, not days.
A behaviour change with no version bump is the nastiest, because your version pin does not protect you. A field that used to always be present becomes nullable. A list that used to return in creation order stops. A rate limit tightens. None of these break the contract on paper and all of them break your code.
Then there is the vendor being acquired or shutting the product. You get a notice period set by them, not by you, and it may not be generous.
What we build to catch these early
Deprecation headers, where the vendor sends them, get logged and alerted on rather than discarded. A weekly scheduled job diffs the vendor's OpenAPI specification against the version you built against and raises a ticket when it moves. Response schemas are validated rather than trusted, so an unexpected null surfaces as a clear error naming the field rather than as a crash three functions later. Vendor notification emails go to a shared distribution list and a Slack channel, never to an individual, because individuals leave and their mailbox goes with them.
The register carries a deprecation column with dates. Reviewing it once a quarter is a thirty minute meeting that prevents most integration emergencies.
When the Vendor Goes Down
Your uptime is the product of every service in the request path. Chain four vendors into a synchronous checkout and you have quietly signed up to be less available than any of them individually. Most teams discover this arithmetic during their first bad quarter.
The fix starts with a decision, not with code. For every integration, we ask what should happen when it is unavailable, and we write the answer down. There are four sensible answers and picking one is the whole exercise.
Queue and retry
The user action succeeds locally, the outbound call goes on a durable queue with backoff, and delivery catches up when the vendor returns. Right for anything the user does not need an immediate answer to: CRM syncs, analytics events, most notifications.
Degrade the feature
The rest of the product keeps working and the one dependent feature is disabled with an honest message. Address autocomplete falls back to a plain text field. Enrichment is skipped and the record is flagged for backfill.
Fail clearly
Some actions must not proceed without the vendor. A payment authorisation is one. Fail fast, say which step failed, and do not leave a half-created record behind. Silent partial success is worse than a visible error.
Serve stale
Cached data with a visible timestamp beats a spinner. Exchange rates, tax tables, plan catalogues and pricing lookups usually tolerate being an hour old far better than they tolerate being absent.
Circuit breakers
After a threshold of failures the breaker opens and calls fail immediately instead of holding a worker for thirty seconds. This is what stops one struggling vendor from exhausting your connection pool and taking the whole application with it.
Timeouts you chose
Most HTTP clients default to no timeout or a very long one. Set connect and read timeouts deliberately per vendor, based on their observed latency, and make sure the total is shorter than your own request budget.
The related habit is a bulkhead. Give each vendor its own worker pool or its own queue so a slow one cannot starve the others. It costs a little more infrastructure and it converts a total outage into a single degraded feature.
One more thing worth saying because it is regularly forgotten: test the recovery, not just the failure. Plenty of systems handle a vendor going away and then fall over when it returns and six hours of queued work floods through at once. Rate limit the drain.
Should You Build It or Buy an iPaaS?
Zapier, Make, Workato, Tray, Celigo and the rest are genuinely useful, and engineers dismiss them too quickly. They are also the reason a lot of estates are held together by automations that nobody owns. Both things are true.
When the tool is the right answer
Low volume, latency tolerant, and owned by a business team who will want to change it every few weeks. A new lead in a form goes to the CRM and posts to a Slack channel. A signed contract triggers a task. A support ticket over a threshold notifies an account manager. These flows change with the business process, and routing every change through an engineering sprint is slower and more expensive than letting the operations lead edit it themselves.
The tool also wins on breadth. Zapier's connector count is a number no in-house team will match, and for a one-off connection to an obscure tool it is not worth writing an adapter you will maintain forever.
When building is the right answer
Volume, latency, or the logic being genuinely yours. If the integration is part of the product your customers pay for, it belongs in your codebase with your tests and your deploy pipeline. If it runs tens of thousands of times a day, per-task pricing turns into a bill that pays for the engineering several times over. If the transformation involves real business rules, expressing them in a visual builder produces something nobody can read in six months and nobody can unit test.
The other case for building is control of failure behaviour. Most iPaaS tools retry and then email someone. That is fine for a Slack notification and not fine for an order.
The middle option people forget
Between point-to-point code and a full platform sits a small internal integration service of your own: one place that owns outbound calls to vendors, holds the credentials, applies the rate limiting, normalises errors and publishes events for the rest of your systems. It is a modest amount of code and it changes the arithmetic. Point-to-point connections between systems grow roughly with the square of the number of systems. A hub grows linearly. Below five or six systems the hub is overhead you do not need. Above that it starts paying for itself, and the crossover usually arrives before anyone notices.
Our honest position: most mid-sized companies should run a hybrid. Business process automation in a tool, with a named owner and a company-owned account rather than someone's personal login. Product-critical and high-volume flows in code behind an internal interface. And a written rule for which is which, so the next person knows where to put the next integration.
The unit economics question to ask
Take your highest volume flow, look up the tool's per-task or per-operation pricing at your projected volume in twelve months, and compare it to the cost of building and running the equivalent. Do the same for the flow that changes most often, where the tool usually wins easily. Two calculations, an afternoon of work, and it settles an argument that otherwise runs for months.
Integration Sprawl and the Registry That Fixes It
Sprawl is not caused by bad decisions. It is caused by good decisions made one at a time by different people over four years, with no record kept. Each integration was reasonable when it was built. The estate as a whole is what nobody designed.
You can recognise it without an audit. Nobody can say how many vendors hold your customer data. A tool's renewal comes up and nobody knows what breaks if it lapses. An API key is in a config file, an environment variable, a secrets manager and one developer's laptop, and nobody knows which one production reads. A script fails and three teams each assume it belongs to another. Someone leaves and a scheduled job stops, and it takes eleven days for anyone to notice.
What goes in the registry
One row per integration. Vendor and product. What it does in one plain sentence a non-engineer understands. Direction of data flow and the specific fields that cross the boundary, which is the part your privacy review will ask for. Authentication method and where the credential lives. Business owner by name and engineering owner by team. Environments it exists in. Failure behaviour, from the four options above. Rate limit and current headroom. Contract renewal date. Any deprecation or retirement date you know about. Link to the runbook.
Keep it in version control next to the code rather than in a wiki that goes stale. A YAML file per integration, reviewed in the same pull request that changes the integration, stays accurate because it is impossible to forget. A wiki page is always six months behind.
The quarterly pass
Thirty minutes, four questions. Which integrations had zero successful calls this quarter, meaning they are dead and can be removed along with their credentials. Which are approaching a rate limit ceiling. Which have a deprecation date inside the next two quarters. Which have an owner who has left the company.
Dead integrations are worth removing rather than ignoring. Each one is a live credential with access to your data and a vendor still holding a copy of it. The clean-up is usually the fastest security win available to a team that has never done it.
Who Owns the Integration Nobody Remembers Building?
This question decides whether your estate is maintainable, and it is almost never answered until something breaks.
The usual pattern: an engineer builds a connector for a specific team's request, it works, they move to another project, and the code has no owner. It runs for two years. Then the vendor changes something, the sync stops, and the ticket bounces between platform, backend and the business team who use the data. Each has a reasonable argument that it is not theirs. The customer waits.
Two owners per integration, always
A business owner who can answer whether the data flowing is correct and who to call at the vendor, and an engineering owner who can answer why it stopped. Neither is optional. An integration with only an engineering owner is one where nobody notices wrong data. An integration with only a business owner is one where nobody can fix it.
Make failure loud enough to reach the owner
A failure that only appears in a log file is not a monitored integration. The alert that matters most is not the error spike. It is the absence of expected traffic: a sync that normally processes four hundred records overnight and processed zero. That failure is silent by nature and it is the one that costs a week of bad data before anyone notices.
Each alert needs a runbook that says what the integration does, what this alert means, the first three things to check, how to replay missed events, and who to escalate to at the vendor. Written for someone with no context, because at 3am that is who is reading it.
Where an offshore team fits
Integration maintenance is well suited to a dedicated team in India, and better suited than most work, because the trigger is often asynchronous. A vendor deprecation notice, a schema drift alert, a quarterly registry review and a backlog of small connector changes do not need you awake. A team working an Indian day can clear that queue and leave you a written summary. Incidents needing a live decision are a different matter, and we are clear about which is which rather than promising both.
Sub-Processors, Data Residency and the Contract Questions
When you send customer data to a vendor, that vendor is processing data on your behalf, and their own suppliers are processing it too. Your customers hold you responsible for the whole chain. Treat the following as questions to put to your counsel and your vendor rather than as legal advice, because the answers depend on your jurisdiction, your sector and your contracts.
Questions worth asking before you connect
Does the vendor publish a sub-processor list, and do they commit to notifying you before adding one? A vendor whose list is public and versioned is a vendor you can review. Where is the data stored and processed, and can you pick a region? Several vendors offer EU or Australian hosting on higher tiers only, which turns a compliance requirement into a pricing conversation. What is the retention period after you delete a record on your side, and is deletion propagated or only marked?
Then the practical ones. Do they have a data processing agreement they will actually sign, or only a link to a policy page? Do they support the transfer mechanism your legal team requires? Will they complete your security questionnaire, and do they hold third party attestations you can request under NDA? If your customers are in regulated sectors, does the vendor sign the sector-specific agreements those customers will demand of you?
Minimise what crosses the boundary
The engineering answer to most of this is to send less. An enrichment API rarely needs a full customer record when a domain name would do. An analytics tool rarely needs an email address when a hashed identifier works. A support tool does not need payment details. Every field you do not send is a field you never have to explain in a breach notification or a due diligence questionnaire.
Two techniques that are worth the effort. Tokenise sensitive identifiers before they leave your systems, keeping the mapping on your side. And pass a reference rather than the data itself where the vendor supports it, so they call back for what they need under your access control instead of holding a copy.
Record the field list in the registry. When a privacy review, a customer security questionnaire or a regulator asks what data goes where, the answer takes ten minutes instead of two weeks of code reading. That is the practical return on documentation nobody enjoys writing.
SSO and SCIM: The Integrations Your Buyers Demand
These two get their own section because they behave differently from every other integration on this page. They are not features your users asked for. They are gates your enterprise buyer's security team puts in front of the contract, and they are frequently the reason a deal stalls in procurement.
Single sign-on
SAML 2.0 is still the language enterprise identity teams speak, and OIDC is what most modern providers prefer. Support both if you sell upmarket. The work is not the protocol, which any decent library handles. It is everything around it: per-tenant identity provider configuration, service-provider-initiated and identity-provider-initiated flows both working, certificate rotation before expiry rather than during an outage, and an emergency access path for when the customer's identity provider is the thing that is down.
Test against more than one provider. Okta, Microsoft Entra ID, Google Workspace, OneLogin and JumpCloud each have their own defaults for attribute names and their own configuration quirks. An implementation verified against a single provider will fail on the second customer.
SCIM provisioning
SCIM 2.0 is how a customer's identity provider creates, updates and deactivates users in your product automatically. Without it, an administrator adds people by hand and, far more importantly, forgets to remove them. That is the risk their security team is actually buying protection against.
The decisions that need making before you build: what happens to a deactivated user's data and their assigned work, how group membership maps to your roles, whether just-in-time provisioning on first login is supported alongside SCIM, and what your product does when the identity provider sends a full sync that appears to remove half the users. That last one has caused real damage in real products and is worth a deliberate guard rail.
The other direction
If you are the buyer rather than the seller, the same work applies to the tools you consume. Wiring your own vendors into your identity provider means a leaver loses access to all of them at once instead of eleven of them eventually. It is unglamorous, it takes a couple of weeks across a mid-sized estate, and it removes an entire category of incident.
The Exit Plan You Write on Day One
You will replace some of these vendors. Pricing changes, an acquisition changes the product, a competitor is better, or the relationship simply stops working. The cost of that day is decided by choices made at the start, when nobody is thinking about it.
Four decisions that make switching survivable
Keep vendor code behind your own interface. Your application asks for an email to be sent, not for a particular provider's API to be called. Switching then means writing one adapter rather than finding every call site across three years of code.
Own your identifiers. Store the vendor's ID as a foreign reference, never as your primary key. Teams who used a payment provider's customer ID as their own key have paid for it in six-figure migrations, because every table that references it has to be rewritten.
Prove the export once. Not "they have an export endpoint" but an actual full export, run, inspected, and checked for the fields you thought were included. Rate limits usually apply to bulk export too, so a full extract of a large dataset can take days. Better to learn that in a planning exercise than during a notice period.
Keep your own copy of the data that matters. Not everything, and not as a shadow system. Just enough that if the vendor disappeared tomorrow you would still have the history your business runs on. For most companies that means transactions and customer records, not every log line.
What a migration actually looks like
Write the new adapter behind the same interface. Run both in parallel, writing to old and new, and compare the outputs for a period long enough to cover a month-end. Backfill history into the new vendor, expecting the rate limit to make this the slow part. Cut reads over per segment rather than all at once. Then, and this is the step teams skip, actually decommission the old integration: revoke the credentials, cancel the contract, delete the data at the vendor, and remove the row from the registry.
A vendor you stopped using but never disconnected is still holding your customer data with a live key. We have found several of those during discovery on estates that were otherwise well run.
Three Situations We See Repeatedly
Each one is a composite built from patterns we see repeatedly, not a specific client engagement.
The scale-up whose Zapier account belonged to someone who left
A company of about ninety people, growing fast, running perhaps thirty automations across two iPaaS tools. The flows were built by whoever needed them and several sat on individual accounts. When a marketing manager left, three automations stopped, and the failure was invisible for over a week because the error emails went to a deactivated mailbox.
The work is not glamorous. Inventory every automation across both tools. Move each one to a company-owned account with shared billing. Name a business owner per flow. Identify the handful that are actually product-critical and rebuild those in code with proper alerting, leaving the rest where they are because rewriting them would be waste. Then route all failure notifications to a shared channel. The outcome is not new functionality. It is that a departure no longer breaks the business.
The B2B platform stalled in a security review
A product selling into mid-market accounts, with a deal held up because the buyer's security team required SAML SSO, SCIM deprovisioning and a sub-processor list. The engineering team had never built any of it, and the sales team had already promised a date.
The sequence that works: SAML first because it unblocks the immediate deal, tested against at least two identity providers before the customer sees it. SCIM next, with the deactivation semantics agreed with product rather than assumed by engineering. In parallel, the vendor registry produces the sub-processor list and the field-level data map the questionnaire asks for. The engineering work is a few weeks. The registry is what turns future questionnaires from a scramble into a form fill, and there will be a next one.
The marketplace whose largest partner rewrote their API
A platform whose order flow depended on one large partner's API. The partner announced a new version with a fixed retirement date for the old one, and the migration was not optional. Meanwhile the existing integration had grown organically: partner field names appeared in the database schema, and their status codes had leaked into the application's own logic.
Getting out of that starts with a translation layer between the partner's model and your own, built before touching anything else, so the rest of the codebase stops caring which version is live. Then the new adapter, a parallel run comparing both against the same orders, and a segment-by-segment cutover with the ability to fall back. The real deliverable is that the next version bump from that partner, or from any other, is one adapter's worth of work instead of a company-wide project.
How We Run Integration Work From India
You are hiring a team you will mostly not be awake at the same time as. Pretending otherwise helps nobody, so here is how it actually runs.
The overlap window, honestly
Our standard day is 09:30 to 18:30 IST. Against London that gives roughly four hours of live overlap in your morning. Central European time gets about five. Sydney and Auckland overlap for most of your afternoon, which makes Australia and New Zealand the easiest timezones we work with. US Eastern is the hard one: a standard Indian day ends before your morning starts, and shifting the Indian start later buys two to three hours at best. Anything more than that needs a real second shift, which means a separate set of people, a handover ritual between them, and coordination cost you should price in rather than assume away. We agree the window with you before work starts and it goes in writing.
Written first, because the alternative does not work
Decisions live in tickets and documents, not in calls. A vendor assessment is a document you can read at your desk. An architecture choice is written up with the alternatives and why they were rejected. Standups are written and posted before your day begins, so you wake up to yesterday's progress and today's plan rather than to a question. Calls are used for the things that genuinely need discussion, and they are recorded and summarised for whoever missed them.
The practical benefit for integration work specifically: a vendor's API question often takes a day to resolve because their support responds slowly. Written handover means that day is not wasted waiting for you.
Handover at the end of the Indian day
The last thing each day is a written note covering what moved, what is blocked and on whom, and anything that needs your decision before the next Indian morning. Questions are batched into that note rather than trickling into your inbox across your night. If a decision is needed, you get it as a specific choice with a recommendation, not an open question.
Quality gates that do not depend on being in the room
Every change goes through pull request review by a second engineer. Integration code carries contract tests against recorded vendor responses so a schema drift fails the build. Nothing reaches production without the alerting and the runbook for it existing, because an integration without monitoring is a future incident with no owner. Definition of done for a connector includes the registry row, the runbook, the failure behaviour decision and the credential in your secrets manager rather than in a config file.
Access and security
Least privilege as the default. Sandbox and test credentials wherever the work allows it, production access only where it is genuinely needed and only for the named people who need it, on your identity provider and your device policy. Where you require work to happen inside your own VPN, VDI or bastion, we work that way. Access questions and any specific security, contractual or data-handling terms are settled in the agreement before work starts rather than assumed by either side.
The talent question
India's services industry has spent two decades doing systems integration for large enterprises, which means integration engineers here have seen more vendor APIs, more EDI, more identity provider quirks and more legacy connectors than the equivalent hire in a smaller market typically has. That depth is the specific reason integration work travels well to an Indian team. We screen for it directly: candidates are asked to reason about a rate limit policy, a retry that could double-charge, and a webhook that arrives twice, because those are the situations the job is made of.
Ways to Work With Us
Vendor assessment
A short engagement before you sign anything. We evaluate the shortlisted vendors' APIs against the checks above and hand you a written verdict per vendor with the risks and the likely integration effort. Useful when the commercial decision is close and the engineering reality would settle it.
Project build
A defined set of integrations, scoped after discovery, delivered with monitoring, runbooks and registry entries. Fixed scope, agreed acceptance criteria, and a handover your team can maintain. Best when you know which connections you need and want them built once, properly.
Dedicated integration team
Engineers working as part of your team on a continuing basis, owning the estate: new connectors, deprecation tracking, the quarterly registry pass and the vendor migrations. This is the right model when the number of vendors keeps growing, which for most companies it does.
Team composition, engagement length, notice and handover terms are agreed with you and set out in the agreement before any work begins. We would rather have that conversation properly than publish a number that turns out not to fit your situation.
Where This Sits Alongside Our Other Work
If the problem is connecting your own internal systems to each other rather than to outside vendors, enterprise integration covers ERP, CRM, message queues and EDI. If you are publishing an API for other people to integrate with rather than consuming one, that is API development, and the design decisions run in the opposite direction.
When the question is which integrations to build at all and in what order, a technology roadmap engagement produces the estate map and the sequence first, which is usually the cheaper order to do things in. On the build side, connector and webhook work on a JavaScript stack goes to Node.js developers in India, and data-heavy sync and backfill work is often better handled by Python developers in India.
Frequently Asked Questions
What are third party integration services?
Building and maintaining the connections between your product and the outside software you depend on: the CRM, the helpdesk, the accounting package, the e-signature tool, the identity provider, the shipping carrier. The code is usually the small part. The work that decides whether the integration survives is assessing each vendor's API before you commit, handling their rate limits and their outages, tracking their deprecations, and knowing what you would do if you had to replace them.
How do you assess a vendor's API before we commit to it?
We read the changelog first, because a vendor who publishes dated changes and honours a deprecation window behaves differently from one who ships silent changes. Then we check whether a free sandbox exists, whether webhooks are signed and replayable, whether errors are machine readable, whether pagination survives large datasets, and whether the rate limit is documented as a number rather than described as fair use. We write the findings up per vendor so the decision is on record.
Should we build integrations ourselves or use an iPaaS like Zapier or Workato?
Use a tool when the flow is low volume, tolerant of a few minutes of delay, and owned by a business team who will change it often. Build when the logic is genuinely yours, when volume or latency matters, or when the flow is part of the product your customers pay for. Most companies end up with both, and the mistake is not choosing wrongly. It is never writing down which flows live where, so nobody knows what breaks when a licence lapses.
What happens to our product when a vendor's API goes down?
That depends entirely on decisions made before the outage. We classify every integration by what should happen when it is unavailable: queue and retry, degrade to a reduced feature, fail the user action with a clear message, or serve stale cached data with a visible timestamp. Timeouts and a circuit breaker stop one slow vendor from consuming your web workers. Without that classification, a third party outage becomes your outage.
How do you stop integration sprawl?
With a registry. One record per integration covering the vendor, the business owner, the engineering owner, the credentials and where they live, the data that crosses the boundary, the failure behaviour, and the renewal or deprecation dates being tracked. It is a boring artefact and it is the single thing that separates an estate you can reason about from forty scripts nobody remembers writing. We produce it in discovery and hand it over as something your team maintains.
Do you handle SSO and SCIM user provisioning integrations?
Yes, and they are worth separating from the rest. SAML or OIDC single sign-on gets a buyer past a security review; SCIM provisioning is what stops a leaver keeping access to eleven tools. The work is mostly in the details: attribute mapping, just-in-time provisioning rules, what deprovisioning actually does to a user's data, and testing against more than one identity provider because Okta, Entra ID and Google Workspace each behave differently.
How does the timezone difference work with a team in India?
A 09:30 to 18:30 IST day overlaps the UK morning by roughly four hours, Central European time by five, and Australian eastern time for most of your afternoon. US Eastern gets very little: a shifted start in India buys two to three hours of live overlap, and anything beyond that needs a genuine second shift with the coordination cost that carries. We agree the overlap window with you up front and run written first, so progress does not stall waiting for a call.
What happens if we switch vendors later?
It costs far less if the integration was built with that possibility in mind. We keep vendor specific code behind an internal interface, store your own identifiers alongside theirs rather than depending on their IDs as primary keys, and keep an export path proven at least once rather than assumed. Switching then means writing one new adapter and running a backfill, instead of unpicking a vendor's field names from three years of application code.