How it works
- Trigger — POST a request to
/ai_outbound/requestsidentifying the client bycontact_number(required, optionally withclient_id) and thepurposeof the outreach. - Synchronous intake — Oliver validates the input, resolves the client, and runs suppression checks before responding. A queued request returns
201; a suppressed request returns200with asuppression_reason. - Asynchronous dispatch — Oliver composes an opener and starts the conversation. The request moves through
queued→in_progress. - Outcome — when the conversation resolves, the request reaches a terminal status (
completed,suppressed, orfailed). If you supplied acallback_url, Oliver delivers exactly one outcome webhook — on any of the three terminal statuses, not only when anoutcomeis set. The outcome is also available anytime viaGET /ai_outbound/requests/{id}.
Purposes
Statuses
A request moves through a linear lifecycle:received → queued → in_progress → one of completed, suppressed, failed
When a request is completed, its outcome is one of booked, opted_out, or no_response. A failed request carries undeliverable when the text bounced at the carrier, and a null outcome with an error_message when dispatch never completed. A suppressed request has no outcome — it has a suppression_reason.
Timing
Suppression
Suppression is a normal, auditable outcome — not an error. Oliver will suppress a request when contacting the client would be inappropriate, for example:recent_contact— Oliver already contacted the client (by SMS or AI phone call, from any campaign) within the last 72 hours.active_conversation— there is already an open AI conversation with the client.sms_opted_out— the client has opted out of SMS.voice_not_supported— thevoicechannel is not yet available.
200 with the suppression_reason on the response. Eligibility is also re-checked just before the message is sent, so a request accepted with 201 can still end up suppressed — see the outcome webhook for the full list of reasons.
Idempotency
Setpartner_request_id to a unique value per logical request. Re-submitting the same partner_request_id returns the existing request rather than creating a duplicate, so retries are safe.
Rate limits
Each practice is limited to 120 requests per minute. Exceeding the limit returns429 Too Many Requests.
