Verification Statuses

Verifications move through a series of statuses from submission to completion. Understanding these statuses is essential for building a robust integration.

Status overview

The verificationStatus field indicates the current state of a verification. Each status change triggers a webhook notification to your registered endpoint.

Entity verification flow

After submission, a verification typically follows this flow:

1. Submitted to pending: Verification is queued for processing
2. pending to verified / rejected / info: Processing completes with a result
3. info to pending: After missing information is provided, returns to processing
4. The cycle can repeat until reaching a terminal state (verified or rejected)

Status details

new

The verification entry exists but no data has been submitted yet. This status is returned when:

• A trace identifier has been created (e.g., via form creation)
• No entity data has been submitted for verification

Response includes:

• trace - The verification trace identifier
• userId - Your internal user identifier (if provided during form creation)
• onBehalfUid - The onBehalf account UID (if applicable)
• submissionStatus - Current submission status (typically new)
• verificationStatus - Set to new
• message - Explanation that entity has not been submitted
• Entity fields (country, type, name, etc.) will be null

What to do: Submit entity data using POST /v5/verifications to begin the verification process.

pending

The verification has been submitted and is being processed. This is typically the first status after submission.

What to do: Wait for a webhook notification with the next status. Processing times vary:

• Median: Under 15 minutes
• Extended cases: Up to 24-48 hours (during registry maintenance or high load)

info

Additional information is required to complete the verification. This typically means:

• Additional documents are needed (e.g., trust deed, certificate of incorporation)
• Additional stakeholders need to be verified (e.g., directors, beneficial owners)

What to do:

1. Fetch the remainingActions using GET /v5/verifications/:trace
2. Upload any requested documents using PUT /v5/verifications/:trace/documents/:documentId
3. Direct stakeholders to complete their verification using the provided formUrl

See Provide Missing Information for detailed instructions.

verified

The verification was successful and satisfies the bronID verification requirements.

What to do: Update your system to reflect the successful verification. The customer can proceed with your onboarding flow.

Response includes:

• Summary entity data
• IDV risk score
• Verification timestamp

What to do:

1. Read detailed verification information
2. Read detailed stakeholder information
3. Read detailed document information
4. Update your system to reflect the successful verification

rejected

The verification requirements were not met. Common reasons include:

• Entity could not be found in the relevant registry
• Incorrect entity details were submitted
• Document verification failed
• Stakeholder verification failed

What to do:

1. Fetch rejection details using GET /v5/verifications/:trace
2. Review the rejectionReasons array for specific issues
3. If correctable, submit a new verification with corrected information

error

A system error occurred during processing. This is rare and typically indicates a temporary issue.

What to do: Contact bronID support if the error persists. You may retry the verification after a short delay.

locked

This status indicates too many unsuccessful verification attempts. No further attempts will be processed for this entry.

What to do: Submit a new verification with a new userId if the customer needs to retry.

Submission status

In addition to verificationStatus, the submissionStatus field tracks the data collection state:

Best practices

Design for asynchronous processing

Processing times can range from seconds to hours. Design your flow so that:

• Users do not wait on a loading screen for verification results
• Status updates are communicated via email or in-app notifications
• Your system polls or listens for webhook updates

Handle all statuses

Ensure your integration handles all possible status transitions.

Use webhooks

Rather than polling the API, configure webhooks to receive real-time status updates. This is more efficient and provides immediate notifications.