Handle a Voice API content-review response in your application

Handle a Voice API content-review refusal, retain its review reference and inspect partial action results before deciding what to do next.

If a Voice API text action returns voice_content_review_required, stop automatic attempts to play that text and follow the review process. The refusal is not a network timeout. Keep the returned review reference and inspect any earlier actions before deciding whether the call needs another permitted action.

Recognize the response

Selected Voice API text can return HTTP 403 with the error code voice_content_review_required. Where supplied, fields.review_reference identifies the review to discuss with Support. Save the code and reference with your own operation record; do not log the API key or expose private call content in a public error screen.

The reviewed text action is refused before that action’s speech playback or input capture and its associated charge. This does not erase earlier call-setup charges or actions that already completed. Check actual operation results rather than assuming the whole call was free or never started.

1. Stop the retry loop

  1. Mark this operation as requiring review in your application. Keep the original request and retry key privately so you can explain which attempt was refused.
  2. Do not generate new keys, rotate credentials or repeatedly rewrite the same text to evade the review. These changes do not resolve the underlying review state.
  3. Show your operator a clear message that the action was not executed and retain the reference for follow-up. Avoid reporting “speech played” merely because your application sent a request.

2. Inspect an action sequence carefully

When the refusal occurs in a batch of Voice API actions, later actions stop even if stop_on_error was false. Inspect each returned result. An earlier answer, wait or other completed action remains part of the call’s history; the refusal does not roll it back.

For example, if a call was answered and a later speak action required review, your application must not assume that a following gather action collected a response. Leave those later steps uncompleted in your workflow. If the call is still active, use its actual status to decide whether an independently permitted action, such as ending the call, is appropriate.

3. Open the review workflow

Sign in to the Portal with the appropriate account access and open Communication reviews. Locate the matching reference when it is available in the account view. Read the requested explanation and supply accurate information about the intended communication and your activity. If you cannot locate the review, contact Support with the returned reference and UTC request time.

Use the Portal’s private review form for any requested supporting details. A review submission is not an approval, and this guide does not promise a review completion time. Keep the integration paused for the affected operation while its outcome is unresolved.

4. Resume deliberately after a decision

Read the review result and the current service state before resuming. Approval does not mean that a previously refused action has already played, or that the original call is still connected. Query the call’s current state and decide whether there is still a valid customer task to perform.

A stored same-key refusal may be replayed as the same result. Do not treat a new request identity as a routine workaround: use the endpoint’s documented contract and make a deliberate new-operation decision only after the review permits the intended activity. If the call ended, do not silently create another call.

What to check in your integration

  • The 403 review response is handled separately from transport errors and rate limits.
  • Later batch steps remain unexecuted when review stops the sequence.
  • The operator can retrieve the review reference without seeing credentials.
  • The application does not claim rollback of earlier charges or automatically call the customer again.
  • A post-review resumption checks current call state and the user’s intended next action.

These checks can be exercised with saved, sanitized example responses. Do not deliberately trigger a live content review or paid call merely to test the user interface.

Related guides

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