Theme
Developer workflow
Recommended patterns for a reliable VoiceLab integration.
Minimal path (sync)
txt
Client / Backend
-> X-Api-Key
-> POST /api/v1/tts/post/ or POST /api/v1/stt/post/
-> result (audio_path / transcript)Use when: short text, short audio, and you need an immediate response.
Async path (webhook or polling)
TTS
POST /api/v1/tts/post/withwebhook_notification_url→202+task_id/id- Wait for the webhook or poll
GET /api/v1/tts/status/{id}/ - History:
GET /api/v1/tts/get/
STT (long audio)
POST /api/v2/stt/post/→task_id+ recordid- Poll
GET /api/v2/stt/get/{id}/untilSUCCESSorFAILED - List:
GET /api/v2/stt/get/
txt
Backend
-> create job (v2 STT or async TTS)
-> store id / task_id
-> poll detail/status or webhook handler
-> persist transcript / audio URLRealtime path
For long sessions or low latency:
| Service | Transport | Endpoint |
|---|---|---|
| TTS | WebSocket | wss://api.voicelab.uz/api/v1/tts/realtime?token=... |
| STT | WebSocket | wss://api.voicelab.uz/api/v1/stt/realtime?format=webm&token=... |
| TTS / STT | gRPC | api.voicelab.uz:443 |
Practices:
- Reuse one TTS WebSocket for multiple
textturns; do not reconnect per turn. - Stream STT audio chunks; finish with
{"event":"end"}. - Balance is usually checked when the stream starts — verify credit before opening a session.
Recommended architecture
txt
Browser / Mobile
|
v
Your Backend (holds AISHA_API_KEY)
|
+--> REST TTS/STT
+--> WebSocket / gRPC realtime
+--> Webhook receiver (async)
|
v
Storage / DB / downstream systems- Keep the API key only on your backend.
- Separate preview and production (different keys and webhook URLs).
- Persist async job
ids in your database for retries and audit.
Integration checklist
- [ ]
AISHA_API_KEYis read from the environment - [ ] Sync TTS/STT smoke test passes
- [ ] Async status/detail flow is closed
- [ ]
402/403are handled in UI or logs - [ ] If using realtime — multiple turns on one session work
- [ ] Agents can load
llms-api.txt