Adding the Responses API does not require replacing every chat completion call. Start with one workflow, keep the existing route intact, and make the differences explicit. This first lap covers endpoint configuration, request shapes, response parsing, conversation state, and the checks that keep a small migration from becoming an accidental rewrite.
1. Separate endpoint compatibility from model availability
An OpenAI-compatible service may support chat completions without implementing every Responses API feature. Before writing application code, confirm that your chosen route supports /v1/responses, the selected model, and any tools or state features you need. A model appearing in a catalog does not establish support for every endpoint.
SwiftRelay is a practical option for routing multiple model families through one pay-as-you-go account, with per-token billing. Sign up for SwiftRelay to receive a small gift credit, then verify Responses support for your intended route before committing the workflow. Keep your working chat completions integration available during that check.
2. Configure one client with an explicit base URL
For an OpenAI SDK pointed at SwiftRelay, use https://api.fastapirelay.com/v1 as the base URL. Load your relay key from an environment variable rather than embedding it in source control. Keep the model identifier configurable too; use the exact identifier supplied by the service, not a guessed display name.
With the Python OpenAI SDK, client construction can look like this: client = OpenAI(api_key=os.environ["SWIFTRELAY_API_KEY"], base_url="https://api.fastapirelay.com/v1"). This assumes you have imported os and OpenAI. Use an SDK version that exposes client.responses; an older installation may need updating.
3. Translate one text request into Responses input
Choose a bounded task such as drafting a release note from three bullet points. Your existing call might be client.chat.completions.create(model=model_id, messages=[{"role": "user", "content": prompt}]). The corresponding minimal Responses call is client.responses.create(model=model_id, input=prompt).
For separate application guidance, Responses provides an instructions field. For example, add instructions="Write a concise release note in plain English.". Do not mechanically rename messages to input throughout a large codebase: structured content, tool results, and multimodal inputs need their own mapping.
4. Parse output without assuming the first item is text
Chat completions commonly exposes generated text through completion.choices[0].message.content. In the Python Responses SDK, response.output_text is the convenient accessor for aggregated text output. The underlying response.output collection can contain different item types, including tool calls.
Put endpoint-specific parsing behind a small adapter. Return the text your application needs, but retain response identifiers, usage information, and structured items when relevant. Treat an empty text result as something to inspect, not automatic proof of failure: the model may be requesting a tool action instead.
5. Choose explicit history before adding stored state
For the first test, send the context required for each request explicitly. This makes behavior easier to reproduce and avoids depending on server-side conversation storage. Keep a canonical application transcript rather than assuming the two endpoints share a conversation automatically.
Where supported, Responses can continue a conversation using previous_response_id. Verify storage behavior, retention requirements, and route support before adopting it. Carry forward instructions deliberately: instructions from an earlier response are not automatically inherited through previous_response_id. Do not assume a continuation makes earlier context free; inspect usage.
6. Validate tools and streaming as separate milestones
Start without tools or streaming. Once plain text works, add each capability independently. Function tools use different request and result shapes across the endpoints, and Responses streaming uses typed events rather than the chat completion delta structure.
- Validate tool arguments before executing application code.
- Return function results with the matching call identifier.
- Confirm whether built-in tools are available on the selected route.
- Handle partial output, errors, and completion events explicitly.
7. Gate rollout with a small regression checklist
Run representative prompts through both integrations and inspect instruction adherence, output parsing, tool behavior, and token usage. Test invalid credentials, unsupported parameters, and interrupted requests. Then enable Responses for one workflow behind a configuration flag. Keep chat completions for existing workloads until the new path satisfies your application's requirements; endpoint adoption should be deliberate, not an all-at-once switch.