Skip to main content

Turn AI replies on or off for a lead

PUT 
/v1/leads/:leadID/ai-handling

Sets whether the AI Employee may reply to this lead. Body: {"handled_by_ai": true} or {"handled_by_ai": false}; the field is required and must be a JSON boolean (the string "false" is rejected), and unknown fields are rejected.

Three switches. The AI replies to a lead only when AI is enabled for your company, for the messaging channel the conversation is on, AND for the lead. This endpoint controls the lead-level switch only: setting true does not turn on a company- or channel-level switch that is off, so the AI may still stay silent. Setting false always stops AI replies to this lead. Setting either value also cancels any timed AI pause set in the app.

Lead identifier. {leadID} is either the numeric lead id or the external_id, which is the data.id returned by POST /v1/webhooks/leads. Without id_type, a value that is not a positive integer is looked up as an external_id; a positive integer is looked up as both, and if it names two different leads the request fails with 409 lead_ambiguous: repeat it with ?id_type=lead_id or ?id_type=external_id. An external_id shared by more than one lead is also 409 lead_ambiguous; use the numeric id for those leads.

Right after intake. POST /v1/webhooks/leads is asynchronous: it answers 202 before the lead is stored. A follow-up call made immediately can get 404 for a few seconds; retry with exponential backoff (for example 1s, 2s, 4s, 8s) before treating the lead as missing.

Webhooks. A change sends a lead-updated event to your webhook subscriptions; repeating the current value does not. A subscriber that reacts to lead updates by calling this endpoint can create a loop.

Rate limited per company (default 600 requests per 10 minutes, shared with DELETE /v1/leads/{leadID}/tags).

Request​

Responses​

OK