> ## Documentation Index
> Fetch the complete documentation index at: https://docs.finosu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Origination Overview

> Start new-lead, returning-borrower, and one-off outreach using your existing cadences.

Use origination enrollment to replace manual customer-list uploads with API
requests. Send a [whole list in one batch request](/api-reference/origination/batch)
or enroll an individual application. Finosu creates or reuses each customer and
enrolls the application in the configured calling cadence.

## Start here

1. Obtain an API key for each company you will send records to, and confirm which
   outreach modes are enabled. The key determines the company; a request cannot
   select another company by changing a body field.
2. Choose the appropriate [task type](/api-reference/endpoint/task-types/list).
   New leads use `PendingLoanNewLead`. Returning borrowers use
   `PendingLoanReturning`; add `oneOff: true` for a single call.
3. For lists, use [Enroll a List (Batch)](/api-reference/origination/batch) and
   follow the returned job ID. For individual records, [enroll the application](/api-reference/endpoint/customers/origination-enrollment)
   with `scheduleMode: "enroll"`, the customer and application references, and a
   stable `Idempotency-Key`. No separate customer-create or scheduled-calls request
   is required.
4. For individual enrollment, save the returned receipt. Follow its `scheduledCallId` using
   [Get Scheduled Call](/api-reference/endpoint/scheduled-calls/get-by-id) for the
   current status, and retrieve [call history](/api-reference/endpoint/calls/list)
   for completed calls. HTTP `200` means the schedule is saved, not that a call
   has connected.

Use the [complete request examples](/api-reference/origination/examples) to test
each enabled mode with your account manager and approved test numbers.

## Which endpoint should I use?

| Action | Endpoint | What to send |
| - | - | - |
| Enroll a whole list | `POST /customers/batch` | Outer `scheduleMode: "enroll"`, a header `Idempotency-Key`, and a row `idempotencyKey` for every application |
| Track list progress and each row | `GET /customers/batch/{jobId}` | The job ID and the same company API key |
| Discover origination task-type names | `GET /origination/task-types` | Your company API key; this catalog does not confirm company enablement |
| Enroll a new lead | `POST /customers/schedule/sync` | `scheduleMode: "enroll"`, `taskType: "PendingLoanNewLead"`, and `Idempotency-Key` |
| Enroll a returning borrower | `POST /customers/schedule/sync` | `scheduleMode: "enroll"`, `taskType: "PendingLoanReturning"`, and `Idempotency-Key` |
| Enroll a returning borrower for one call | `POST /customers/schedule/sync` | The returning request with `oneOff: true` |
| Read a scheduled call's current status | `GET /scheduled-calls/{id}` | The `scheduledCallId` from the enrollment receipt |

The three enrollment rows are **options on one endpoint**, not three separate
endpoints. [Customer Schedule Sync](/api-reference/endpoint/customers/schedule-sync)
is the shared API reference and playground. Its replacement mode is for existing
integrations that intentionally rebuild pending schedules; it is not the
origination enrollment workflow. Always send `scheduleMode: "enroll"` here.

`taskType` is not the `scheduleType` used by the separate legacy
[Create Scheduled Calls](/api-reference/endpoint/scheduled-calls/create) operation.

## Sending an existing list

* Keep customer and application references consistent with prior uploads so the
  API can recognize an existing enrollment.
* Send the list in one [batch enrollment request](/api-reference/origination/batch)
  using the key for its company. Finosu divides and processes it internally.
* Keep a stable key for the list and a stable key per enrollment row. Retry an
  uncertain submission with the same list and header key.
* Save the job ID, monitor progress, and reconcile every row result. A rejected
  row does not prevent valid rows from enrolling.
* Batch submission permits 10 requests/minute/company; individual enrollment
  permits 60. Honor `Retry-After` and the documented list-size limits.

The existing scheduler continues to apply calling windows, business-day rules,
contact restrictions, phone rotation, and the configured transfer routing. API
enrollment does not let the sender override those settings.

## Funded applications and stopping outreach

Enrollment is an **intake** operation. It does not mark an application as funded,
cancel a cadence, restart a finished cadence, or write call notes and flags back
to your LMS.

Before replacing a funded/stop upload, agree on and test its API workflow with
your account manager. Cancelling individual pending calls is not evidence that
the parent cadence has stopped. Keep your existing funded/stop process until its
replacement is validated; do not send a new enrollment as a cancellation signal.