Skip to main content
Use origination enrollment to replace manual customer-list uploads with API requests. Send a whole list in one batch request 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. New leads use PendingLoanNewLead. Returning borrowers use PendingLoanReturning; add oneOff: true for a single call.
  3. For lists, use Enroll a List (Batch) and follow the returned job ID. For individual records, enroll the application 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 Retrieve a Scheduled Call for the current status, and retrieve call history for completed calls. HTTP 200 means the schedule is saved, not that a call has connected.
Use the complete request examples to test each enabled mode with your account manager and approved test numbers.

​
Which endpoint should I use?

The three enrollment rows are options on one endpoint, not three separate endpoints. Sync Customer Schedules 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 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 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. Use Close Origination, POST /originations/{id}/close, with the application’s external loanId and a required reason: FUNDED, WITHDRAWN, or REJECTED. It records the final outcome and cancels the application’s active/paused cadences and pending work. Retrieve the accepted catalog with List Origination Close Reasons. Retry an uncertain close with the same reference and reason. Do not send a new enrollment as a cancellation signal, and validate this workflow before replacing an existing funded/stop upload. Already-funded loans that are active in collections are not eligible for this endpoint and return 409. Use the collections lifecycle API for those loans. A FUNDED close reports the outcome of an enrolled origination application; it does not close an active collections loan.