MICROSIVE

OpenAI voice and speech API integration

Two ways to build a voice feature on OpenAI’s models, how to choose between them, and how structured outputs turn documents into data you can check.

Reviewed by: Rahul Jaiswar, founder

What OpenAI is

OpenAI offers language, speech and image models through an API your software calls over the internet. You send text or audio, get back text, audio or structured data, and pay by usage.

Realtime speech-to-speech or a three-step pipeline?

Choose realtime when a natural back-and-forth matters most. Choose a pipeline when you need to control or record exactly what the agent says, or want to swap one part later.

A realtime speech-to-speech model takes the caller’s audio and answers in audio within one session. With fewer hand-offs, replies can start sooner, tone carries through, and interruptions are handled inside the session.

A pipeline transcribes the speech, sends the text to a language model, then turns the reply back into speech. Each step is a separate choice, so the transcription, the model and the voice can come from different providers, and the text in the middle can be logged, checked against rules or filtered before anything is said aloud. The cost is an extra hop at every step, which adds delay, and the tone of the caller’s voice is lost at transcription.

Either way, audio needs a real-time connection: WebRTC, a WebSocket or a phone (SIP) link. LiveKit is one way to run that layer. Both approaches are billed differently from text requests, so compare costs using your own call lengths.

How we use it

We have used OpenAI models in voice agent experiments.

When it fits

  • The feature needs speech and language from one account. OpenAI covers transcription, text generation and synthetic voice, which keeps an early voice or call-notes prototype to one provider and one bill.
  • The output can be checked by code or a person. Pulling the PO number, ship date and carrier out of an emailed order works well, because a validator or a reviewer catches a bad result before it reaches your system.
  • Your contracts allow the text to go to an outside provider.

When it doesn’t

  • The data can’t leave your own servers. Then a hosted API is the wrong starting point; an open model run on hardware or a cloud account you control is the one to test.
  • Answers must come only from your own records, and there is no retrieval layer yet. A model on its own fills gaps with guesses. Build retrieval first, so the model quotes the passage it relied on and refuses when nothing matches.

Structured outputs for documents and orders

For text tasks, such as turning an emailed order or a rate confirmation into fields, OpenAI’s structured outputs make the reply match a JSON schema you supply. That removes parsing failures but not wrong values: a delivery date can be well-formed and still wrong. Check business rules in code, and send doubtful records to a person.

Watch for

  • A model update changes answers. Keep a fixed set of real cases and rerun it before any switch.
  • Waiting on a live call. Every step in a voice flow adds delay, so test the whole flow over a real phone call before agreeing what an agent should handle.

Related

Have a task you think a model could take on?

Send two or three real examples of the input, with anything private removed.