Skip to main content
All examples use POST /customers/schedule/sync with scheduleMode: "enroll". Replace YOUR_API_KEY with the key for the intended company. Confirm that the mode is enabled, and use account-manager-approved test records and phone numbers before sending real customers. The identities below are fictional. The enrollment guide defines required fields, spreadsheet mappings, cadence behavior, and error codes. Each example uses a different customer and application so testing one mode does not conflict with another mode’s active schedule.

​
New lead

Creates the configured new-lead cadence. daysInApplied supplies application-age context; it does not skip cadence steps.

​
Returning borrower / react

daysSincePaidOff selects the returning cadence relative to the previous payoff. If you omit this field, enrollment creates an initial call using the normal returning flow, which may include a mobile fallback; it does not create the payoff-based cadence.

​
Returning borrower / one-off

oneOff: true creates exactly one scheduled call, without mobile fallback. It is an option on PendingLoanReturning, not another task type. Do not use it with PendingLoanNewLead.

​
Read the result and retry safely

  • 200, origination.status: "scheduled": save the receipt, scheduleId, and scheduledCallId. Scheduling succeeded; a connected call is not guaranteed.
  • 200, Idempotency-Replayed: true: this is the saved result of the original request, not a new set of calls. Its counts are the original receipt’s counts.
  • 200, origination.status: "already_scheduled": the application already has a matching active cadence. No additional calls were created and customer data was not updated. Top-level contact fields are built from your normalized request, with phoneNumber falling back to mobilePhone; they do not confirm that those changes were saved. See Response for the full response semantics, including the fixed doNotCall: false value.
  • Timeout or 503: retry the same request with the same idempotency key; honor Retry-After when present and use exponential backoff with jitter.
  • 429: wait for Retry-After before retrying the same request. The quota is shared across keys for the same company.
  • 409 with detail.code: "request_in_progress": retry the same request after Retry-After.
  • Other 409: review the conflict. Do not change keys to bypass an existing application, contact restriction, or finished/paused cadence.
  • 400, 401, or 422: correct the account configuration, authentication, or invalid input before resubmitting. Do not blindly retry rejected records.
Repeating the exact cURL request above demonstrates a retry. Changing its key is not a retry strategy and does not authorize restarting a completed cadence. For a list, persist each record’s payload, idempotency key, and outcome on your side. Retry only unresolved records and reconcile successful, already-scheduled, and rejected records before retiring the corresponding manual upload. Funded/stop events require a separate validated workflow; see Funded applications and stopping outreach.