Skip to main content
By default an outbound call that is not answered is simply over: the result reaches your webhook and nothing dials again. A retry policy changes that. It says, per outcome, how long to wait and how many times to try, and it can cap how often any one number is called. Retries are opt-in: an agent with no policy, placing a call with no policy, never redials.

​
Creating a policy

Policies belong to the account and are managed at Account Settings → Retry Policies in the Dashboard, or through the Retry Policies API. Each policy has a name (unique within the account) and: Rules — one per outcome, for no_answer, busy, voicemail (the call reached a voicemail box, with or without leaving a message) and failed. An outcome with no rule is never retried; a call that reached a person is never retried either. Contact limits (contact_policy) — hard caps per destination number, enforced across the whole account: Max calls per day (max_attempts_per_day, up to 50), Max calls per week (max_attempts_per_week, up to 200), and a Minimum gap between attempts (min_seconds_between_attempts). A call that would break a cap is refused when it is triggered, with 409 policy_violation, and a retry that would break one is cancelled instead of dialled. When attempts run out (on_exhausted) — end (Stop quietly), webhook (Call a webhook), or notify_email (Send an email), with the URL or address in on_exhausted_target. See escalation. Reschedule out-of-window calls (reschedule_out_of_window) — when the agent has calling hours and a call is triggered outside them, queue it for the next window instead of refusing it.

​
Assigning a policy

  • Per agent: choose a Default retry policy in the outbound agent’s settings (Dashboard or Connect App), or set defaultRetryPolicyId through the Agents API. Every call that agent places follows it.
  • Per call: pass retry_policy_id when you trigger the call. It overrides the agent’s default for that call only.
The policy is copied onto the call when it is created. Editing or deleting a policy later changes future calls, never a chain that is already in flight.

​
How a retry chain works

Each retry is a new outbound call that inherits everything that defined the original — number, agent, context, greeting, voicemail message, AMD and IVR settings, callback URL — and keeps its own transcript, recording and detection result.
  • The retry is created with status scheduled and a next_attempt_at; it dials when that time arrives.
  • attempt_number counts up from 1. parent_call_id points at the attempt before it and root_call_id at the first call of the chain, so you can group a chain in your own system. Your metadata is echoed on every attempt, with a reserved _telzino_retry key carrying the same two values.
  • Each attempt fires your result webhook on its own.
  • Reports → Outbound Calls shows the attempt number and, for a scheduled retry, when it will dial, with a Cancel button.

​
Stopping retries

  • Opt-out. If the callee asks not to be called again — the agent is given a tool for exactly this on outbound calls, and the transcript is also checked for clear phrases such as “stop calling me” or “take me off your list” — the call is marked opt_out_detected, every queued retry to that number is cancelled, and the result webhook reports it. Add the number to the suppression list to stop future campaigns as well; opting out does not do that on its own.
  • Cancel one scheduled retry: the Cancel button in the report, or DELETE /v1/agents/{agentId}/outbound-calls/{callId} on a call whose status is scheduled (reference).
  • Cancel every scheduled retry to a number: DELETE /v1/outbound-calls/queued?to_number=…, for do-not-call handling when all you know is the number.
A retry that has already started dialling is not affected by any of these.

​
When attempts run out

With on_exhausted: webhook, Telzino POSTs one event to your URL when the last attempt of a chain ends without reaching a person:
With notify_email, an email with the same facts is sent to the address you gave, from the account’s own configured email server. Delivery is best-effort and is not retried.