Overview
When you create a custom cloned voice in Hamsa, you need to preload it into the system before using it with any real-time API endpoints. This one-time preload ensures your custom voice is ready and available, eliminating latency when making real-time TTS requests or WebSocket connections.Why Preloading Matters:
Custom cloned voices require initialization in the system before they can be used. Without preloading, the first real-time request using your custom voice would experience significant latency as the system loads the voice model.
When to Preload
You should call the preload endpoint:- Once when your application starts - Preload during your app’s initialization phase
- Before any real-time TTS or WebSocket usage - Ensure the voice is ready before making real-time requests
- Only once per voice - You don’t need to preload the same voice multiple times
When is Preloading Required?This preload step is required when using your custom cloned voice with:
- Real-Time TTS REST API (
/v1/realtime/tts) - Streaming TTS REST API (
/v1/realtime/tts-stream) - Real-Time WebSocket connections
Preload Endpoint
Endpoint Details
| Property | Value |
|---|---|
| Method | POST |
| URL | https://api.tryhamsa.com/v2/tts/voices/custom/preload |
| Authentication | API Key (Token) |
| Content-Type | application/json |
Request Body
| Parameter | Type | Required | Description |
|---|---|---|---|
voiceId | string | Yes | The unique identifier of your custom cloned voice |
Response
Success Response (200):| Status | Description |
|---|---|
400 | Bad request - Invalid voice ID format |
401 | Unauthorized - Invalid or missing API key |
404 | Voice not found - The specified voice ID doesn’t exist |
500 | Server error - Internal server error |
Code Examples
JavaScript/Node.js
Python
cURL
Integration Patterns
App Startup Pattern
The recommended approach is to preload your custom voice during application initialization, before making any real-time API calls:Multiple Voices Pattern
If you have multiple custom voices, preload them all during startup:Best Practices
Preload Early
Call the preload endpoint as early as possible in your application lifecycle
Handle Failures Gracefully
If preloading fails, log a warning but don’t block your app. The voice will load on first use with added latency
Preload Once
You only need to preload each voice once. Don’t call the endpoint repeatedly for the same voice
Use Environment Variables
Store your API key and voice IDs in environment variables, not in code
Troubleshooting
Voice Not Found (404)
If you receive a 404 error:- Verify the voice ID is correct
- Ensure the custom voice was created successfully in your account
- Check that you’re using the correct API key associated with the voice
Unauthorized (401)
If you receive a 401 error:- Verify your API key is valid
- Ensure the API key has permissions to access custom voices
- Check the Authorization header format:
Token YOUR_API_KEY
Latency Still Present
If you notice latency even after preloading:- Ensure the preload completed successfully before making real-time requests
- Check that you’re using the same voice ID in both preload and TTS requests
- Verify the preload was called in the current session