When a software provider changes an API, the person responsible for your integration should already be named. Agree who watches supplier notices, decides whether a change affects a business process, pays for the work, tests the replacement and handles a failed handoff. Put those duties in the support agreement before the connector becomes essential. Owning code alone does not keep it running.
HubSpot’s September 2026 announcement is a useful prompt. Its older numbered API versions and legacy app types are moving towards new versions and architecture. That does not mean every HubSpot connection is broken today. It means a business relying on one should find out which parts it uses, who maintains them and what evidence will show that a migration works. HubSpot says existing legacy private apps continue to work for now, even though the ability to create new ones is ending on a separate timetable.
The same ownership question applies to an accounting connector, a booking feed or a customer portal. A purchased connector may be maintained by its supplier. Custom code may sit with your developer. A workflow in an automation platform may be owned by neither in practice if the person who set it up has left. I would make that uncertainty visible before asking anyone to estimate a replacement.
What has actually changed?
Start with the provider’s original notice, not a summary or a sales pitch. Record the affected product, account, app, API version, date and required action. Then separate three questions: can you create a new integration, will an existing integration keep running, and will an older interface still receive support? They can have different answers.
HubSpot’s legacy-app creation notice says new accounts lost the ability to create legacy private apps on 28 September 2026; for existing accounts, the stated date is 26 October 2026. It also says existing legacy private apps continue to work as they are for now. Its wider 15 September announcement gives a September 2027 enforcement date for older app architecture and API versions v1 to v3. The v4 support timetable is separate. These distinctions matter if somebody proposes an urgent rebuild on the strength of a headline.
The change might also affect data rather than access. HubSpot’s migration guide notes that some replacement endpoints differ in request bodies, query parameters or response shape. A successful connection test does not prove that a customer record, invoice status or approval has reached the right place. Ask your maintainer to show the actual path your business uses and the behaviour that needs checking.
Where is the integration, and what does it do for the business?
Write down one row per important handoff. Keep the first pass understandable to the person responsible for the work it supports:
| Record | Question to answer |
|---|---|
| Business job | Which customer or internal task stops if this handoff fails? |
| Systems | Which product sends the information, and which receives it? |
| Operator | Who notices a failure and can use a temporary route? |
| Technical maintainer | Who can inspect, change, test and release the connection? |
| Supplier | Who supplies the connector, API or automation platform? |
| Evidence | Where can you see the last successful run and a failed run? |
| Change window | Which deadline, busy period or renewal affects the work? |
Do not assume that an app visible in an admin screen describes every connection. A scheduled script, a low-code workflow, a supplier-managed connector and a spreadsheet import can all move the same records. HubSpot says its developer task card detects legacy API use from runtime calls, which means a rarely used or seasonal job may need a separate code and process check. Ask the supplier or developer for the list of integrations they operate on your behalf.
The point of the inventory is not to catalogue every endpoint for the sake of it. It is to identify which business journey depends on each connection. If a nightly report stops, you might have time to repair it. If an order acceptance fails without an alert, you may need a tested manual route the same day. The answer depends on your process, not on how complicated the code looks.
Who pays for a provider’s change?
This is the question to settle when you commission the integration. A one-off delivery quote often covers the initial build and a short defect period. It may not cover future API versions, changed authentication, new data fields, platform subscriptions or the time needed to retest a business process. A monthly support fee is not automatically comprehensive either. Read what it actually includes.
I would ask a supplier to answer these points in writing:
- Monitoring: which provider notices do you watch, and how soon will you tell us about a relevant change?
- Assessment: is impact analysis included in support, or quoted separately? Who can approve further work?
- Routine updates: which API, library, credential and platform changes are part of the fee? Is there a time allowance or an exclusion?
- Testing: who supplies realistic test cases and signs off the business result? Is a test account available?
- Incidents: who responds if the handoff fails, during which hours, and how is urgency decided?
- Handover: will we receive source access, deployment instructions, configuration references and a current runbook if we change supplier?
For a business-critical handoff, include a simple change clause. For example: the maintainer checks published provider changes each month, records whether they affect the integration, alerts the business owner if work is needed, proposes a cost and timetable, then demonstrates agreed test results before release. That is a suggested contractual structure, not a claim about a standard market term. Your agreement should reflect the service you actually buy and the risk you can tolerate.
Make the price boundary explicit. An unlimited promise may be expensive or too vague to rely on. A tightly capped support allowance can work if it states what happens when the cap is reached and who can authorise more work. Count the connector’s licence, automation platform charges, hosting, monitoring, support and future migration work in the total running cost, not just the initial development invoice.
How do you prove the replacement still works?
Agree acceptance tests before anyone changes the connection. Use a small set of real business situations with safe test data. A CRM-to-accounts handoff might need an ordinary invoice, a partial payment, a credit note and a retry after a temporary failure. A booking feed might need a cancellation, an amendment and an order arriving out of sequence. Choose cases from your own work rather than copying a generic checklist.
For each case, record the expected result in the destination, the person who checks it and the way a failure becomes visible. Run it in a test environment where possible. Keep the old path available until the new one has passed, if the provider and system design allow that. Reconcile a bounded set of records after release, including records created during the change window. An HTTP success code is useful technical evidence; the business owner still needs to confirm the right outcome.
The HMRC Making Tax Digital API roadmap shows why this matters beyond one CRM supplier. Its September 2026 entries mark some changes as breaking for software vendors. If your business buys compliant accounting software, the vendor may carry the technical change, but you still need to know who checks that your own data flow and filing process work after an update. Do not take over a vendor’s specialist tax obligations by accident.
Should you keep a connector, build a new one or change the process?
There is no automatic case for bespoke software because a provider has changed an API. Compare three practical options against the same business test.
Keep the managed connector when the supplier supports the new interface, the data mapping matches your workflow and its support terms are clear. Ask for the supported version, change policy, error visibility and an export route. A lower upfront cost can be a sound choice if the connector remains reliable and understandable.
Commission a small custom integration when your matching, approval or exception rules cannot be expressed safely in the standard connector, and you can fund ongoing maintenance. Specify ownership of code, credentials, logs, documentation and deployment. A custom connection gives you control over behaviour; it also leaves you with the duty to operate it.
Change the process when a handoff adds little value or creates more exception work than it removes. A controlled export and import at an agreed interval may be sufficient for a low-volume process. For an important live handoff, manual work can be a temporary continuity plan while the permanent option is tested.
Our system integration service starts with the journey and its failure modes. The broader guide to connecting business systems explains when APIs, automation platforms or custom middleware fit. Neither is a reason to replace a useful system without measuring the disruption and running cost.
What should you do this month?
Choose the three connections whose failure would affect customers, cash or a deadline. For each, find the provider notice, the technical maintainer and the person who approves the business result. Ask the maintainer for the supported API or app version and a dated assessment of any announced change. Then agree one test case, one failure alert and one temporary operating route. Put the next review date in the same record.
If an answer is unknown, label it unknown and assign someone to find it. Do not mark a connection safe because it ran yesterday. Do not commission a rebuild until the actual deadline, change and business consequence are clear.
Recommended reading
- When Your CRM and Accounts Disagree shows how to identify the system that owns each business fact.
- The True Cost of SaaS Subscriptions for UK SMEs helps frame running costs beyond the headline licence fee.
If you have an integration deadline or an owner nobody can name, bring the provider notice and one real workflow to a conversation about your options. I can help define the maintenance boundary and the tests before you spend money on a connector or a build.