Skip to main content
DELETE
Remove borrowers from monitoring

Remove Borrowers from Monitoring

Stop monitoring a batch of borrowers in a single call. Send up to 1000 identifiers per request — the same authorizer_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 with obligations, send obligations to stop collecting one of them and keep collecting the rest — for example on the day you re-present an installment yourself:
Send 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.
If your enrollment push is a full file of your book, take removed borrowers out of the file. A borrower or obligation you remove today and re-send tomorrow is monitored again tomorrow — for borrowers removed because they must not be contacted or debited, keeping them out of the push is what keeps them removed.

Reading the response

The response is 200, 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.
A consistently non-zero unknown count usually means the wrong identifier is being sent — a loan number where the enrollment used a customer id, or an identifier that changes between systems. Those borrowers stay monitored until a removal names them correctly.

Removing versus deleting

This endpoint stops monitoring and keeps the borrower’s data. To also remove the borrower’s stored details, use DELETE /v1/persisted_authorizers — the stronger action, which stops monitoring too. Payment history is kept either way as the audit trail.

Authorizations

Authorization
string
header
required

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

application/json

Send authorizer_unique_ids, obligations, or both; at least one entry in total.

authorizer_unique_ids
string[]

The identifiers of the borrowers to stop monitoring — the same authorizer_unique_id values you sent on enrollment. Stops every obligation the borrower has.

Maximum array length: 1000
obligations
object[]

Single obligations to stop collecting, leaving the borrower's other obligations monitored.

Maximum array length: 1000

Response

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.

removed
integer

Borrowers whose live monitoring was stopped by this request.

not_monitored
integer

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.

unknown
integer

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.

results
object[]