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 are the silent ones, and whether a failure stays silent is 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 wasn’t

• 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 taken out, 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 and the credentials, and you can see what it’s 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 doesn’t, and a supplier who quotes the same for both has skipped the thinking

On August 18, 2026, Google switched off the Content API for Shopping. It had announced the shutdown exactly a year earlier, and offered a migration path to the new Merchant API.¹

For any business whose product feed still ran through the old endpoint, the calls started coming back as errors. No email, and no warning banner in the admin. The listings just stopped updating.

Some of those businesses found out that morning. Others found out weeks later, when someone asked why sales had dipped and the ad spend hadn’t.

Same shutdown, same day, for both groups. The difference was whether their integration had been built to notice, and whether anybody was on the other end of the alert when it did.

Who owns an integration once it’s live is the question almost nobody settles before launch. It’s also one of two things that decide how a morning like that goes. The other is how it was built.

Get both right and a bad day stays a bad day. Get either wrong and a small failure turns into an expensive month.

The awkward bit? The build was settled long before the thing 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, then forget it exists.

An integration is closer to a delivery van. Nobody’s surprised when a van needs servicing, and nobody thinks the cheapest one with no service history is a bargain. What you pay up front is only ever part of what it costs to run.

It’s worse than a van in two ways. An integration is less a thing you own than a conversation between two systems you don’t control, and both of them are being rewritten by other people, on a schedule nobody sent you.

And unlike a van, it doesn’t rattle first.

The build is the part you can see, so it’s the part the quote is based on. What comes afterwards is harder to price, because it varies so much.

Plenty of integrations need almost nothing for years. One stable system talks to another, and the design already handles the predictable problems on its own. 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

Nobody has to make a mistake for an integration to stop working. It wears down from several directions at once, and none of them ever takes a day off.

The platforms underneath you keep moving

Google gave a year’s notice on the Content API, then turned it off. Shopify ships a new API version every three months and supports each one for at least twelve months. Those are the well-behaved ones: big companies with formal deprecation policies and public timelines. Plenty of the systems in a typical stack have neither.

Even Google and Shopify catch you out in opposite ways, though. One is loud and one is gentle, and the gentle one is the dangerous one.

Google’s shutdown is loud. The call comes back as an error, nothing works, and you’re in no doubt that something has happened.

Shopify doesn’t reject a request to a version it has retired. It moves you forward instead, answering with the oldest version it still supports, which by definition is newer than the one your integration asked for.

So your integration carries on getting perfectly valid responses, and nothing looks broken anywhere. It’s just talking to a different version of the platform than the one it was written for.

It’s a bit like ringing your usual supplier and getting someone new, who’s lovely and quotes you from next year’s price list without mentioning it. The differences show up as quietly wrong data, with no error anywhere to point at them.

That’s the more expensive of the two. A platform that breaks you outright has at least told you. A platform that helpfully moves you onto newer behavior has handed you the job of noticing. Most businesses notice through a customer complaint, or a month-end reconciliation that won’t balance.

Most of them will not tell you first

And Google and Shopify are the considerate end of the market. The rest of your stack probably isn’t, and somebody has actually counted.

A 2020 study took 2,224 versions of 1,368 public RESTful APIs and looked at every version that introduced a breaking change. Had the version before it flagged what was coming? Only 12.7% had. The other 87.3% broke something with nothing in the specification to warn you.²

To be fair, a changelog post or an email may well have gone out, and the better vendors send both. But that kind of warning goes to a person, and it only helps if somebody reads it in time.

Picking a big, well-supported vendor buys you better documentation and a longer notice period. It doesn’t buy you a system that stops changing. And it does nothing for the smaller tools in the chain, the ones that’ll 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.

A music retailer we worked with ran fulfillment on automation rules that had been stretched years past what rules can handle. Over time the team had built up several order statuses that all meant “do not ship this.” The rules only knew some of them, so an order parked in a status they’d never heard of looked like a normal order, and out it went.

(Click and collect had the same problem. Customers who were only ever going to walk in and pick something up got a parcel instead.)

Nothing had broken. The business had moved, and the logic hadn’t moved with it.

The people who understood it leave

The developer who built it moves on. So does the ops manager who knew which errors were safe to ignore, and why that one field gets mapped backwards. (There was a reason. Nobody wrote it down.)

Once they’re gone, the integration turns into a black box that everybody’s 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 that is avoidable. Every integration ever built will meet a change it wasn’t designed for.

What happens next is very much a choice, though. And whoever built it made that choice long before the change arrived.

Take an ordinary event. An upstream platform starts rejecting a call, maybe because a field became required, maybe because a rate limit got tighter. Nothing dramatic. Sooner or later every integration meets something like it.

In an integration built to the lowest quote, the call fails and that’s the end of it.

There’s no retry, so a temporary problem becomes a permanent one. There’s no error log, so nothing records what was lost. There’s no alert, so nobody’s told.

The order or the invoice is just gone. The first sign of trouble shows up at month end, when the numbers won’t reconcile.

By then the work is forensic. Somebody has to establish what went missing and rebuild it from whichever system still has a copy. Then they have to work out how far back the problem goes, all while the integration carries on failing in exactly the same way.

In an integration built properly, the same call gets retried a few times, with a longer gap each time. That quietly sorts out most temporary problems without anyone ever knowing.

If it still fails, the record gets parked in a holding queue where you can see it, and an alert goes off within the hour. Everything else keeps flowing, so the damage stays with 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 rebuilt, because nothing was lost.

Same upstream event. One version is an afternoon’s work, and no customer ever notices. The other is a month-end crisis, with days of detective work behind it and a stretch of data nobody trusts.

It’s also where a proper integration and a chain of low-code automations part ways. A failed call in a system with retries and alerting is an incident that mostly resolves itself. In a Zapier chain, it’s often an order sitting in the task history until somebody notices and replays it by hand. We’ve written up the specific points where low-code automation stops coping.

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

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

An integration is an iceberg. Above the waterline sits the happy path: an order goes in one side and comes out the other, and everyone nods.

Below it sits everything else. Retries for the calls that fail for a moment. Queues, so a record that can’t be processed waits somewhere safe instead of vanishing. Logging good enough to answer “what happened last Tuesday?” Monitoring that raises the alarm without being asked. Documentation, and a fallback somebody has actually tested.

None of it shows on a good day. Most of the engineering is down there.

Here’s the thing: you can buy the tip on its own. It’ll demo exactly as well as the whole iceberg, because on a good day you can’t tell them apart.

The bill for the missing nine tenths arrives later, and it rarely gets traced back to the decision that caused it.

It arrives as diagnosis time, on every incident. A system that writes down what it did and shouts when it fails can be diagnosed in minutes, because the answer’s already on file. A system that records nothing has to be investigated from the outside, by someone with two databases open side by side, forming a theory.

The first is a support ticket. The second is a small project, started from scratch every time.

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 goes looking for a cause. People only see the symptom (orders not turning up where they should), so they start keying them in by hand.

Nobody decided it, but your team is now the integration. We call that human middleware.

Six weeks of it is 30 hours, roughly $1,050 at a $35 loaded hourly rate. That’s only the salaried time, and it’s the cheap part.

That figure leaves out the bad data that piled up in the meantime, and whatever that cost you at the customer end. The reconciliation afterwards is where the real time goes, and we’ve written separately about how much monthly reconciliation actually costs.

And eventually it arrives as a rebuild. A cheap integration nobody can diagnose gets patched rather than fixed, because a patch is all you can afford in the middle of an incident. Each patch adds a special case the next person won’t understand. Keep that up and you end up with a system nobody wants to touch, and a quote to replace it that rivals the original build.

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

That cuts both ways, though, and it’s worth saying plainly. A high price is no evidence of any of this.

Part of the gap between two quotes is engineering. 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’s harder to spot than underpaying, because a big invoice looks like it must have substance behind it.

The test doesn’t change. Ask what the extra money buys you in the hour after something fails. If the answer is specific, you’re buying engineering. If it’s logos and process, you’re buying somebody else’s overhead.

Aim that question at us too. 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’s responsible for keeping an integration running, and you’ll get one of three answers. None of them is good.

“The agency who built it.” Sometimes true, usually not. Unless a support agreement says so in writing, the relationship ended at handover. They may well fix it, but they’ll do it when they have capacity, at whatever they charge by then. Goodwill isn’t a maintenance plan.

“Our developer.” If you’ve got one in-house, they’re almost certainly busy with something that has a roadmap and a deadline attached. Integration maintenance is unplanned, unglamorous work that turns up without warning. It sits at the bottom of the list until it’s an emergency, and then it’s the whole list.

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

If that’s yours, don’t feel bad. Nobody puts an owner on something that’s never caused a problem.

The trouble with all three is that they treat ownership as one thing, to be handed to one party. It works better split in two, because the halves need different things.

Fast recovery depends on familiarity, and nobody knows the system like whoever built it. Control depends on independence, and you should never be in a spot where one supplier is the only way into your own operations.

Get either half wrong and it shows. Own the code with nobody watching it, and you find out about a six-week outage at month end. Let a supplier watch it without ever showing you the internals, and you get a slower, quieter problem that costs more to escape.

Here’s the split in practical terms. None of it needs 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’ve stopped wanting. That takes a person who knows the system and the business, looking at it now and then 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’s down. This is what saves you when the person who built it moves on, and takes the reason for that backwards field with them.
• 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’re independent enough that catching things early never becomes leverage.

Three kinds of supplier

Suppliers fall fairly cleanly into three groups here, and you can usually tell which one you’re dealing with before you’ve signed anything.

They deliver and run

The invoice clears and the relationship evaporates. There’s no support agreement, so the first failure is a cold start for everyone. It’s the honest version of the problem. At least you know where you stand.

They deliver and lock you out

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

The warning signs are all things you can check without a developer, most of them in an afternoon:

• The code lives in their repository, not yours, or you’ve 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’s 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’re renting access to. And you only see the price of that arrangement when you want to question an invoice, or leave.

They build it so you could leave

You can see the difference on day one, long before the first incident. A supplier in this group builds the integration so 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 stuck.

Here are ours, up front 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’s a commercial position as much as a principled one. Lock-in is what a supplier reaches for when the work can’t hold a client on merit.

We want staying to be the obvious choice every year, and 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’re comparing quotes for a new integration or checking one you already run, these are the questions that decide how the next outage goes. Ask them while everyone’s still cheerful about the project. The answers tell you a lot about who you’re dealing with.

Thirteen is a lot. If you only get to ask one, skip to the last.

How it behaves when something fails

1. What happens to a record that fails to send? If the answer is anything other than “it’s 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 can’t 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 to spot. Ask specifically how partial failure shows up.

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 don’t 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’s the finding.
6. What’s the manual fallback while it’s down? Every integration needs a way for the business to keep operating without it, even if that way is slow and unpleasant.
7. Who’s 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, and actually read them.
8. When did anyone last check that this still matches how you work? Nothing raises an alarm when an integration carries on correctly doing 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’s 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’d 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 isn’t an answer to this question.
13. If we wanted to move this to another provider next year, what would that take? The answer tells you more about a supplier than anything else on this list. So does how long they take to give it.

The gap between two quotes is usually sitting in these answers. A supplier who hasn’t thought about any of this is selling you the same risk at whatever price they like, and now you know before signing instead of eighteen months afterwards. It’s one of the clearest signs 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.

Nobody builds a footbridge over a park stream to motorway standard. It would be magnificently strong, and the money could have gone on something the town actually needed. (More ducks, probably.)

Engineering is mostly matching what you build to the load it’ll really carry. With an integration, the load is what it costs you when the data’s wrong for a day, however complicated the thing looks.

Say an integration moves a handful of low-stakes records a week. Someone looks at the output anyway, so a failure would be obvious within hours, and 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 don’t push the heavy version where the light one will do, even when that means quoting less than we could. A scheduled export that one person opens on a Monday morning doesn’t need an alerting stack and a response commitment bolted on. Selling those would be selling engineering nobody would ever feel.

Apply real ownership wherever an integration touches money, inventory or customers, because that’s where a quiet failure compounds while you’re 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’s also a perfectly good case for accepting the risk on purpose. If you’ve decided that a particular integration can break, that you’ll notice within a day, and that you’ll live with the consequences, that’s a real decision and a defensible one. It’s a completely different thing from never having thought about it.

One of our clients runs a stock sync against a legacy warehouse system that allows one request per hour. One. Per hour. Nobody would choose that. It works because they sell in bulk to other businesses, so the odds of overselling in the 59 minutes between updates are tiny, and we checked that before designing anything.

What to insist on even at the lowest budget

Going light is a decision about engineering. It should never turn into a decision about rights.

The failure handling is the part that costs money to build. The ownership terms cost nothing to grant, so a tight budget is never the reason a supplier holds them back. 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 costs an afternoon, and it’s the whole difference between a supplier you could replace and one you couldn’t.
• 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 isn’t. And if the answer is that it vanishes, you’ve priced the discount properly and can decide whether you still want it.

None of that turns a cheap integration into a sturdy one. It does keep the next decision in your hands, and that’s the part that gets expensive to win back 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'll 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 leaving out 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 they're separate things. 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're 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's 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 isn't the same as safety.

Isn't the vendor responsible for keeping their API working?

They're responsible for their end, which isn't 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's 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're 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't we just monitor it ourselves with an alert if the sync fails?

You can, and it's 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 behavior 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've 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 August 18, 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