What happens to custom integrations when a vendor changes its API?
Format: Article.
When a vendor changes its API, a custom integration may need a code change, a permission change or no change at all. The important question is who will notice, test and approve the response. An integration that worked at handoff still needs an owner for the assumptions it depends on.
An API is the supported way one system requests work or data from another. Its contract includes field names, data types, permissions, limits and error behavior. A change to any of those can matter even if the screen in your internal tool looks unchanged.
Keep a change-watch register
Make a list of the outside services the workflow needs. These are its dependencies. Do not leave one developer to remember every vendor email. For each service, keep a link to its docs and name the account contact who receives change notices. Give that person someone to notify.
| Register field | What to record |
|---|---|
| Dependency and purpose | Provider, endpoint and the business step using it |
| Selected version | Version actually requested, not just installed library name |
| Notice route | Changelog, provider email and account administrator |
| Technical owner | Person who assesses and tests the change |
| Business owner | Person who decides whether the changed behavior is acceptable |
| Time boundary | Known support deadline, or explicitly unknown |
| Fallback | What pauses and what work may continue without this dependency |
| Commercial responsibility | Included maintenance, separate work or unresolved terms |
For example, GitHub documents a header called X-GitHub-Api-Version for selecting a REST API version.[5] A header is a named value sent with a request. This lets the caller choose a version. Other vendors may not offer that choice or support old versions for the same length of time.
Keep the register tied to the actual build. A library upgrade can change requests even if no business rule was meant to change. Review the dependency record when the build changes, and review provider notices on an agreed schedule.
Test meaning, not just connection
A connection test may prove only that the account can reach a service. A contract test checks the parts of a response your workflow relies on. Ask for small, repeatable tests against approved test records or a provider test environment.
For a followup integration, useful checks might include these:
- A stable record ID remains available and is not confused with a display name.
- A missing owner stays missing rather than becoming a fabricated default user.
- A new status value produces an explicit review state.
- All required pages are read before a full-list result is declared.
- An unauthorized request fails without exposing a protected record.
- A permitted write is checked against the resulting saved state.
Keep a permitted sample reply with the test. Remove secrets and private customer details. Invented test records, called synthetic fixtures, can show whether code reads a reply as intended. They cannot prove that the real provider accepts the request. Label which tests use fixtures and which use the provider's approved test service.
A hypothetical status change
Imagine a custom account followup queue that reads a provider's task status. It recognizes “open” and “complete.” A new API version adds “paused.” The old connector treats every value other than “open” as complete.
The API call can succeed while the business result is wrong. A useful contract test would feed the new value into the connector and require an explicit paused or unsupported state. The operations owner then decides how paused tasks belong in the queue.
The developer should not invent what “paused” means. If the vendor's docs do not make it clear, hold those records and ask the vendor. Keep their IDs with the question. Once the meaning is clear, the team can find each held record and decide what happens next.
Use a staged upgrade decision
First, check the notice against your list. Name the fields, users and actions that may change. Update the tests before changing the live connection. Run a small approved sample in a separate test setup. Compare the old and new results, including missing fields and failed requests.
Next, ask the business owner to approve any changed meaning. Ask the access owner to review any new rights the provider requires. Code reading a reply correctly does not grant more access. Plan the live change only when those decisions are made and the team knows how to stop or reverse it.
Finally, watch the changed path after release and read back representative results. Keep the old version only if the provider still supports it. A rollback plan that depends on a retired endpoint is not a usable fallback.
If the dependency disappears
Pause unsupported writes and label affected views with their last verified read. Route urgent work to the agreed manual process. Do not scrape a blocked interface or silently switch providers to preserve the appearance of service. A different access route may change permissions, costs and data handling.
Bring a vendor notice or your list of outside services to Core Agentic. Book a Demo to discuss the tests and upkeep a custom build would need. Agree on who watches for changes and who handles repairs as part of the scope.
Sources
- GitHub: API Versions.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.