Guides
Start typing to search…

Renegotiations

To request a new Renegotiation, you can use this endpoint:

POST /loans/{uuid}/schedule-requests

{
  "type": "due_date_adjustment",
  "proposed_schedule": {
    "installments": [
      {
        "due_date": "2025-09-30", // YYYY-MM-DD
        "fixed_amount": 500.0
      },
			{
        "due_date": "2025-10-30",
        "fixed_amount": 500.0
      },
			{
        "due_date": "2025-12-30",
        "fixed_amount": 500.0
      }
    ]
  },
  "reason": "Any specific text you want to add, min 20 chars",
  
  "approved_by_name": "John Doe", // required only when doing a "loss_risk_agreement"
  "discount": 150.0 // used only when doing a "loss_risk_agreement"
}

The full documentation of the endpoint is available in our API Swagger

Based on the request, we'll run some validations according to the required business rules, depending on the Provider needs. Some rules are configurable, like min interest rate, max installments, etc.

The possible values in the type field are:

  • due_date_adjustment: When you need to only adjust the installments due date, without bypassing the last installment due date nor change the insterest rate
  • term_extension_restructuring: Restructuring with term extension (up to facility max installments, e.g.: 12 installment). Allows up to 2 renegotiations of this type per contract, with a maximum total length of 12 installments. Only permitted for contracts in good standing or less than 30 days past due. The renegotiated interest rate cannot be lower than 6.79% per month, a limit established based on the effective cost of funding via CR.
  • loss_risk_agreement: Allowed for contracts with a default period of more than 90 days. Allows for interest discounts and flexible terms, with a maximum grace period of 60 days (will be validated based on the first installment due date). The renegotiated interest rate cannot be lower than 6.79% per month, ensuring that the cost of the credit operation remains lower than the return for CR investors.Requires formal justification, by sending the field approved_by_name with the name of the approver, otherwise the request will be rejected.

Case any rule isn't meet, the API will return a HTTP 400 - Bad Request, with field informing the reason, like:

  • error_code: A slug indicating why the request wasn't approved. The possible values are: 
    no_active_schedule
no_proposed_schedule
no_installments
invalid_due_date
low_interest_rate
max_due_date_exceeded
max_installments_exceeded
grace_period_exceeded
max_renegotiations_exceeded
approver_not_allowed
type_not_supported
interest_rate_changed
invalid_installments
not_default_enough
justification_required
invalid_discount
  • error_message: A more detailed text (in English) explaining the rejection.

If everything is ok with the validations, you'll receive a HTTP 201 - Created, and a specific response structure that ou can check in our API Swagger. It's a good idea to save schedule_request_uuid so that you can make further queries later, and also to compare with the webhooks we'll send you in specific points of the flow.

Schedule Request Webhooks

We'll send you webhooks notifying of some the status changes of the Schedule Request status.

{
  "created_at": "YYYY-MM-DDTHH:MM:SSZ",
  "event": "repayment_schedule_request_status_changed",
  "payload":  {
    "uuid": "<schedule_request_uuid>",
    "status": "contract_sent",
    "type": "addendum",
    "contract_type": "due_date_adjustment",
    "loan_uuid": "<loan_uuid>",
  }
}
{
  "created_at": "YYYY-MM-DDTHH:MM:SSZ",
  "event": "repayment_schedule_request_status_changed",
  "payload":  {
    "uuid": "<schedule_request_uuid>",
    "status": "contract_signed",
    "type": "addendum",
    "contract_type": "due_date_adjustment",
    "loan_uuid": "<loan_uuid>",
  }
}
{
  "created_at": "YYYY-MM-DDTHH:MM:SSZ",
  "event": "repayment_schedule_request_status_changed",
  "payload":  {
    "uuid": "<schedule_request_uuid>",
    "status": "finished",
    "type": "addendum",
    "contract_type": "due_date_adjustment",
    "loan_uuid": "<loan_uuid>",
  }
}

Webhook meanings:

  • Contract Sent:
    The contract was rendered and sent to the signers to be signed throught the DocuSign platform. The signers include the Borrower itself, the Witnesses, and the Collection Agent (Securitizadora). For the borrower, we'll use the preferred_contact_method in the production environment as delivery method of the contract link, it can be whatsapp or email. In sandbox we'll always use email.
  • Contract Signed:
    All required signers already signed, and the flow can proceed to the next step
  • Finished:
    The "old" Loan's repayment schedule was deactivated, any QR Code and/or Boleto were canceled, a new repayment schedule was creted according to the initial proposed schedule, and the new QR Codes and/or Boletos were issued and are now available for this schedule in the Loan.

Updated 20 days ago