Skip to main content
POST
Adjust disbursement date
Shifts the effective disbursal date on an Active loan. Use this when the partner’s wallet credit was delayed (e.g. pending → confirmed two days later) and the LMS-recorded disbursement date no longer matches the day the customer actually received the money. Interest re-accrues from the new date, and the repaymentSchedule is recalculated so the next due-date math matches reality.
A loan with recorded repayments is rejected with 409 aborted. The adjustment reverses and re-books the disbursement, which would cascade-reverse any repayments — so erasing them must be an explicit choice. Reverse the repayment(s) first, then adjust.

Date constraints

  • The new date must not be in the future — pass today or any past day.
  • The new date must not be before the loan’s approval date. Because POST /v1/loans approves on the same day it disburses, the new date must be on or after the original disbursement date.
For the realistic delayed-wallet flow both constraints are satisfied naturally: the partner calls this endpoint on the day the wallet credit actually confirms, which is between the original approval/disbursement day and today. Two equivalent forms — prefer the externalId form for partner integrations.

Path parameters

string
required
The loan’s externalId. On the /v1/loans/{loan_id}/adjust-disbursement-date form, this is the numeric LMS id instead.

Request body

string
required
ISO-8601 YYYY-MM-DD. The corrected disbursal date.
string
Optional. Reason for the adjustment, captured in the LMS audit log.

Examples

Response

200 OK returns the loan object with the new disbursal date, recomputed schedule, and adjusted next-due fields.

How it works

The wrapper performs undo-disbursal then re-disburse against the LMS with the corrected date. These are two separate LMS commands, so the wrapper makes them atomic from the partner’s point of view: it records the current disbursement date first, and if re-disbursing at the new date fails it automatically rolls the loan back to the original date. Either the adjustment succeeds (loan Active, new schedule), or it fails cleanly with the loan left in its original Active state — the loan is never stranded in Approved. The only exception is the rare case where the re-disbursal and the automatic rollback both fail; the response is then a 500 whose message states the loan is in Approved and names the original date to re-disburse manually.

Errors