Build Voice Agents with Voice Model-Ready Transit Endpoints

Product and API update - 20 August 2026

Ask, "When is my next bus?" A voice application needs a short, reliable answer - not route geometry, map colors, URLs, and repeated display data. BusMaps now provides seven voice-ready transit endpoints for applications that need to answer questions quickly.

Built with AI assistance in about two hours

We built and debugged this working integration with AI assistance in about two hours. The browser connects to GPT-Realtime-2.1 over WebRTC through the OpenAI Realtime API. The model then calls BusMaps tools to search for places, plan a route, and fetch the exact boarding stop's next departures, while keeping the selected route and stop identifiers for follow-up questions.

Tired of your AI hallucinating? Connect it to a real API.

A model should not invent a route, stop, or departure time. In the demo, the browser connects to GPT-Realtime-2.1 through the OpenAI Realtime API and WebRTC. When the model needs transit data, the BusMaps Voice backend runs a three-step tool chain: place search, compact route planning, and the exact boarding stop's next departures. The route result keeps the selected line and stop identifiers in context, so the user can ask, "When does the next bus on that line leave?" without repeating the journey.

Built for voice models, delivered as JSON

The voice-ready methods use the /compact/v1/* URL family because smaller responses are how they keep model tool calls focused and fast. They are answer-focused representations of existing BusMaps capabilities, designed for voice models and voice agents. They keep the stops, services, times, alerts, accessibility values, and follow-up identifiers an assistant needs, while removing geometry and presentation metadata it would otherwise have to ignore. The regular /v1/* methods remain available for map-ready responses, and both response families can be used in the same application.

Voice platforms you can build with

The options below range from complete realtime voice APIs to open-source speech components. This is not a ranking: each can use BusMaps voice-ready methods either through remote MCP or through its own function-calling, tool, or application layer.

Realtime speech-to-speech models and APIs

OpenAI GPT-Realtime-2.1 Direct MCP support OpenAI GPT-Realtime-2.1-mini Lower-cost realtime model - direct MCP Google Gemini Live API Connect through function calling Microsoft Azure Voice Live Direct MCP support Amazon Nova 2 Sonic Connect through tool use or AgentCore Kyutai Moshi Open-source full-duplex model - application bridge NVIDIA PersonaPlex Open-weight full-duplex model - application bridge Qwen3-Omni Open-source end-to-end model - application bridge

Managed voice-agent platforms

ElevenLabs Agents Direct MCP support Deepgram Voice Agent API Connect through function calling Hume EVI Connect through tools or an application bridge Speechmatics Flow Connect through tools or an application bridge Cartesia Sonic Use in a composable voice stack PlayAI Voice Agents / PlayHT Use its speech models in an application bridge Retell AI Connect through custom functions Vapi Connect through tools or MCP Bland AI Connect through API tools or webhooks

Frameworks and composable speech stacks

Hugging Face Speech-to-Speech Open-source Realtime-compatible server with tool modules LiveKit Agents Open-source agent framework Pipecat Open-source voice framework AssemblyAI streaming STT stack Add BusMaps through the application LLM Google Cloud Speech STT/TTS Add BusMaps through the application LLM NVIDIA Riva Self-hosted speech stack with a tool bridge faster-whisper + Kokoro/Piper + local LLM Fully local stack with MCP or function calling

BusMaps does not ship prebuilt connectors for these platforms. A "direct MCP" label means the platform can connect to a remote MCP server. Every other option needs its tool or function layer, or a small amount of application code, between the voice stack and BusMaps.

From a question to a transit answer

The voice platform turns speech into a travel question, the application calls the relevant voice-ready method, and BusMaps returns the facts needed for the spoken answer. A conversation can start with place search, continue with a route, and then request live departures for the exact boarding stop. Returned identifiers let the application answer follow-up questions without starting over.

Why smaller responses help

Voice-ready responses declare repeated field names once, deduplicate shared objects, and omit map-only detail. That reduces network transfer, JSON parsing, and model context without asking the model to reconstruct missing transport facts.

For example, /compact/v1/routes keeps the journey alternatives, transit legs, stops, services, scheduled and live times, accessibility values, alerts, and identifiers needed for the next request. It removes route geometry and presentation metadata, deduplicates equivalent alternatives, and replaces repeated objects with references. The application gets the transit answer without first unpacking a map-ready response. In one like-for-like documentation example, the same two journey alternatives took 7,506 bytes as minified JSON from /v1/routes and 1,973 bytes from /compact/v1/routes - 74% smaller. The exact reduction depends on the journey.

Try the methods through MCP or REST

For a prototype, connect a compatible agent to the BusMaps Transit MCP Server. The public demo requires no BusMaps API key and exposes all seven voice-ready methods as tools with schemas and examples. A platform without MCP can call the same methods through a custom function or skill backend.

For production, call the REST methods with your own BusMaps key. The Voice Model-Ready endpoint documentation contains the complete compact contracts, and new developers can request API access here.