Home → Blog → How to migrate from the OpenAI Whisper API to another service

How to migrate from the OpenAI Whisper API to another service

Teams leave the public Whisper API for different reasons: cost at volume, requirements on where data is processed, or the service simply not being available in their region. The good news is that when the API is protocol-compatible, migration comes down to two lines and takes an evening.

What actually changes in the code

Exactly two things: the base URL and the key. Everything else — field names, response formats, error handling — stays as it is.

# before
client = OpenAI(api_key="sk-…")

# after
client = OpenAI(base_url="https://voicesscribe.com/v1", api_key="vs_live_…")

The transcription call is not touched at all:

result = client.audio.transcriptions.create(model="whisper-1", file=f)

Keep the model parameter for compatibility: the service accepts the familiar value and uses its own model.

Compatibility in detail

That last row matters more than it looks: the official SDKs parse errors into typed exceptions. If a server answers with its own error shape, client code fails in an unexpected place — compatible errors save you from rewriting handlers.

How to compare quality before switching

Do not flip production blindly. A sensible order:

1. Collect a sample. Twenty to fifty real recordings: clean, noisy, short, in different languages — the way they arrive in production.
2. Run them through both services with one script and keep the results side by side.
3. Judge by your own criteria. Abstract percentages do not matter; your scenarios do — are product codes, names and amounts recognised correctly?
4. Switch gradually. Send 10% of traffic to the new service, then all of it a few days later.

for path in samples:
    with open(path, "rb") as f:
        a = old_client.audio.transcriptions.create(model="whisper-1", file=f).text
    with open(path, "rb") as f:
        b = new_client.audio.transcriptions.create(model="whisper-1", file=f).text
    print(path, "\n  before:", a, "\n  after:", b)

What to check separately

• Client timeouts. The default 100 seconds is fine for voice messages and short calls; raise it for hour-long recordings.
• Size limit. Files above 25 MB have to be compressed or split — the same as in the original API.
• Retries. Add one or two retries for 5xx responses: standard practice for any external service.
• Transcript retention. Confirm the policy: here, recordings and texts are deleted automatically after 24 hours.

When migration is worth it

Changing provider makes sense if at least one of these is true:

• volume has grown to the point where per-minute billing is a visible line in the budget;
• there are requirements on where recordings are processed and how long they are kept;
• you need predictable access without regional restrictions or card problems;
• you need formats or parameters your current provider does not offer.

If none of that applies, leave the working integration alone — compatibility means you can still move later in a single evening.

Frequently asked questions

Related reading

• How to transcribe a call recording to text — A step-by-step guide to turning phone call recordings into text through an API in minutes: Python and C# samples, response formats and the errors you will meet.
• Automatic SRT and VTT subtitles from video and webinars — How to get ready-made timed subtitles from a webinar or a video: extracting the audio track, SRT versus VTT, code samples and fixes for the usual problems.
• How to improve speech-to-text accuracy: eight practical fixes — Eight changes that actually move transcription quality: audio preparation, language hints, the prompt parameter, chunking, formats, and how to measure word error rate.