The Sela API is designed to ingest leads, initiate outbound phone calls, and deliver status updates via webhooks. Webhooks can be configured to return payloads based on a variety of trigger conditions, including lead status changes and call-related events. If your use case requires custom field mapping or more complex data workflows, please contact our engineering team to discuss a solution tailored to your system.
Sela supports custom metadata with each lead. The more information you provide, the better we can personalize our agents’ conversations for your clients. Any fields included in lead creation or update payloads that aren’t reserved for system use are automatically stored and can be leveraged in our talk tracks.
Lead type determines which use case and talk track we use for a given lead. During onboarding, our team will communicate what lead_type id you should include in your lead creation posts.
We will work with you to ensure two-way communication regarding Do Not Contact requests to comply with TCPA regulations. Our return webhooks automatically contain that information in our lead metadata.
Many of our customers receive duplicate submissions due to working with multiple lead sources. A lead is considered a duplicate when it matches an existing lead based on the same combination of email address and phone number. Duplicate leads are discarded unless qualify as a reengagement, as determined by the min_reengagement_days field sent in the request. This field accepts an integer value and determines whether an incoming lead that would otherwise be rejected as a duplicate (based on the same phone number and email) should instead reopen a previous lead.If at least X days have passed since the lead was originally created or last reengaged, the existing lead will be reopened rather than rejected. For example, setting min_reengagement_days to 0 will reopen the lead regardless of age, while a value of 30 will only reopen the lead if it is at least 30 days old.By default, a reengaged lead will be set to OPEN if no status is provided. However, in scenarios such as missed transfers, a specific status (e.g., CALLBACK_TO_TRANSFER) may be supplied to resume the transfer flow directly, avoiding the need for the lead to repeat the initial talk track.
