When an API retires: keeping a business assistant running.

Retrospective · week of 24 August 2026

An automation can remain useful even when the technology behind it reaches the end of its life. The problem may not be visible in the interface: teams still use the same button, but a service behind that button changes or disappears. Maintenance therefore needs to be part of the project from the outset.

Assistants API closed on 26 August. OpenAI recommends Responses and Conversations. Source: OpenAI's official changelog.

Understand what depends on what

Before choosing a migration approach, inventory the affected assistants and workflows. Record their business purpose, owner, services called and connection method. A product name on an invoice is not enough: you need to know which dependency the process actually uses.

Next, rank each use case by the consequences of an interruption. An internal preparation tool may have a temporary manual alternative. A step essential to receiving sales enquiries needs a different arrangement. Prioritising business impact avoids treating every technical change as equally urgent.

Define what must stay the same

Migration is not simply about getting a response from the new service. It must preserve the behaviour the team relies on. A summary can read well while omitting a reference needed later in the process. Structured output can look correct but no longer match the fields expected by the CRM.

Prepare a small set of contract tests: for each input, specify the expected format, mandatory fields, acceptable errors and prohibited actions. Use fictional data or information prepared specifically for testing. Include an incomplete request, an ambiguous enquiry and a service outage, not just an ideal example.

Illustrative example: a sales preparation assistant

Suppose an assistant turns an enquiry into a summary and a list of follow-up questions. The test should not merely check that text appears. It should confirm that the enquiry reference is preserved, that a missing budget remains missing and that no message is sent to the prospect without the intended approval step.

Compare both versions using the same examples while the old service remains available. If it has already disappeared, compare the new results with documented expectations and usable reference outputs. Returning to a retired API must not be presented as a genuine fallback.

Plan a reversible switch where possible

A staged migration can start with a limited scope, human review of results and error monitoring. Decide in advance what should trigger a pause: missing fields, unprocessed enquiries or unexpected actions. Identify who can authorise that pause and how they will be alerted.

The fallback must be practical. Depending on the situation, it could be a supported version, a visible queue or a documented manual process. “Roll back” is not a procedure unless the technical conditions allow it and someone knows how to carry it out.

Make maintenance an explicit responsibility

Once the change has been validated, update the inventory, tests and operating instructions. Assign responsibility for monitoring supplier announcements and checking their effect on workflows. The deliverable is not just an integration that works today, but a method for recognising the next important change.

SWM's automation service is a way to consider the workflow's operation and evolution together. Let's check your assistants' dependencies before their next technical change.