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.

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 collectable_amount in that push.
If your enrollment push is a full file of your book, take removed borrowers out of the file. A borrower 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
authorizer_unique_ids
string[]
required

The identifiers of the borrowers to stop monitoring — the same authorizer_unique_id values you sent on enrollment.

Required array length: 1 - 1000 elements

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, in the order you sent them. The counts sum to the number of identifiers in the request.

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[]