Your integration has been successfully implemented․ A bigger concern is who owns the integration when a partner changes it․ Many teams are aware of the other systems that are affected by their integration․ Fewer teams are aware of the contacts to reach out to when a problem arises with one of their integrations that needs to be addressed․ The absence of this information is a integration risk․ This article provides a quick overview of an integration governance process‚ including a system dependency register and API contract testing‚ for integration and platform managers and business executives․
What does it mean to own the integration?
Who owns the integration when a partner makes changes?
Every integration should have a single contact and other written materials identifying integration partners and other technical information about the integration‚ such as recent transactions and contingency plans․ The single contact should receive alerts‚ decide what to do‚ and recover transactions with the other integration partner․ Integration governance practices include having a single contact and other written materials about the integration and its outcomes․
"The platform team" is not an owner․ Team members can work together‚ but there needs to be an one owner and one backup for each integration․ Assign owners and backups for all integrations․
What information should you store in a dependency register?
A dependency register is an Excel document with a row for every integration․ No special software is needed․ A shared Excel spreadsheet could work if kept up to date by someone․
Six columns per row are recommended․
- Workflow: The business process to which this workflow belongs‚ including lead assignment and order synchronization․
- Endpoints: partner endpoints and those in your system that connect to partner endpoints․
- Owner: One owner and one recovery backup․
- Version or schedule: API version or other version or release information for the integration․
- Last successful run: Date and time of last successful transaction․
- Backup: Manual processes used by the business when the integration is down or frozen․
The fifth field is critical․ A stale date in the fifth field means the integration may be failing silently, and customers will notice before you do. Other advantages of a current registry include information about the integration risk which can be assessed using data in fields five and other fields to target high-risk areas․
How do you test negative and inconclusive outcomes?
Most integration testing checks expected behavior․ Ownership gets decided on the other two outcomes so test all three behaviors․
- Normal: The partner accepts the request․ Both parties have a record of the request․
- Failed: The partner rejects the request or returns an error․ Test checks that the failure is logged and reported to the owner‚ not ignored․
- Uncertain: Partner may or may not process transaction․ Unclear about whether the partner processed the request․ Either choice is risky: resending can duplicate a transaction, and not resending can lose it․
Contract testing is a suitable approach․ API contract test records interactions between your application and a partner's API‚ including parameter testing‚ and flags test failures due to changes in a partner's API that impact your application․
Test failed, uncertain and successful transactions to detect partner API changes that might impact your production environment․
Contract tests complement end-to-end integration testing. They check the agreement between two systems quickly without needing live environment․ API contract testing can be combined with API monitoring approaches to alert the contact for a given API when the last successful test run is outdated․
If you want to learn more about how APIs can help your business read this article about what API integration is and why businesses need it. This article assumes familiarity with best practices and discusses responsibility for integration changes with a partner․
A dated example: Node․js 20 freeze on HubSpot Workflows
HubSpot's November 2026 announcement shows why ownership beats reaction․ The HubSpot November 2026 developer changelog lists two relevant dates for custom code workflow actions that run on Node․js 20:
- November 3‚ 2026: You can't write new custom Node․js 20 code actions․
- November 17, 2026: You can’t save changes to existing Node.js 20 code actions.
Current actions will persist on and after both dates․ Node․js 16 actions already work this way and HubSpot's upgrade guide suggests migrating each action to Node․js 24 by November 17․
This is a silent risk․ Nobody is impacted on November 17‚ and nobody gets a downtime notification on that date․ The silent risk comes during a future event when there is a need to update a field name or integration routing rule and the update cannot be saved․ Steps to mitigate the risk now include assigning ownership and adding a row under "version or schedule" in the dependency register․ If no ownership is assigned for this integration‚ the risk will materialize at a future date․ Steps to mitigate the risk include assigning a date to complete the action and closing the integration risk․
The announcement covers certain HubSpot services․ Code actions for workflows on HubSpot built with Node․js 20 and design manager serverless functions on their schedule․ Other services are not covered by this announcement.
What should you do this week?
- List all third party API integrations that handle financial or customer information․
- Give each one an owner and a recovery backup
- Enter data in all six register fields․ Mark as a gap any fields you cannot answer․
- Add one API contract test for a failed outcome and one for an uncertain outcome to one of your most important integration test cases‚ alongside your existing integration testing․
- Check the change logs for both parties for dated information and add dates to the register․
Frequently asked questions
What is contract testing for APIs?
Contract testing or API contract testing checks compatibility between your company's systems and an external API provider's systems․ You write contract tests to specify data formats and other expectations․ Contract tests written by your company will fail if the external API provider makes changes that are incompatible with your company's systems․ Advantages of contract testing include the ability to detect incompatibilities before they disrupt operations․ Contract testing differs from other types of integration testing in that it focuses on testing two particular systems for compatibility․
What is an dependency register?
A dependency register lists partnerships and information about them‚ such as contact information and backup plans․ A dependency register can help a team answer the question "What will be affected if this partner makes a change?" in minutes, not days.
Who should own a third party API integration?
One owner and one backup should be designated to manage third party API integrations and serve as a backup contact, the designated individual receives notifications about changes from the third-party partner and takes action to resolve issues related to incomplete or erroneous transactions․ A shared email account is not an acceptable solution․ Your API integration governance policy should include provisions to help ensure consistency in the role over time․ If you are managing API integrations with an external third-party partner‚ request that the partner provide contact and testing information for each relevant API integration before beginning any work․
Conclusion
Integration governance processes can help reduce disruptions caused by partner changes and improve integration risk awareness․ Strategies include designating a business owner for each integration and using a six-field dependency register and API contract tests to test and identify other integration issues․ Start with your top integration priority this week․ Integration staff are available to help implement the dependency tracking and testing processes‚ if desired․
