Remove Borrowers from Monitoring
Stop monitoring a batch of borrowers without deleting anything about them
Remove Borrowers from Monitoring
Stop monitoring a batch of borrowers in a single call. Send up to 1000 identifiers per request — the sameauthorizer_unique_id values you enrolled them with.
Use it for cured accounts, payoffs, and any borrower who must not be contacted or debited. Removal takes effect immediately: no new payment is initiated for these borrowers after the call returns.
Nothing about the borrower is deleted. Their details and payment history are kept, and results already collected remain available.
Removing a single obligation
For a borrower enrolled withobligations, send obligations to stop collecting one of them and keep collecting the rest — for example on the day you re-present an installment yourself:
authorizer_unique_ids, obligations, or both in one request. Removing a borrower by authorizer_unique_id stops every obligation they have.
Each obligation you send gets its own entry in results, after the borrower entries, carrying its obligation_id. The outcomes mean the same as for a borrower: removed if it was being collected, not_monitored if the borrower is known but that obligation was not being collected, and unknown if Rightfoot has no record of the borrower.
Removal is not sticky
Sending a removed borrower in a later enrollment push is read as intent to resume, and starts fresh monitoring using the amount in that push. The same goes for a removed obligation sent again in a later push.Reading the response
The response is200, and every identifier you sent has an entry in results, in the order you sent them. Check each outcome rather than relying on the status code.
not_monitored is normal, not an error. Monitoring expires 30 days after it starts, so a borrower who left your enrollment file weeks ago has usually lapsed on their own by the time a cleanup removal arrives. Re-sending a removal also lands every borrower here — the request is safe to retry.
Removing versus deleting
This endpoint stops monitoring and keeps the borrower’s data. To also remove the borrower’s stored details, useDELETE /v1/persisted_authorizers — the stronger action, which stops monitoring too. Payment history is kept either way as the audit trail.Authorizations
Authentication to the API is performed via Bearer Token Authentication. Provide your API key as the bearer token in the Authorization header.
All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.
Body
Send authorizer_unique_ids, obligations, or both; at least one entry in total.
The identifiers of the borrowers to stop monitoring — the same
authorizer_unique_id values you sent on enrollment. Stops every
obligation the borrower has.
1000Single obligations to stop collecting, leaving the borrower's other obligations monitored.
1000Response
Batch processed. Every identifier in the request has an entry in
results; inspect each outcome rather than relying on the status
code.
Counts plus one result per identifier or obligation sent. The counts sum
to the number of entries in results.
Borrowers whose live monitoring was stopped by this request.
Borrowers Rightfoot knows but was not monitoring — monitoring had already expired or been stopped, or never started. Re-sending a removal lands every borrower here, so a repeated request is safe.
Identifiers Rightfoot has no record of. A consistently non-zero count usually means the wrong identifier is being sent — those borrowers are not removed from monitoring.
