Who Owns the Integration After It Ships?

Key takeaways

• Breaking changes usually arrive unflagged. Across 1,368 public RESTful APIs, 87.3% of the versions that introduced a breaking change carried no deprecation notice in the specification before them²

• The worst failures never announce themselves, and whether yours does was decided at build time. The same upstream change is an afternoon’s work in an integration built to retry and raise an alarm, and a month-end crisis in one that was not

• An integration is an iceberg and you can buy the tip on its own. The cheaper quote is usually the same integration with the failure handling removed, and the cost moved off the invoice and onto your operations

• The answer to the title is both of you. Your partner watches it and answers when it complains. You hold the code, the credentials, and the ability to see what it is doing without asking anyone

• Match the engineering to the consequence. Anything touching money, inventory or customers needs real ownership. A weekly report that two people read does not, and a supplier who quotes the same for both has skipped the thinking

On 18 August 2026, Google shut down the Content API for Shopping. It had announced the deprecation exactly a year earlier and offered a migration path to the Merchant API.¹ For any business whose product feed still ran through the old endpoint, the calls started coming back as errors. No email, no warning banner in the admin, no phone call. The listings simply stopped updating.

Some of those businesses found out that morning. Others found out weeks later, when someone asked why the ad spend was flat and the sales were not. The upstream event was identical for both groups. What differed was whether their integration had been built to notice, and whether anyone was on the other end of the alert when it did.

Ownership is the thing almost nobody settles before launch, and it is the thing that decides how a morning like that one goes. Get it right and a bad day stays a bad day. Get it wrong and a small failure becomes an expensive month. Most of what decides which way it goes was settled long before the thing ever went live.

The day it stops working is not the day it breaks

Most businesses buy an integration the way they buy a filing cabinet: pay once and stop thinking about it. An integration is closer to a delivery van. Nobody is surprised that a van needs servicing, and nobody believes the cheapest one with no service history is the bargain. What you pay up front is only ever part of what it costs to run.

It is harder than the van in two ways. An integration is less a thing you own than a conversation between two systems you do not control, both of which are being rewritten by other people on a schedule nobody told you about. And unlike a van, it makes no noise when something goes wrong.

The build is the visible part, and it is the part the quote is based on. What comes afterwards is harder to price, because it varies so much. Plenty of integrations need almost no attention for years, where one stable system talks to another and the design already handles the predictable problems by itself. Others want looking at every few months, usually because they touch several systems at once, or because one of those systems is being actively rewritten by its vendor.

Why integrations decay: API breaking changes and business drift

Nothing has to go wrong internally for an integration to stop working. Four things erode it from the outside, and they operate continuously.

The platforms underneath you keep moving

Google gave a year of notice on the Content API and then turned it off. Shopify releases a new API version every three months and supports each one for a minimum of twelve months. Both are well-behaved cases, run by large companies with formal deprecation policies and public timelines. Plenty of the systems in a typical stack have neither.

The two of them fail in opposite ways, and the gentler one is the more dangerous. Google’s shutdown is loud. The call comes back as an error, nothing works, and you are in no doubt that something has happened. Shopify does not reject a request to a version it has retired. It moves you forward instead, answering with the oldest version it still supports, which is by definition a newer one than your integration asked for. Your integration carries on receiving perfectly valid responses, so nothing looks broken anywhere. It is simply holding a conversation with a different version of the platform than the one it was written for, and the differences show up as quietly wrong data, with no error anywhere to point at them.

That is the more expensive of the two, and it is worth being clear about why. A platform that breaks you outright has at least told you. A platform that helpfully moves you onto newer behaviour without being asked has handed you the job of noticing, and most businesses notice through a customer complaint or a month-end reconciliation that will not balance.

Most of them will not tell you first

Google and Shopify are the considerate end of the market. The rest of your stack is unlikely to behave that way, and there is research on exactly this. A 2020 study of 2,224 API versions drawn from 1,368 public RESTful APIs took the versions that introduced a breaking change and asked whether the version before them had flagged it coming. Only 12.7% had. The other 87.3% broke something with nothing in the specification to warn you.²

A changelog post or an email may still have gone out, and the better vendors send both. What was missing in seven cases out of eight was the warning in a form the integration itself could have acted on. Choosing a big, well-supported vendor buys you better documentation and a longer notice period. It does not buy you a system that stops changing, and it does nothing for the smaller tools in the chain that will simply alter a field one Tuesday and leave you to work it out.

Your own business changes shape

You add a sales channel. You start selling bundles. Finance introduces a new tax code, or someone creates a product category the integration was never told about. The integration keeps doing exactly what it was built to do, which is now the wrong thing. We saw this with a music retailer whose fulfilment ran on automation rules that had been stretched years past what rules can handle. Nothing had broken. The business had simply moved, and the logic had not moved with it.

The people who understood it leave

The developer who built it, the ops manager who knew which errors were safe to ignore, the person who remembered why that one field gets mapped backwards. When they go, the integration becomes a black box that everyone is afraid to touch and nobody can explain. This is the failure mode that turns a two-hour fix into a two-week investigation.

The same failure, and why only one of them is silent

None of the above is avoidable. Every integration ever built will meet a change it was not designed for. What is very much a choice is what happens next, and that choice was made by whoever built it, long before the change arrived.

Take an ordinary event. An upstream platform starts rejecting a call, because a field became required, a rate limit tightened, or a timeout got shorter. Nothing dramatic, and sooner or later every integration meets something like it.

In an integration built to the lowest quote, the call fails and that is the end of it. There is no retry, so a temporary problem becomes a permanent one. There is no error log, so no record exists of what was lost. There is no alert, so nobody is told. The order, the invoice or the stock update is simply gone, and the first sign of trouble arrives at month end when the numbers do not reconcile. At that point the work is forensic. Somebody has to establish what went missing, reconstruct it from whichever system still has it, and work out how far back the problem goes, all while the integration keeps failing in the same way.

In an integration built properly, the same failed call is retried a few times with a widening gap, which quietly resolves most transient problems without anyone knowing. If it still fails, the affected record is parked in a holding queue where you can see it, and an alert fires within the hour. The rest of the data keeps flowing, so the failure stays contained to the records it actually touched. When someone fixes the cause, that holding queue is the list of exactly what to replay. Nothing has to be reconstructed, because nothing was lost.

Identical upstream event. One version is an afternoon of work with no customer ever noticing. The other is a month-end crisis with several days of investigation behind it and a stretch of unreliable data in the middle.

This is also the real distinction between a proper integration and a chain of low-code automations. A missed webhook in a system with retry logic and alerting is an incident that mostly resolves itself. The same missed webhook in a Zapier chain is an order that never existed. We covered the specific points where low-code automation stops coping in more detail.

Cheap to build, expensive to own: the real cost of an integration

When two quotes for the same integration are far apart, the difference is almost never the happy path. Both will move an ordinary order from A to B on the day of the demo.

An integration is an iceberg. Above the waterline sits that happy path: an order arrives, it appears in the other system, everyone nods. Below sits retry logic for the calls that fail for a moment, queues so a record that cannot be processed waits somewhere safe instead of vanishing, logging good enough to answer what happened last Tuesday, monitoring that raises the alarm unprompted, documentation, and a fallback somebody has actually tested. None of it shows on a good day, and most of the engineering is down there.

You can buy the tip on its own. It will demo exactly as well as the whole thing, because on a good day the two are indistinguishable. The bill for the missing nine tenths arrives later, in a form that rarely gets traced back to the original decision.

It arrives as diagnosis time, and it arrives every time. A system that records what it did and shouts when it fails can be diagnosed in minutes, because the answer is already written down. A system that records nothing has to be investigated from the outside by someone comparing two databases and forming a theory. The first is a support ticket. The second is a small project, started from scratch on each occasion.

It arrives as the cost of running broken. An integration that was saving your team five hours a week stops, and because nothing raises an alarm nobody looks for a cause. People see only the symptom, orders not arriving where they should, and start keying them in by hand. Six weeks of that is 30 hours, roughly $1,050 at a $35 loaded hourly rate, and that is salaried time and nothing else. It excludes the bad data that piled up while it ran and the work of unpicking it, along with whatever the errors cost at the customer end. The reconciliation afterwards is where the real time goes, and we have written separately about how much monthly reconciliation actually costs.

And eventually it arrives as a rebuild. A cheap integration nobody can diagnose gets patched, not fixed, because patching is what you can afford in the middle of an incident. Each patch adds a special case the next person will not understand, until you have a system nobody wants to touch and a quote to replace it that rivals the original build.

The cheaper quote is not usually a cheaper integration. It is the same integration with the failure handling removed and the cost moved off the invoice and onto your operations, where nobody is counting it. Total cost of ownership is the only number that matters here, and it is settled by what got built rather than by what got quoted.

Which runs in both directions, and that is worth saying plainly. A high price is no evidence of any of this. Part of the gap between two quotes is engineering, and part of it can be brand, account management, office overhead and a margin somebody has decided the market will bear. Overpaying for a happy path is entirely possible, and it is harder to spot than underpaying, because a large invoice implies substance. The test does not change: ask what the extra money buys you in the hour after something fails. If the answer is specific, you are buying engineering. If it is logos and process, you are buying somebody else’s overhead. That question should be aimed at us as readily as at anyone else, and our answer is on the about page: a small senior team without the overhead of a tech hub, so more of what you pay ends up in the engineering.

So who owns it? Both of you

Ask most businesses who is responsible for keeping an integration running and you get one of three answers, none of them good.

“The agency who built it.” Sometimes true, usually not. Unless there is a support agreement that says so in writing, the relationship ended at handover. They may well fix it, but they will do so when they have capacity and at whatever their current rate is. Goodwill is not a maintenance plan.

“Our developer.” If you have one in-house, they are almost certainly working on something with a roadmap and a deadline attached. Integration maintenance is unplanned, unglamorous work that arrives without warning. It gets deprioritised until it becomes an emergency, at which point it displaces everything.

“Nobody, really.” The honest answer, and the most common one. The integration works, so it is invisible, and it stays invisible right up until it is the most urgent thing in the business.

The problem with all three is that they treat ownership as a single thing to be handed to one party. It works better split, because the two halves need different things. Recovery speed depends on familiarity, and nobody knows the system like whoever built it. Control depends on independence, and you should never be in a position where one supplier is the only route to your own operations.

Get either half wrong and it shows. Owning the code while nobody watches it is how businesses discover a six-week outage at month end. Being watched by a supplier who will not show you the internals is quieter and slower, and it costs more to escape.

Here is the split in practical terms. None of it requires you to read code.

The half your partner is on the hook for

• Automated monitoring, so the integration reports what it did and raises the alarm by itself when the numbers fall outside a normal range.
• A named person on the other end of that alarm, with a response time agreed in advance and written into the support agreement. Not a shared inbox, and not a dashboard someone opens when they remember.
• Watching the platforms upstream, so deprecations get handled during the notice period and not on the morning they take effect. Google gave twelve months of warning on the Content API, which only helped the businesses where somebody was reading it.
• Speaking up when it no longer fits. Monitoring catches an integration failing, but nothing catches an integration succeeding at something you have stopped wanting. That takes a person who knows the system and the business, looking at it periodically and saying when a rule has gone stale.

The half that stays in your hands

• The code and the credentials. The repository is yours, and the credentials sit in a password vault your business controls, holding only the permissions the integration needs.
• A written record of what it does, covering which systems it touches, what the business rules are, which failures are safe to ignore, and what happens manually while it is down. This is the artefact that saves you when the person who built it moves on.
• Visibility on demand, so you can check the state of your own operations without asking anyone’s permission.

The two halves hold each other up. Your partner is close enough to catch things early, and you are independent enough that catching things early never becomes leverage.

Three kinds of supplier

Suppliers divide fairly cleanly into three groups on this, and you can usually tell which one you are dealing with before you have signed anything.

They deliver and run

The build completes, the invoice clears, and the relationship evaporates. There is no support agreement, so the first failure is a cold start for everyone. This is the honest version of the problem, and at least you know where you stand.

They deliver and lock you out

More expensive, and much harder to see coming, because on the surface everything is fine. Someone is looking after it. The catch is that they are the only ones who can, and every year that passes makes leaving harder.

The warning signs are practical, not technical, and you can check most of them in an afternoon:

• The code lives in their repository, not yours, or you have never been told where it lives
• The integration runs on their hosting, under their account, on their cloud bill
• API credentials for your systems were created by them and are held by them
• There is no documentation you could hand to another developer
• You have no way of seeing whether it ran today without asking them
• Questions about how it works get answered in reassurance instead of detail

Any one of these might be a reasonable convenience. Together they describe a system you are renting access to, and the price of that arrangement only becomes visible when you want to change something, question an invoice, or leave.

They build it so you could leave

The difference shows on day one, not at the first incident. A supplier in this group builds the integration so that it could be handed to somebody else at any point, and then earns the right to keep looking after it. Nothing about the arrangement depends on you being unable to go.

Our own terms sit on the services page instead of three pages into a contract: the code committed to your repository, the credentials in your own vault, the runbooks yours whether or not you keep paying us, and no proprietary middleware in the middle that quietly stops working when the invoices do.

That is a commercial position as much as a principled one. Lock-in is what a supplier reaches for when the work cannot hold a client on merit.

Our aim is to make staying the obvious choice every year, never the only one. A client who could walk away tomorrow without a fight and stays anyway is the only endorsement worth having.

The questions to settle before you sign off

Whether you are commissioning an integration, comparing quotes, or auditing something you already run, these are the questions that decide how the next outage goes. They are worth asking while everyone is still cheerful about the project, and the answers tell you a great deal about who you are dealing with.

How it behaves when something fails

1. What happens to a record that fails to send? If the answer is anything other than “it is retried, and then held somewhere we can see it,” that record is being thrown away.
2. What does this integration log, and can we see it? A system that cannot tell you what it did yesterday will be expensive to diagnose for the rest of its life.
3. How would we know if it were half-working? Total failure is easy. Ask specifically how partial failure surfaces.

How you find out, and who acts

4. If this stops working tonight, what tells us, and how quickly? If the answer involves a person noticing, you do not have monitoring.
5. Who receives that alert, what are they expected to do, and how fast? Name someone and attach a timeframe. If neither can be named, that is the finding.
6. What is the manual fallback while it is down? Every integration needs a way for the business to keep operating without it, even if that way is slow and unpleasant.
7. Who is responsible for upstream API changes, and how do they hear about them? Somebody has to be subscribed to the developer changelogs of every platform in the chain.
8. When did anyone last check that this still matches how you work? Nothing raises an alarm when an integration carries on doing correctly what the business stopped needing a year ago.

What you own, and how easily you could leave

9. Where does the code live, and whose name is on the hosting and the credentials? All three should be yours. Anything else is a tenancy.
10. How do we see what it is doing without asking you? You should be able to check the state of your own operations at eleven at night without emailing anybody.
11. What happens if the person who built this leaves? If the answer is “we would be in trouble,” the documentation is the thing to fix first.
12. What does support cost, what does it cover, and how fast is the response? An informal understanding is not an answer to this question.
13. If we wanted to move this to another provider next year, what would that take? The answer reveals more about a supplier than any other question on this list.

The gap between two quotes is usually sitting in these answers. Paying for the failure handling up front is cheaper than paying for it later in diagnosis time and month-end reconciliation, which is what makes the higher quote the cheaper one over the life of the integration. That holds only as far as the answers do. A supplier who has not thought about any of this is selling you the same risk at whatever price they like, and you have found that out before signing instead of eighteen months afterwards. It is one of the clearest signals of the difference between an integration partner and a developer for hire.

When this is more care than the integration deserves

Not everything needs this treatment, and it would be expensive nonsense to pretend otherwise.

Civil engineers do not build every bridge to the same specification. A motorway crossing carrying forty-tonne lorries and a footbridge over a stream in a park get very different amounts of steel, and both are correctly engineered. You could build the footbridge to motorway standard. It would be magnificently strong, nobody would ever be at risk, and it would be a straightforward waste of money that could have gone on something the town actually needed. Engineering is the discipline of matching what you build to the load it will genuinely carry, with a sensible margin on top. Working out how much margin is most of the job.

Integrations are no different. The load is what it costs you to have that data wrong for a day. If an integration moves a handful of low-stakes records a week, if a failure would be obvious within hours because someone is looking at the output anyway, and if doing the work by hand for a fortnight would be irritating but not damaging, then lightweight is correct. Check it occasionally and move on. A supplier who specifies the same failure handling for every integration has skipped the part where somebody works out what this one actually carries.

We turn this work down, or quote less for it than we could. A scheduled export that one person opens on a Monday morning does not need an alerting stack and a response commitment attached to it, and selling those would be selling engineering nobody would ever feel.

The threshold is consequence, not complexity. Apply real ownership where an integration touches money, inventory, or customers, because those are the places where a quiet failure compounds while you are not looking. A stock feed that silently stops is overselling by Thursday. An invoice sync that drops 2% of records is a reconciliation problem that surfaces at month end and takes days to unpick.

There is also a legitimate case for accepting the risk deliberately. If you have decided that a particular integration can break, that you will notice within a day, and that you will live with the consequences, that is a real decision and a defensible one. It is completely different from having never thought about it. One of our clients ran a sync against a legacy warehouse system that allowed a single request per hour, which is a constraint you would never choose. It worked because the constraint was understood and designed around from the start.

What to insist on even at the lowest budget

Going light is a decision about engineering, and it should never become a decision about rights. The failure handling is the part that costs money to build. The ownership terms cost nothing to grant, which means a tight budget is never the reason a supplier withholds them. Three things are worth insisting on however small the job:

• The credentials to your own systems are created by you and held by you. It takes an afternoon, it costs nothing, and it is the whole difference between a supplier you could replace and one you could not.
• The code sits somewhere you control, with a short plain-English note saying what it does and which systems it touches. The cheapest build in the world is still cheap to hand over when the next person can find it and read it.
• You know what happens to a record that fails to send. Asking is free even when fixing is not, and if the answer is that it vanishes, you have priced the discount properly and can decide whether you still want it.

None of that turns a cheap integration into a robust one. It does keep the next decision in your hands, and that is the part that gets expensive to recover once somebody else is holding it.

Frequently Asked Questions: Integration Ownership and Maintenance

How do I tell a well-built integration from a cheap one before I buy?

Ask what happens when things go wrong. Every quote handles the normal case. The differences are in retries, where failed records go, what gets logged, what triggers an alert, who receives it, and what the documented fallback is. A supplier who answers these fluently has built the failure handling before. One who treats them as edge cases is quoting for the happy path only, and you will pay for the rest later in diagnosis time.

Is the cheapest quote really more expensive in the long run?

Usually, and the reason is mechanical. The savings in a cheap build come from omitting error handling, logging, alerting and documentation, none of which are visible at launch. Those omissions turn every future incident into an investigation instead of a fix, and they mean failures run undetected for longer. Maintenance on a well-built integration is usually small and planned, and on a genuinely stable pair of systems it can be close to nothing for long stretches. Maintenance on something nobody can diagnose means paying someone to work out what happened before they can start on why.

If our partner maintains the integration, do we still own it?

You should, and the two things are separate. Maintenance is a service you buy and can stop buying. Ownership means the code sits in your repository, the credentials to your systems are held by you, the hosting is on your account, and the documentation is yours to keep. A supplier who ties the second to the first is selling access to your own operations. The practical test is whether you could hand everything to another developer next month without a negotiation.

How often do integrations actually break?

Usually without drama, and how often depends almost entirely on what you are connected to. A well-built integration between two stable systems can go a very long time without needing anything. One spanning several actively developed platforms will want looking at more regularly, because the busier a platform is, the more often it changes something that used to work. In both cases the attention is small and preventative when someone is watching, and expensive when nobody is.

Our integration has run fine for two years. Do we still need to worry?

Two years of stability tells you the integration was built well. It tells you nothing about the next twelve months, because the change is coming from outside. Google announced the Content API for Shopping deprecation in August 2025 and shut it down in August 2026, and integrations that had been running perfectly for years stopped on that date. Stability is not the same as safety.

Is the vendor not responsible for keeping their API working?

They are responsible for their end, which is not the same thing. Well-run platforms version their APIs, publish deprecation notices, and give you notice before removing anything. Shopify, for example, releases quarterly and supports each version for at least twelve months. That is a fair deal, but it puts the obligation on you to act inside the window. The notice is only useful if someone on your side is reading it.

What is the difference between support and maintenance for an integration?

Support is reactive: something has broken and someone fixes it. Maintenance is preventative: tracking upstream API changes, adjusting the integration before a deprecation lands, and reviewing whether the business rules still match how the business actually runs. Support alone means you are always finding out the hard way. Most of the cost of a broken integration is the time it ran broken, so the preventative half is where the value is.

Can we not just monitor it ourselves with an alert if the sync fails?

You can, and it is far better than nothing. The limitation is that a simple did-it-run check only catches total failure, which is the least damaging kind. Partial failures are what cost money: records that are skipped, fields that arrive empty, or data that syncs successfully but is stale. Catching those means monitoring the shape of the data, not just whether the job completed, and that has to be designed in from the start.

We inherited an integration nobody understands. Where do we start?

Start by watching it. Establish what it currently does from its inputs and outputs over a week, then confirm whether that still matches what the business needs. In most cases some of the original behaviour has drifted out of step as the business changed. Once you know what it should do, you can decide whether to document and monitor it or rebuild it properly. We usually do this as part of an integration audit, and we have written about why this tends to work better with a dedicated partner than as a side project for a busy in-house developer.

References

¹ Google – Content API for Shopping release notes and sunset schedule. Deprecation announced 18 August 2025, with merchants directed to migrate to the Merchant API. Available at: https://developers.google.com/shopping-content/guides/rel-notes. Google’s Content API documentation confirms the service “was sunset on August 18, 2026.” Available at: https://developers.google.com/shopping-content/guides/how-tos/common-errors

² Yasmin, J., Tian, Y. & Yang, J. – “A First Look at the Deprecation of RESTful APIs: An Empirical Study.” IEEE International Conference on Software Maintenance and Evolution (ICSME), 2020. Analysis of 2,224 OpenAPI specifications from 1,368 RESTful APIs listed on APIs.guru, of which 257 (11.55%) were deprecation-related versions. Separately, of the 251 versions that introduced breaking changes, only 32 (12.7%) had a deprecation-related preceding version, while the remaining 219 (87.3%) specified no deprecation-related information before making the change. Available at: https://arxiv.org/abs/2008.12808