# Pause Outbound Calls
Source: https://docs.trysela.com/api-reference/call-control/pause-outbound-calls
/Sela_API.yaml post /api/users/{id}/pause-calls/
Pauses outbound calls for the authenticated API user. The path ID must identify that user. By default, outbound calling is paused until the unpause endpoint is called. Set `only_existing_leads` to true to asynchronously pause only leads that already exist while leaving future leads unaffected.
# Unpause and Reschedule Outbound Calls
Source: https://docs.trysela.com/api-reference/call-control/unpause-and-reschedule-outbound-calls
/Sela_API.yaml post /api/users/{id}/unpause-calls/
Unpauses outbound calls for the authenticated API user and asynchronously reschedules eligible paused leads. The path ID must identify that user. The response confirms that rescheduling was queued, not that every lead has already been rescheduled.
# Create a File Upload URL
Source: https://docs.trysela.com/api-reference/file-ingestion/create-a-file-upload-url
/Sela_API.yaml post /api/ingestion/upload/
Creates a temporary URL for uploading a CSV file to a preconfigured Sela file ingestion source. The source value is provided by Sela and determines how the uploaded CSV is processed. Sela configures which CSV column is used as the row lookup key. First call this endpoint with a source and filename, then upload the file to the returned signed_url using an HTTP PUT request. The upload URL expires after one hour.
# Introduction
Source: https://docs.trysela.com/api-reference/introduction
Welcome to Sela API Reference
## Getting started
The Sela API is designed to ingest leads, initiate outbound phone calls, control outreach,
and deliver status updates through webhooks. The endpoint pages in this reference contain
the authoritative request and response definitions.
## Authentication
Unless an endpoint explicitly says otherwise, authenticate using an Authorization token in
the request header.
```http theme={null}
Authorization: Token abc123...
```
Please do not share your token with anyone outside your organization. Custom lead-ingestion
URLs may be configured without token authentication when a third-party lead provider cannot
send credentials.
## Integration guidance
Use [Integrating with Sela](/integrating-with-sela) for the end-to-end workflow, including:
* Lead types, metadata, location, and lead creation
* Optional warm transfers and calendar booking
* Stopping outbound calls and synchronizing DNC
* Webhook strategy, replay testing, and reengagement
See [Webhook Responses](/api-reference/webhook) for payload structure and webhook
authentication options.
# Create a Lead from a Custom Payload
Source: https://docs.trysela.com/api-reference/lead-ingestion/create-a-lead-from-a-custom-payload
/Sela_API.yaml post /api/ingest-lead/{id}/create/
Creates a new Sela lead from a custom payload format. Sela configures these ingestion endpoints when an external system, such as a lead provider, cannot send Sela's standard lead API format. The endpoint can map custom field names, validate the incoming payload, and assign a default lead type so the lead reaches the right Sela campaign. Token authentication is required by default. Authentication may be disabled for an ingestion URL when agreed during setup. Contact support if your lead provider cannot send credentials.
# Create or Update a Lead from a Custom Payload
Source: https://docs.trysela.com/api-reference/lead-ingestion/create-or-update-a-lead-from-a-custom-payload
/Sela_API.yaml post /api/ingest-lead/{id}/upsert/
Creates or updates a Sela lead from a custom payload format. Use this when an external system, such as a lead provider, may resend updates for an existing lead. Sela matches existing leads by external ID, phone number, or email after applying the endpoint's configured field mapping. If no matching lead exists, a new lead is created and routed to the configured Sela campaign. Token authentication is required by default. Authentication may be disabled for an ingestion URL when agreed during setup. Contact support if your lead provider cannot send credentials.
# List Lead Types
Source: https://docs.trysela.com/api-reference/lead-types/list-lead-types
/Sela_API.yaml get /api/lead-types/
Returns the lead categories you can assign when creating or updating leads. Use this endpoint to discover the available lead_type IDs and the metadata fields each lead type accepts, so new leads can be routed and handled correctly.
# Retrieve a Lead Type
Source: https://docs.trysela.com/api-reference/lead-types/retrieve-a-lead-type
/Sela_API.yaml get /api/lead-types/{id}/
Returns details for one lead type, including the metadata fields accepted for leads in that category. Use this before creating leads when you need to confirm which metadata keys and value types to send.
# Bulk Create Leads
Source: https://docs.trysela.com/api-reference/leads/bulk-create-leads
/Sela_API.yaml post /api/leads/bulk-create/
Creates or reengages multiple leads in one request. Each item accepts the same fields as `POST /api/leads/`. Results preserve request order and report whether each item was created, reengaged, or failed validation.
# Bulk Update Leads
Source: https://docs.trysela.com/api-reference/leads/bulk-update-leads
/Sela_API.yaml patch /api/leads/bulk-update/
Updates multiple leads in one request. Each item must include an `id` and may include the same fields as `PATCH /api/leads/{id}/`. Results preserve request order and report whether each item was queued or failed request-level validation. Queued items are processed asynchronously in batches.
# Create a Lead
Source: https://docs.trysela.com/api-reference/leads/create-a-lead
/Sela_API.yaml post /api/leads/
Creates a lead for the authenticated API user. `phone_number` is required; `email`, `lead_type`, `external_id`, and `metadata` are optional. Use `GET /api/lead-types/` to discover available lead type IDs and their public metadata fields. Unknown top-level fields are preserved in `metadata`, which lets customer-specific values be used by the agent. If reengagement is configured and the payload matches an eligible existing lead, that lead is reengaged and returned with a 200 response instead of creating a duplicate.
# DNC a Phone Number
Source: https://docs.trysela.com/api-reference/leads/dnc-a-phone-number
/Sela_API.yaml post /api/leads/dnc-phone-number/
Marks a phone number as do not contact for the authenticated API user's account. If neither `call_dnc` nor `sms_dnc` is provided, both default to true (DNC both channels). If either flag is provided, the other must also be provided, and at least one of the two must be true. This endpoint only adds DNC: passing `false` for a channel does not un-DNC an existing record.
# List Leads
Source: https://docs.trysela.com/api-reference/leads/list-leads
/Sela_API.yaml get /api/leads/
Lists all leads.
# Retrieve a Lead
Source: https://docs.trysela.com/api-reference/leads/retrieve-a-lead
/Sela_API.yaml get /api/leads/{id}/
Retrieves a lead.
# Update a Lead
Source: https://docs.trysela.com/api-reference/leads/update-a-lead
/Sela_API.yaml patch /api/leads/{id}/
Partially updates a lead. Update requests may include lifecycle fields such as status, status_detail, sms_dnc, and call_dnc.
# Update a Lead with Phone / Email Match
Source: https://docs.trysela.com/api-reference/leads/update-a-lead-with-phone-email-match
/Sela_API.yaml put /api/leads/update/
Updates a lead a using the phone number and the email to find a matching lead.
# Update Live Call
Source: https://docs.trysela.com/api-reference/leads/update-live-call
/Sela_API.yaml patch /api/leads/{id}/live-call/
Updates a live call for this lead with connected representative information and other external identifiers. This endpoint is used when a customer's CRM notifies us that a loan officer picked up a transferred call. The endpoint will find the appropriate chat (using connected_timestamp if provided, otherwise an active call, a recent warm transfer, or a recent blind transfer/escalation) and link the representative to it. If no matching representative exists, a new one will be created. The external_id field is required and must be unique per company.
# Webhook Responses
Source: https://docs.trysela.com/api-reference/webhook
What we send you
## Trigger selection
Use [Integrating with Sela](/integrating-with-sela) to choose between call-level, terminal,
DNC, and reengagement updates. The full supported trigger enum is available in the
[Create a Webhook Subscription](/api-reference/webhooks/create-a-webhook-subscription)
endpoint documentation.
## Configuration
Webhooks created through the API send payloads in the format below. A subscription can
include static string-valued HTTP headers, such as an API key or bearer token. Header values
are encrypted at rest and are never returned by the API.
OAuth2 authentication is also supported, but its credentials must currently be configured
and attached to the webhook by the Sela team. Contact
[support@trysela.com](mailto:support@trysela.com) for OAuth2 or customized payload
requirements.
## Sample Payload
The exact fields depend on the trigger, lead configuration, and whether recent chat details
are enabled.
```json theme={null}
{
"id": 28013,
"email": "first_name@trysela.com",
"phone_number": "+18042221111",
"metadata": {
"phone_number": "+18042221111",
"email": "first_name@trysela.com",
"first_name": "First",
"last_name": "Name",
"timezone": "America/Los_Angeles",
"created_at": "02/28/2025 15:09",
"property_address": "123 Main St",
"property_city": "San Francisco",
"property_state": "California",
"property_zip": "94101",
"address": "456 2nd St",
"city": "Los Angeles",
"state": "California",
"zip": "90001",
"lead_source": "USDALoans.com",
"external_id": "id_in_your_crm_123"
},
"modified_time": "2026-01-05T11:30:20.764434-08:00",
"created_time": "2026-01-03T11:51:40.950747-08:00",
"status": "OPEN",
"status_reason": null,
"lead_type": 1234,
"next_call_time": "2026-01-05T21:59:01+00:00",
"next_call_time_reason": "NEXT_AVAILABLE_SLOT",
"external_id": "id_in_your_crm_123",
"us_state": "CA",
"lead_source": "USDALoans.com",
"received_time": "2026-01-03T11:51:40.943339-08:00",
"reengagements_count": 0,
"last_reengagement_time": null,
"call_schedule_start_time": null,
"sms_dnc": null,
"call_dnc": null,
"call_count": 5,
"last_chat": {
"id": 4357837,
"start_time": "2026-01-06T23:54:22.857000+00:00",
"end_time": "2026-01-06T23:54:33.899000+00:00",
"created_time": "2026-01-06T23:53:49.512728+00:00",
"call_created_time": "2026-01-06T23:53:49.651000+00:00",
"call_initiated_time": "2026-01-06T23:53:49.704000+00:00",
"call_ringing_started_time": "2026-01-06T23:53:51.033000+00:00",
"summary": "The user attempted to reach a borrower but was informed that the borrower is not available and was prompted to leave a message.",
"voicemail_status": "WENT_TO_VOICEMAIL",
"disconnection_reason": "agent_hangup",
"call_direction": "OUTBOUND",
"call_outcome": "WENT_TO_VOICEMAIL",
"is_contact": false,
"agent_nr": "+18042221112"
},
"webhook_trigger": "CALL_COMPLETE"
}
```
# Create a Webhook Subscription
Source: https://docs.trysela.com/api-reference/webhooks/create-a-webhook-subscription
/Sela_API.yaml post /api/webhooks/
Creates a webhook subscription for the authenticated API user. A subscription may listen for one or more trigger values. Outbound requests default to POST when method is omitted. URL placeholders such as `{{id}}` and `{{metadata.us_state}}` are populated from each webhook payload. Optional headers are encrypted at rest and are not returned by the API.
# Delete a Webhook Subscription
Source: https://docs.trysela.com/api-reference/webhooks/delete-a-webhook-subscription
/Sela_API.yaml delete /api/webhooks/{id}/
Permanently deletes one webhook subscription owned by the authenticated API user.
# Delete Webhook Subscriptions by URL
Source: https://docs.trysela.com/api-reference/webhooks/delete-webhook-subscriptions-by-url
/Sela_API.yaml delete /api/webhooks/unsubscribe/
Deletes every webhook subscription owned by the authenticated API user whose destination exactly matches the supplied URL.
# List Webhook Subscriptions
Source: https://docs.trysela.com/api-reference/webhooks/list-webhook-subscriptions
/Sela_API.yaml get /api/webhooks/
Returns the webhook subscriptions owned by the authenticated API user. Each subscription identifies the destination URL, outbound HTTP method, events that trigger delivery, and optional delivery filter. Secret headers are write-only and are never included in responses.
# Replay Recent Chat Webhooks
Source: https://docs.trysela.com/api-reference/webhooks/replay-recent-chat-webhooks
/Sela_API.yaml post /api/agents/webhooks/replay-recent-chat/
Queues webhook and configured integration-action deliveries using each requested lead's most recent chat. Only leads owned by the authenticated API user are processed; inaccessible lead IDs are skipped and counted in the response. Work is split into background-task chunks, so a 202 response means the replay was queued.
# Retrieve a Webhook Subscription
Source: https://docs.trysela.com/api-reference/webhooks/retrieve-a-webhook-subscription
/Sela_API.yaml get /api/webhooks/{id}/
Returns one webhook subscription owned by the authenticated API user. Secret headers are write-only and are never included in the response.
# Call Outcomes
Source: https://docs.trysela.com/call outcomes
### UNKNOWN
The call didn't reach a clear result.
### DIAL\_NO\_ANSWER
The call rang but the recipient did not answer. This will mostly be calls that did not go to voicemail and were declined.
### DIAL\_FAILED
The dial failed. Usually due to network issues, or a bad phone number.
### DIAL\_BUSY
The number was busy.
### WENT\_TO\_VOICEMAIL
The call went to voicemail, but Sela did not leave a message.
### LEFT\_VOICEMAIL
Sela reached voicemail and left a message.
### COMPLETED\_CLOSED\_LIVE\_TRANSFER
The call was successfully live transferred to a human agent.
### COMPLETED\_CLOSED\_OTHER
The lead was marked as closed without transferring, often due to scheduling a meeting on their calendar.
### COMPLETED\_STOP\_CALLING
The lead asked us to stop calling. This is not always a DNC request and includes when the lead is not interested, wrong number, or similar negative outcomes.
### COMPLETED\_LAST\_CALL
Sela completed the final scheduled call in the campaign.
### COMPLETED
The conversation finished, but did not match any other call outcomes.
# Features
Source: https://docs.trysela.com/features
Explore Sela's core sales, transfer, scheduling, and voicemail capabilities.
Need a capability or integration that is not listed here? Contact
[support@trysela.com](mailto:support@trysela.com) to discuss your requirements.
## Sales Skills
Sela agents are designed to conduct effective, natural sales conversations. They
support essential sales skills throughout each customer interaction:
* Discovery
* Qualification
* Objection handling
* Personalized pitching
## Warm Call Transfer
Sela manages the handoff between a customer and a loan officer from start to
finish. During the customer conversation, Sela can contact a loan officer to
confirm availability. Once both parties are ready, Sela connects the calls,
provides a brief introduction, and exits the conversation.
This coordinated process provides a more seamless experience than a cold transfer
or basic call forwarding.
## Metadata
Sela supports custom metadata for each lead, enabling agents to personalize their
conversations with relevant context. Fields included in lead creation or update
requests are stored automatically unless they are reserved for system use. This
metadata can then be incorporated into the agent's talk track.
## Scheduling
### Automatic callback scheduling
Sela agents can schedule and place callbacks at a customer's requested date and
time. For example, if a customer asks to be called the following day, the agent
schedules the follow-up and places the call at the appropriate time.
### Calendar integrations
Sela agents can check availability and book meetings through:
* Cal.com
* Calendly
* Microsoft Bookings
Contact [support@trysela.com](mailto:support@trysela.com) to discuss additional calendar integrations.
## Voicemail Detection
Sela can detect when a call reaches voicemail and leave a dynamic message tailored
to the conversation context.
***
## Next Steps
Learn how to integrate Sela with your systems or speak with an AI assistant.
Call Sela at (320) 446-4456 to schedule an onboarding meeting with an AI expert.
Plan how your systems send leads, handle transfers, and receive updates.
# Integrating with Sela
Source: https://docs.trysela.com/integrating-with-sela
Plan, build, and test an end-to-end Sela integration.
Most Sela integrations have four parts:
1. Sending leads to Sela
2. Handling live transfers
3. Letting Sela know when to stop calling
4. Receiving call and lead updates
This guide covers each part in the order most integrations build them, focusing on the main
decisions rather than field-by-field details. Full request and response definitions are
available in the API Reference.
Sela provides an API token during setup. Include it in the `Authorization` header of every
API request unless Sela has explicitly configured an unauthenticated endpoint for your
integration.
## Sending Leads to Sela
### Lead types
Every lead sent to Sela belongs to a lead type—commonly called a campaign. The lead type
determines how Sela handles the lead, including which configuration applies and which talk
track the agent follows. During setup, Sela creates a lead type for each of your use cases
and gives you its ID. You can see all lead types available to your account with
`GET /api/lead-types/`.
To see what metadata a specific lead type accepts, call `GET /api/lead-types/{id}/`. The
response describes the metadata fields configured for that lead type, including each
field's name, purpose, and expected format. These fields feed directly into the
conversation. A talk track may reference the lead's name, property information, loan
details, or other customer-specific data, so providing more complete information allows
for a more personalized call.
### Creating leads
Sela prefers a flat JSON payload, with standard and customer-specific fields sent together
as top-level keys. This keeps the request simple and lets most CRMs and lead providers send
data to Sela without restructuring it.
You are not limited to the fields in the lead type definition. Additional fields can
support routing, scheduling, transfers, customer-specific integrations, and other
functionality outside the talk track. Send all useful context you have when creating the
lead. Better source data helps the Sela agent personalize the conversation and avoid asking
for information you already know.
The default way to send a lead is `POST /api/leads/`. Use this endpoint whenever your
system can format its request using Sela's standard lead fields and the custom fields
configured for your lead type. The response includes the Sela lead ID. Store this ID—it
identifies the lead in future updates, including requests to stop calling.
Some lead sources cannot change the structure or destination format of their requests. In
those cases, Sela can optionally configure a customer-specific lead-ingest endpoint that
accepts the existing payload and transforms it into the format Sela needs. Use lead ingest
when the standard endpoint is not practical. Authentication can be optional for this
endpoint, allowing you to share its unique URL with a third-party lead provider without
also sharing your Sela API token.
### How Sela determines the lead's state and timezone
Before calling, Sela determines the lead's location and local time so it knows when a call
is allowed. It first looks for the lead's state in `us_state`, then `state`, and then
`property_state`. If none is available, it derives the state from `zip` and then
`property_zip`.
For the timezone, Sela uses an explicit `timezone` when you provide one. Otherwise, it
checks the contact ZIP code, contact state, property ZIP code, property state, and available
IP location information, in that order. If none of those identifies the location, Sela uses
a configured safe default timezone and calling window.
Once Sela knows the lead's local time, it applies the relevant federal, state-specific, and
account-level calling restrictions. Because inference is a fallback, provide accurate state
and ZIP information whenever possible.
## Live Transfer Flow
Live transfer functionality is optional and should be configured when your workflow
requires Sela to connect borrowers with a person during the call.
There are two ways to make this connection: a warm transfer, where Sela brings a loan
officer onto the call, and an escalation, where the call is forwarded directly.
### Warm transfer
During a warm transfer, the main Sela agent stays on the line with the borrower—the borrower
is never left waiting alone. In parallel, Sela creates a transfer sub-agent that places a
separate call, called the transfer leg, to your transfer destination and works to get a loan
officer on the line.
Once an officer is available, the transfer leg is joined with the borrower's call, bringing
the loan officer, borrower, and main Sela agent together for the handoff. The main agent
then leaves so the borrower and loan officer can continue speaking directly.
### Receiving queue and IVR behavior
How your receiving queue handles the transfer leg can make or break a warm transfer. After
the leg is answered, the line should remain silent while a loan officer is located.
Recorded messages, repeated announcements, or other unexpected audio can interfere with
the flow.
How long the queue should hold the transfer leg open depends on whether a loan officer can
realistically join:
* If an officer may become available within the next few minutes, keep the transfer leg
open for up to three minutes.
* If there is no chance an officer will answer—for example, because no one is signed
in—hang up immediately or do not ring at all. This lets Sela return to the borrower and
continue with the configured unavailable-transfer flow.
The rule of thumb is simple: give viable transfers enough time, and end impossible transfers
quickly. Holding the line open when no one can answer only wastes the borrower's time.
### Escalation
Escalation is a more direct path to a person than a warm transfer. It is generally triggered
when a borrower asks to speak with someone, says they do not want to continue with the AI,
or meets another customer-defined condition.
There is no transfer sub-agent or availability check; the call routes directly to the
escalation destination. That destination may differ from the loan-officer transfer queue,
allowing escalations to reach another team, such as customer support. Decide during setup
where escalations should go and what should happen if the destination does not answer.
### Receiving live lead updates
During the conversation, Sela may collect additional information from the borrower.
Optionally subscribe to the `LEAD_UPDATED` webhook to receive that information while the
call is still in progress.
These updates let your system refresh the lead record in real time, making the latest
details available to the loan officer before or during the handoff. The fields included
depend on what the configured talk track collects.
## Calendar Bookings (Optional)
Live transfers only work when someone is available immediately. Calendar integration
provides an optional fallback and is particularly useful when leads belong to specific loan
officers rather than whoever is next in a shared queue.
If the assigned officer misses a call or cannot join a live transfer, Sela can offer the
borrower an available meeting time and book it directly on that officer's calendar. The
borrower leaves the call with a confirmed follow-up, and the lead stays with its owner.
Two things must be in place:
1. The lead-to-loan-officer assignment must be visible to Sela so the correct calendar is
used. Confirm during setup which lead field identifies the assigned officer.
2. The officer's connected calendar must accurately reflect working hours, existing
meetings, time off, and other unavailable periods.
If you enable calendar booking, decide during setup when Sela should offer it: after the
assigned officer does not answer, after a warm transfer cannot be completed, or when the
borrower asks to speak at another time.
## Telling Sela to Stop Calling a Lead
Your CRM may learn that Sela should no longer call a lead—for example, because the borrower
converted through another channel or the file was withdrawn. Decide which conditions in
your workflow should stop Sela calls, and configure your CRM to update Sela whenever one
occurs.
When one of those conditions occurs, send `PATCH /api/leads/{sela_lead_id}/` using the Sela
lead ID returned when the lead was created, and set the lead's status to `CANCELLED`. This
is a simple stop instruction; your CRM can retain the detailed reason without translating
it into a Sela status.
DNC requests are distinct from cancellation. If a lead revokes consent to be
contacted—through your team, your CRM, or another channel—update the Sela lead with that DNC
information rather than only cancelling it. This ensures Sela records the consent
revocation and does not contact someone who has withdrawn consent.
For the full set, see the Lead Statuses and Call Outcomes pages in the Documentation tab.
## Receiving Updates from Sela
Sela sends updates to your systems through webhooks.
Decide early how you want to track Sela lead status in your systems: which statuses matter,
where they are stored, and what they should trigger. That decision determines which events
to subscribe to. DNC events should be part of every integration. Beyond that, the main
choice is between receiving an update after every call and receiving updates only when a
lead reaches a terminal status.
See [Webhook Responses](/api-reference/webhook) for payload structure and authentication
options.
### Receiving DNC updates
Subscribe to `CALL_DNC` when a lead requests no further calls and `SMS_DNC` when a lead
requests no further text messages. When either event arrives, record and enforce the
preference in your systems.
DNC status is also included in every webhook payload, so events such as `CALL_COMPLETE` or
`LEAD_LOST` capture it as well. Call and SMS preferences are independent, so a DNC request
on one channel applies only to that channel.
### Option 1: Receive every completed call
Subscribe to `CALL_COMPLETE` to receive a webhook after each completed Sela call, including
calls that do not produce a final lead outcome.
Choose this option when you want call-by-call activity in your CRM or want the lead record
updated throughout the Sela calling process. A single lead may produce many `CALL_COMPLETE`
events over its lifetime.
### Option 2: Receive terminal lead status changes
If you only need to know the final outcome for each lead, subscribe to the terminal lead
status events:
* `LEAD_CLOSED`
* `LEAD_CLOSED_INCOMPLETE`
* `LEAD_LOST`
* `LEAD_SCHEDULE_COMPLETED`
* `LEAD_BAD_NUMBER`
* `LEAD_OUT_OF_TERRITORY`
The last two events correspond to the terminal lead statuses `BAD_NUMBER` and
`OUT_OF_TERRITORY`.
This option produces far fewer updates than `CALL_COMPLETE`, typically one final outcome
per lead lifecycle. Choose between these options with Sela during integration setup.
### Testing webhooks without placing a call
After configuring your webhook subscriptions, you can test them without placing another
call by using:
`POST /api/agents/webhooks/replay-recent-chat/`
Provide the Sela lead IDs and webhook triggers you want to test:
```json theme={null}
{
"lead_ids": [123],
"triggers": ["CALL_COMPLETE"]
}
```
Sela builds the webhook payload from each lead's most recent completed call and sends it to
the subscriptions configured for the requested triggers. The lead must belong to the
authenticated API user and have at least one completed Sela call.
The endpoint queues delivery asynchronously and returns `202 Accepted`; this confirms that
the replay was queued, not that your destination successfully processed it. Verify receipt,
authentication, field mapping, and idempotent handling in your system. Replaying a webhook
does not place a new call or change the lead's status.
## When a Newer Lead Replaces an Older One
Sometimes a lead already sent to Sela arrives again as a newer version—for example, when
the same person fills out another form. Sela calls this reengagement.
Rather than creating a second lead, Sela keeps the existing lead record and overwrites its
data with the newer metadata. This can replace the lead's `external_id`, which is its ID in
your CRM. Future updates are then associated with the newer CRM lead ID, and the older
record stops receiving updates.
If your CRM needs to know before this happens, subscribe to `LEAD_BEFORE_REENGAGEMENT`. This
event fires before the overwrite and identifies the older CRM lead that is about to stop
being called and updated. Use it to close the old record, link it to the newer one, or
otherwise preserve your internal lead history.
This subscription is recommended when you need to track newer duplicates replacing older
CRM leads.
## Testing the Integration
* [ ] Create a lead and confirm that it is connected to the correct campaign with the
expected metadata.
* [ ] If warm transfers are enabled, run a transfer with a loan officer available. Confirm
that the transfer sub-agent reaches the officer and that the participants are joined
correctly.
* [ ] If warm transfers are enabled, run the flow with no loan officers available. Confirm
that Sela follows the configured unavailable-transfer behavior.
* [ ] If calendar booking is enabled, confirm that Sela offers valid times from the correct
officer's calendar and creates the booking successfully.
* [ ] Send a `CANCELLED` update using the Sela lead ID. Confirm Sela stops calling the lead.
* [ ] Trigger `CALL_DNC` and `SMS_DNC` separately. Confirm that each event updates the
correct channel in your systems.
* [ ] Use the webhook replay endpoint to test each configured subscription and trigger
without placing another call.
* [ ] Verify that information gathered during a call is communicated correctly back into
your CRM.
# Lead Statuses
Source: https://docs.trysela.com/lead statuses
### NEW
The lead has been created. This status may also be assigned when Sela receives an
inbound call from a phone number that is not associated with an existing lead.
### OPEN
Sela is actively engaging the lead. Most leads remain in this status during
normal outreach.
### CALLBACK\_TO\_TRANSFER
The lead will be called back for a transfer to a loan officer. This commonly
occurs when the lead completes the talk track and requests a transfer outside
the loan officer's transfer hours.
### LOST
Sela has stopped outreach to the lead, typically because the contact declined
further engagement or requested no further contact. Channel-specific do-not-contact
preferences are tracked separately from this status.
### CLOSED
The lead has been transferred to a loan officer or, when calendar scheduling is
configured, has booked a call on the loan officer's calendar.
### CLOSED\_INCOMPLETE
The lead is closed without full resolution, typically because the contact
requested human assistance but the interaction did not result in a completed
transfer or booking.
### BAD\_NUMBER
Sela could not reach the lead after multiple attempts. The phone number appears
invalid or unreachable.
### SCHEDULE\_COMPLETED
All scheduled calls for this lead have been completed.
### OUT\_OF\_TERRITORY
The lead cannot be dialed because the phone number is outside Sela's supported
calling regions.
### CANCELLED
Outreach to the lead was cancelled through an API update or the Sela application.
The lead will no longer be called.
### UNKNOWN
A fallback status used only when no other status applies.
# Okta Integration
Source: https://docs.trysela.com/okta integration
Create an Okta OIDC web application and share connection details with Sela for single sign-on.
## Configure SSO
In Okta Admin → **Applications → Applications → Create App Integration**, use these
settings:
1. **Sign-in method:** OIDC - OpenID Connect
2. **Application type:** Web Application
3. **App integration name:** e.g. `Sela`
4. **Grant type:** Authorization Code only
5. **Sign-in redirect URI:** `https://id.trysela.com/login/callback`
6. **Sign-out redirect URI:** leave blank
7. **Controlled access:** assign the users/groups who should use Sela
8. **Save**
On the app’s **General** tab, confirm **Client authentication = Client secret**, then
securely share:
* **Client ID**
* **Client Secret**
* **Okta domain** (e.g. `your-org.okta.com`)
Do **not** set Initiate login URI or tile visibility yet — wait until Sela confirms
the connection is ready, then continue to step 3.
After Sela confirms setup, open the Okta app → **General → Edit** and set:
1. **Initiate login URI** to:
```text theme={null}
https://tower.trysela.com/login/?organization_name=
```
Replace `` with your Sela organization name (e.g. `acme`).
2. **Application visibility:** enable **Display application icon to users**
3. **Save**
# Okta SCIM Provisioning
Source: https://docs.trysela.com/scim-provisioning
Provision and deprovision Sela users and groups from Okta using SCIM 2.0.
Use this guide to manage Sela users and groups from Okta. SCIM provisioning uses a
separate Okta application from the OIDC application used for
[single sign-on](/okta%20integration).
Treat the SCIM bearer token like a password. Store and share it only through an
approved secrets manager. Never send it through ordinary email or include it in
a support ticket.
## Before you begin
Ask your Sela contact for:
* Your **SCIM Base URL**
* Your **SCIM Bearer Token**
You also need Okta administrator access that allows you to add applications and
assign users and groups.
## Configure SCIM
In Okta Admin:
1. Open **Applications → Browse App Catalog**.
2. Search for **(OAuth Bearer Token) Governance with SCIM 2.0**.
3. Select the application and click **Add Integration**.
4. Set **Application label** to `Sela SCIM`.
5. Enable **Do not display application icon to users**.
6. Disable **Browser plugin auto-submit**.
7. Click **Next**, then **Done**.
This application handles provisioning only. Do not replace or modify your
existing Sela OIDC application.
Open the new **Sela SCIM** application, then:
1. Open **Provisioning → Integration**.
2. Click **Configure API Integration**.
3. Enable **API Integration**.
4. Enter the **SCIM 2.0 Base URL** provided by Sela.
5. Enter the **OAuth Bearer Token** provided by Sela.
6. Click **Test API Credentials**.
7. After Okta reports a successful connection, click **Save**.
Enter the Base URL exactly as provided, without adding a trailing slash.
Open **Provisioning → To App**, click **Edit**, and configure:
* **Create Users:** enabled
* **Update User Attributes:** enabled
* **Deactivate Users:** enabled
* **Sync Password:** disabled
* **Set password when creating new users:** disabled
Click **Save**.
Under **Provisioning → To App → Attribute Mappings**, keep the mappings that
send these required values:
* **User name**
* **First name**
* **Last name**
* **Primary email**
Keep the system-managed **external ID** and **active status** fields if Okta
displays them. Remove every other optional mapping unless Sela has asked you
to provision that attribute.
In particular, remove these default type mappings if they are present because
they can cause user update requests to fail:
* **Primary email type**
* **Primary phone type**
* **Address type**
Open the **Assignments** tab and assign the people or groups that Okta should
provision into Sela.
Users who need to sign in must also be assigned to the separate Sela SSO
application. Assigning a group to the SCIM application provisions its users,
but does not push the group object itself.
To provision group objects and memberships:
1. Open the **Push Groups** tab.
2. Select **Push Groups → Find groups by name**.
3. Choose the group to send to Sela.
4. Confirm the match and click **Save**.
5. Repeat for each group Sela should receive.
## Verify the integration
Start with one test user and one test group before assigning production users:
1. Assign the test user to the **Sela SCIM** application.
2. Confirm the assignment reaches a provisioned state in Okta.
3. Ask your Sela contact to confirm that the user and pushed group arrived.
4. Update the user's first or last name and confirm the update is synchronized.
5. Unassign the user and confirm that the user is deactivated in Sela.
## Troubleshooting
### Test API Credentials returns 401
Re-enter the bearer token. If the token was lost or rotated, ask Sela for a new
token.
### Test API Credentials fails with the correct token
Confirm that the SCIM Base URL has no trailing slash and was copied exactly as
provided.
### Users are not provisioned
Confirm that **Create Users** is enabled and that the user is assigned to the
SCIM application.
### User updates fail
Confirm that **Update User Attributes** is enabled and remove the three type
mappings listed above. Also confirm that all required mappings remain configured.
### Groups do not appear
Assigning a group to the application provisions its users but does not push the
group object. Configure the group separately under **Push Groups**.
# Zapier Integration
Source: https://docs.trysela.com/zapier integration
An easy way to use our API is via our [Zapier Integration](https://zapier.com/developer/public-invite/210854/dd9be7ffa8e19d216a5a24ea99984123/). If you need full transparency and increased flexibility, you can use our API directly.