Mailbox detection

Use the existing outbound call API with mailbox detection enabled, then poll getCall. The endpoint reference owns the request and outcome schemas. This guide describes how a consumer such as n8n should coordinate a lead list. It is an integration recipe, not an installed workflow or a campaign scheduler inside SMAO.

Detection is off unless the request sets mailbox_detection to true. It currently supports German assistants. For an assistant in any other language the call runs unchanged and reports detection as skipped with the reason language_not_supported.

Keep a durable attempt ledger

Store each lead's identifier, normalized phone number, attempt count, current call identifier, processed call identifiers, next attempt time and processing status. Use a durable store with atomic updates: one lead can have only one active attempt. A repeated poll or resumed execution must not increment the counter or schedule a retry twice.

Reserve an attempt before sending the request. Count three total attempts, not three retries. A confirmed pre-dial validation/rate rejection can release the reservation. Save the returned call identifier before continuing.

Poll and make one decision per ended call

A practical node sequence is:

1. Read the next due lead and atomically reserve its attempt.
2. HTTP Request: create the outbound call with mailbox detection enabled.
3. Save the returned call identifier in the ledger.
4. Wait, then HTTP Request: read that call.
5. Continue polling until the call is done and detection is terminal.
6. Switch on the detection outcome, then persist the decision atomically.

Start with five-second polls for the first minute and fifteen-second polls after that. GET retries are safe. Honor Retry-After and rate-limit headers, including backoff when the limiter is temporarily unavailable. After thirty minutes without the required completion/result, mark the lead for review instead of redialing.

Pace outbound requests at least sixty seconds apart per assistant and respect the outbound bucket (default sixty per hour per API key). GET has a separate read bucket (default one thousand per minute). These are existing limits.

Use UTC instants for scheduling. If the call has no end timestamp, mark it for review. A machine verdict while the call is still active is not permission to start another call. For example: a first machine call ends at 10:00 UTC; the next attempt is due no earlier than 12:00 UTC. If that call ends at 12:01 UTC, the third is due no earlier than 14:01 UTC. A third machine answer exhausts the lead.

The two-hour wait and attempt limit belong to your consumer, not to SMAO. Persist scheduled times so restarts and duplicated executions cannot create extra calls.

Qualification is a separate result

Configured analyses, CRM actions and notifications continue for all calls, including machine calls. Evaluate the detection branch before acting on their results in n8n. Call success is a generic call-quality field, not a lead's qualification status.

An ended call can still have an analysis running. Select the qualification analysis configured for your assistant, wait for its completed result and evaluate its configured output. Failed analyses and missing results require review. Do not invent a qualification result from an empty transcript or failed detection.

Before running a real campaign, verify your workflow's duplicate-execution handling, ledger recovery, request pacing and ambiguous-request procedure with controlled leads. SMAO's detection support alone does not certify those consumer behaviors.