Play a private IllyVoIP recording through your application backend

To play an IllyVoIP call recording inside your own application, have your backend authenticate the viewer and retrieve the authorized recording. Keep the IllyVoIP API key on the server. A browser audio element cannot safely hold an account owner’s key, and an unprotected proxy would expose private calls.

Before you begin

• Use an account owner API credential and a public call reference returned for that account. Do not substitute a Voice API control identifier or construct an internal recording filename.
• Check that recording was enabled for the call and that its audio is available. Enabling recording now cannot recreate audio for a past unrecorded call.
• Review recording access charges. A read-shaped request can trigger recording-access billing; a small byte range is not a free preview mechanism.
• Decide which signed-in users may hear each call. Your application must enforce that rule on every audio request.

1. Create an authenticated backend route

Expose a route in your own application that accepts an authorized call reference. Resolve the account credential from your server’s secret store and call the documented recording endpoint on the fixed IllyVoIP API host. Do not accept an arbitrary upstream URL from the browser or append the key to the audio URL.

Use your application’s normal session or another suitable authenticated mechanism for the browser request. Confirm that the user belongs to the intended account and is allowed to access this particular call. A hard-to-guess reference alone is not authorization. Keep recordings out of shared public caches and avoid writing audio or credentials into request logs.

2. Forward a single byte range for seeking

Browsers may request only part of an audio file so they can seek or resume. Forward the incoming Range header only after checking that it is a supported single byte range. The recording endpoint accepts a closed range, an open-ended range or a suffix range; it does not accept a comma-separated multi-range request.

Range: bytes=0-4095
Range: bytes=4096-
Range: bytes=-4096

These are three separate examples, not three headers to send together. Do not fetch the entire recording repeatedly to simulate a range in the browser. Apply sensible timeouts and stream the authorized response rather than loading an arbitrarily large recording into memory.

3. Preserve the response semantics

• For a successful complete response, forward the audio content and its actual success status.
• For 206 Partial Content, preserve Content-Range, Content-Length, Accept-Ranges and the audio content type. The content length describes this response body, not always the whole recording.
• For 416 Range Not Satisfiable, pass the failure through. Preserve a returned Content-Range such as bytes */12345; do not convert the error body to a successful MP3.
• Preserve private, no-store caching behavior. Do not follow an unexpected redirect with the secret header attached.

4. Show useful failures in your player

An unavailable or still-processing recording needs a message outside the audio element. Inspect the HTTP status and structured error before treating the response as audio. Where a processing response includes Retry-After, respect that delay. Avoid an unbounded retry loop: it can obscure the real problem and repeatedly request a paid resource.

For an authorization failure, recheck the application user, account and call mapping. For a missing recording, inspect the call’s recording eligibility and Portal state. For a range error, check the requested offsets against the current file length and let the browser begin a fresh valid request if appropriate.

5. Verify before allowing customer access

1. Test signed-out access and a signed-in user who does not own the call. Neither should receive audio.
2. Test complete playback, a valid range and a range beyond a synthetic test file. Verify status codes and byte counts.
3. Test a processing or JSON error response. The player must show the failure rather than reporting a corrupt MP3.
4. Check that browser developer tools, page source and access logs do not contain the IllyVoIP key.
5. With authorization for the cost and data access, verify one real eligible recording. Local range tests alone do not prove live audio availability.

If Support is needed, provide the public call reference, UTC request time, HTTP status and sanitized error. Do not send the recording itself unless specifically needed through an appropriate private channel.

Related guides

• Export call history and retrieve available recordings with the IllyVoIP API
• How to Read and Understand Your VoIP Call Reports (CDR)

Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.