A timeout tells you that your application did not receive a usable response. It does not tell you whether IllyVoIP accepted the request. Before retrying a paid operation, preserve the original request identity and check the relevant service state. Generating a fresh key too early can create another message, call or order.
Prepare recovery before the first request
- Create one durable record for the intended operation before sending it. Include the endpoint, account, environment, exact request body, creation time and your own business reference.
- Where the endpoint supports an idempotency key, generate it once and persist it with that request. Reuse it only for the same logical operation under that endpoint’s rules.
- Store any returned resource reference immediately, even if later processing of the response fails. Keep HTTP status and sanitized error fields.
- Let only one worker own recovery for that operation at a time. Two workers generating independent keys defeat duplicate protection.
First distinguish rejection from uncertainty
A clear validation response tells you which input needs correction. A transport timeout, broken connection or incomplete body may leave the result unknown. A temporary server error can also occur after work began. Keep these cases separate in your application; do not label every exception “not sent.”
Check the HTTP status and body together. A structured in-progress or recovery-pending response needs its documented recovery path. Respect retry delays and rate limits. Do not replace every non-success response with a generic immediate retry.
Recover an SMS submission
For the SMS send endpoint, retain the same original key and body when retrying the same submission. The endpoint’s replay response can return its saved queued IDs and acceptance details. Save those IDs, then query each message’s status to confirm its destination and progress. An accepted submission is not a delivery receipt.
If the response says that the key belongs to a different or incomplete submission, stop and reconcile that record. Do not “fix” the conflict by generating another key. Correcting a destination or message is a new request and needs a deliberate decision about recipients already accepted.
Recover a phone-number order
Use the saved order reference to inspect the order. If you have no reference, inspect the account’s order list and compare the intended product, selected numbers and submission time before applying the order endpoint’s same-key retry rules. A pending order or an order awaiting documents is an existing purchase workflow, not evidence that nothing happened.
Keep the original reviewed quote fingerprint and selection with the first attempt. A changed quote or replacement number requires a new review; do not merge that change into recovery of an uncertain original order.
Recover a Voice API operation
Read the current call or action status using the relevant Voice API reference. A completed replay, an action still in progress, a content-review refusal and an uncertain media outcome are different results. Follow the exact returned error code and endpoint contract. Do not assume that all Voice actions share one universal retry rule.
For an ordered action sequence, inspect the individual results and the point where execution stopped. Earlier steps may have completed even when a later step failed. Replaying the business workflow from the beginning with new keys can repeat speech, transfers or other paid effects. If the service asks for recovery or manual review, retain the operation as unresolved until that path establishes what can safely happen next.
Verify your recovery logic locally
Use a mock that records an accepted request and then drops the response. Restart your worker and confirm that it retains the same key and body, does not create a second business operation, and records the replayed result. Also test a changed-body conflict and an in-progress response. These tests check your recovery logic; they are not live IllyVoIP delivery or billing acceptance.
When the outcome remains unknown
Pause automatic resubmission for that operation. Send Support its resource reference if available, the UTC time, endpoint and sanitized error. Keep keys, authorization headers and customer message content out of ordinary support summaries. There is no universal operation-status endpoint for every IllyVoIP service, and a GET request is not automatically free—for example, recording access can be charged.
Related guides
- Send an SMS with the IllyVoIP API and track delivery
- Find, quote and order a phone number by API
- Run an ordered Voice API action sequence and inspect partial results
- Handle HTTP 429 rate-limit responses from the IllyVoIP API
Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.