Skip to main content
Use this reference to interpret a rejection label Rain returns on a webhook, whether it’s temporary (fixable) or final (permanent), and to decide what to do about it. For every rejection reason grouped the way the Dashboard groups them, including the Reason and Reason ID behind each label, see the rejection catalog.

Webhook rejection label reference

The user.updated and company.updated webhooks include an applicationReason field containing one or more rejection labels that describe why an application was rejected. Parsing the field: applicationReason may contain multiple comma-separated labels (for example, "DUPLICATE, REGULATIONS_VIOLATIONS"). Split the string by comma, trim whitespace from each token (for example, token.trim() or equivalent), and discard any empty strings before looking up each label. The following table lists the labels Rain has seen in production that carry a recommended action, sorted alphabetically. Each one includes its category, whether the rejection is temporary (fixable) or final (permanent), and what to do about it. For labels not listed here, look up the reason group in the rejection catalog:
The label ESIGN_FAILED has been observed in production but is not yet formally documented. If you encounter this label, contact Rain support for guidance. This section will be updated once the label definition is confirmed with the compliance team.

Understanding multi-label responses

Some rejections produce multiple labels because a single verification failure maps to more than one concern. When applicationReason contains multiple labels, treat the full set as the reason. Do not pick one and ignore the rest. The following table lists the most common multi-label combinations observed in production. One severity per response: multi-label responses always share the same severity. You will not receive a mix of temporary and final labels in a single applicationReason string.

Temporary vs. final rejections

Rejection labels fall into two categories:
  • Temporary: the issue is fixable. A label with this severity moves the applicationStatus to needsInformation, and the user can correct the problem and resubmit. Redirect them to the applicationCompletionLink, or resubmit the corrected information through the update endpoints. See Application states for both approaches.
  • Final: the rejection is permanent. The user cannot reapply. The applicationStatus will be denied. See the rejection catalog for the full breakdown by group.
needsVerification is not a rejection outcome. It means the applicant has not submitted any documents yet, so no applicationReason label applies. See Application states for what triggers it and why the API resubmission approach for needsInformation does not apply there.
Do not prompt the user to resubmit documents when you receive a final rejection label. Final rejections are permanent and cannot be overturned through resubmission.

What’s next

Application states

How rejections map to application states.

Rejection catalog

Every rejection reason by group, temporary and final.

Troubleshoot verification

Fix common verification issues.