Provide missing information

Sometimes customers don't provide enough information to complete the verification of an entity. When this happens, you will receive a webhook with verificationStatus: "info" to let you know that additional information is required. The missing information can be regarding documents or stakeholders (individuals) related to the entity.

Sample info webhook

When a verification transitions to info status, you will receive a webhook with the following structure:

Info webhook payload

{
	"userId": "user-123",
	"onBehalfUid": null,
	"trace": "abc123-verification-trace",
	"submissionId": "abc123-submission-id",
	"submissionStatus": "in_progress",
	"verificationStatus": "info",
	"inputRisk": "medium",
	"country": "AUS",
	"type": "company",
	"subType": "none",
	"name": "My Company Pty Ltd",
	"tags": ["region:apac", "tier-1 >>> gold"],
	"timestamp": 1767004789403
}

Key points about the info webhook:

verificationStatus: "info" indicates that additional information is required
submissionStatus: "in_progress" means the submission is waiting for more data
The trace field is used to fetch the remaining actions and submit missing information
The webhook does not include the remainingActions - you must fetch them separately via the API

Fetching remaining actions

To see what information is missing, make a GET request to fetch the verification details:

Fetch verification details

GET /v5/verifications/:trace

When the status is info, the response will include a remainingActions object:

Response with remainingActions

{
	"verificationStatus": "info",
	"submissionStatus": "in_progress",
	"remainingActions": {
		"document": {
			"doc-id-123": {
				"id": "doc-id-123",
				"type": "document",
				"name": "Trust Deed",
				"description": "The trust deed document for the entity",
				"reason": "Required to verify trust structure",
				"uploadUrl": "https://storage.googleapis.com/…?X-Goog-Signature=…",
				"uploadHeaders": {
					"Content-Type": "application/octet-stream",
					"x-goog-content-length-range": "1,26214400"
				},
				"help": null
			}
		},
		"stakeholder": {
			"stakeholder-id-456": {
				"id": "stakeholder-id-456",
				"type": "individual",
				"name": "Jane Citizen",
				"description": "Director verification required",
				"reason": "ID verification for director",
				"help": null,
				"roles": ["directors"],
				"formUrl": "https://ekyc.bronid.com/ekyc-start/xyz789",
				"email": "jane@example.com",
				"phone": "+61400000000"
			}
		}
	}
}

If you upload directly to uploadUrl, send every header in uploadHeaders unchanged with that upload — they are part of the URL signature and the values can change between URLs, so read them from the response each time rather than hard-coding them.

The remainingActions object contains:

document - A record of documents that need to be uploaded, keyed by document ID
stakeholder - A record of individuals that need to complete eKYC verification, keyed by stakeholder ID

For the full field-by-field reference and the complete GET response envelope, see remainingActions on the Retrieve a verification endpoint.

Uploading missing documents

To upload a missing document, make a PUT request to the documents endpoint with the specific document ID from remainingActions.

The document ID is the key in the remainingActions.document object. In the example above, the document ID is doc-id-123:

"remainingActions": {
  "document": {
    "doc-id-123": {  // <-- This is the document ID
      "id": "doc-id-123",
      "type": "document",
      "name": "Trust Deed",
      ...
    }
  }
}

Use this ID in the PUT request URL: PUT /v5/verifications/:trace/documents/doc-id-123

There are three ways to upload a document:

Upload via URL
Upload via Base64
Upload via pre-upload (direct to storage — best for large files)

Upload via URL

If the document is hosted at a publicly accessible URL (i.e. on your own server and provided via signed URL):

/v5/verifications/:trace/documents/:documentId

curl -X PUT https://dev.bronid.com/v5/verifications/abc123-verification-trace/documents/doc-id-123 \
  --user "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2:api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314" \
  --header "Content-Type: application/json" \
  --data '{
      "source": "url",
      "data": "https://example.com/documents/trust-deed.pdf",
      "kind": "trustDeed",
      "mimeType": "application/pdf",
      "fileName": "trust-deed.pdf",
      "description": "Trust deed for My Company"
  }'

Upload via Base64

If you have the document as a base64-encoded string:

/v5/verifications/:trace/documents/:documentId

curl -X PUT https://dev.bronid.com/v5/verifications/abc123-verification-trace/documents/doc-id-123 \
  --user "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2:api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314" \
  --header "Content-Type: application/json" \
  --data '{
      "source": "base64",
      "data": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==",
      "kind": "trustDeed",
      "mimeType": "image/png",
      "fileName": "trust-deed.png",
      "description": "Trust deed for My Company"
  }'

Upload via pre-upload (direct to storage)

For large files, upload the raw bytes directly to the document's uploadUrl and then confirm the upload. This avoids base64 encoding and supports files up to 25 MB.

Step 1 — upload the file bytes to the uploadUrl from the remainingActions.document entry, sending every header from its uploadHeaders exactly as returned:

Step 1: upload the bytes

curl -X PUT 'https://storage.googleapis.com/…?X-Goog-Signature=…' \
  --header "Content-Type: application/octet-stream" \
  --header "x-goog-content-length-range: 1,26214400" \
  --upload-file trust-deed.pdf

The upload is now parked but not yet complete: the file is stored untyped, the document is not attached to the verification, and the entry stays in remainingActions.

Step 2 — confirm the upload with source: "preupload". The data value is the same document ID — for requested documents, the pre-upload reference is the remainingActions key itself:

Step 2: confirm

curl -X PUT https://dev.bronid.com/v5/verifications/abc123-verification-trace/documents/doc-id-123 \
  --user "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2:api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314" \
  --header "Content-Type: application/json" \
  --data '{
      "source": "preupload",
      "data": "doc-id-123",
      "kind": "trustDeed",
      "mimeType": "application/pdf",
      "fileName": "trust-deed.pdf",
      "description": "Trust deed for My Company"
  }'

The confirmation validates the uploaded file against the declared mimeType, attaches the document to the verification, and removes it from remainingActions. If the uploaded file is replaced while the confirmation is validating it, the confirmation returns a 422 with a preupload_conflict error code — upload the file once more and confirm again.

A requested document's uploadUrl expires 15 minutes after it is issued — if more time has passed, refresh it first (see below). The document request itself does not expire: it stays fulfillable for as long as it is listed in remainingActions. Uploading the bytes without confirming leaves the requested document incomplete — the verification stays in info status, and unconfirmed uploads are retained for at least 7 days; after that, upload the bytes again before confirming.

Refresh an expired upload URL

Signed upload URLs stop working when they expire. If the bytes have not been uploaded yet (Step 1 fails with an HTTP 403 from storage), request a fresh URL for the same document instead of asking for the document to be re-requested:

Refresh the upload URL

curl -X POST https://dev.bronid.com/v5/verifications/abc123-verification-trace/documents/doc-id-123/upload-url \
  --user "XL7ULiU6B4QE9Y2iWFZnhtMDKFN2:api_sec_NJAtNcRtUrPlf7xYDrMNP9URI-ZfN314"

The response carries a fresh uploadUrl, uploadHeaders, and uploadMethod for the SAME document ID — repeat Step 1 with the new values, then confirm as usual. The refreshed URL is valid for 15 minutes, so request it right before uploading.

The URL can be refreshed any number of times while the document request is open. A document that was already confirmed, whose request was cancelled, or whose request is no longer listed returns a 422 with a preupload_already_completed, preupload_cancelled, or preupload_request_closed error code — those documents cannot be uploaded through this flow anymore.

Document upload parameters

Parameter	Type	Required	Description
`source`	string	Yes	Upload method: `url`, `base64`, or `preupload`
`data`	string	Yes	The URL, base64-encoded content, or pre-upload document ID
`kind`	string	Yes	Document type (should match what's in `remainingActions`)
`mimeType`	string	Yes	MIME type: `application/pdf`, `image/jpeg`, `image/png`
`fileName`	string	No	Original filename
`description`	string	No	Description of the document
`reason`	string	No	Reason for uploading
`stakeholderId`	string	No	Reference to a stakeholder if this is a stakeholder-specific document

Documents must be in PDF, JPG, or PNG format. Maximum file size is 25 MB per document for the url and preupload sources, and 23 MB for the base64 source.

Redirecting users to eKYC for missing stakeholders

When remainingActions.stakeholder contains entries, each stakeholder must complete their own identity verification through the eKYC portal.

The stakeholder ID is the key in the remainingActions.stakeholder object. In the example above, the stakeholder ID is stakeholder-id-456:

"remainingActions": {
  "stakeholder": {
    "stakeholder-id-456": {  // <-- This is the stakeholder ID
      "id": "stakeholder-id-456",
      "type": "individual",
      "name": "Jane Citizen",
      "formUrl": "https://ekyc.bronid.com/ekyc-start/xyz789",  // <-- Redirect URL for eKYC
      ...
    }
  }
}

Using the form URL directly

Each stakeholder entry includes a formUrl field. Redirect the user to this URL to complete their eKYC verification.

The stakeholder will complete their verification independently through the eKYC portal.

Stakeholder verification flow

The stakeholder receives the eKYC link (you can send an email/SMS or redirect them to the link via redirect)
They access the eKYC portal and complete identity verification
Upon successful verification, the system automatically removes them from remainingActions
When all stakeholders (and documents) are complete, the verification transitions to pending

Status transition to pending

When all remainingActions are completed:

Each completed action (document upload or stakeholder verification) is automatically removed from remainingActions
When all actions are complete, the status automatically transitions from info to pending
A new webhook is sent with verificationStatus: "pending"

Pending webhook payload

{
	"userId": "user-123",
	"onBehalfUid": null,
	"trace": "abc123-verification-trace",
	"submissionId": "abc123-submission-id",
	"submissionStatus": "submitted",
	"verificationStatus": "pending",
	"inputRisk": "medium",
	"country": "AUS",
	"type": "company",
	"subType": "none",
	"name": "My Company Pty Ltd",
	"timestamp": 1767004800000
}

Note that submissionStatus changes from in_progress to submitted when all information has been provided.

Verification flow after pending

After the verification transitions to pending, it will be processed and can result in one of the following outcomes:

Verified

All checks passed successfully. You will receive a webhook:

Verified webhook payload

{
	"verificationStatus": "verified",
	"submissionStatus": "submitted",
	"trace": "abc123-verification-trace",
	"submissionId": "abc123-submission-id",
	"inputRisk": "medium",
	"idvRisk": "low",
	"screening": {
		"watchlist": {
			"status": "clear",
			"totalHits": 0,
			"lastScreenedAt": 1767004900000,
			"lastScreenedTime": "29/12/2025 21:41:40"
		}
	},
	"country": "AUS",
	"type": "company",
	"subType": "none",
	"name": "My Company Pty Ltd",
	"timestamp": 1767004900000
}

Rejected

Verification requirements were not met. You will receive a webhook:

Rejected webhook payload

{
	"verificationStatus": "rejected",
	"submissionStatus": "submitted",
	"trace": "abc123-verification-trace",
	"submissionId": "abc123-submission-id",
	"inputRisk": "medium",
	"idvRisk": "high",
	"country": "AUS",
	"type": "company",
	"subType": "none",
	"name": "My Company Pty Ltd",
	"timestamp": 1767004900000
}

The rejection reasons can be retrieved via GET /v5/verifications/:trace which includes a rejectionReasons array with details about why the verification was rejected.

Info (again)

In some cases, the verification may transition back to info status if additional information is still required:

Info webhook (again)

{
	"verificationStatus": "info",
	"submissionStatus": "in_progress",
	"trace": "abc123-verification-trace",
	"submissionId": "abc123-submission-id",
	"inputRisk": "medium",
	"idvRisk": "high",
	"country": "AUS",
	"type": "company",
	"subType": "none",
	"name": "My Company Pty Ltd",
	"timestamp": 1767005000000
}

This can happen when:

Submitted documents were incomplete, unclear, or invalid
Additional stakeholders need to be verified that weren't initially identified
Document verification revealed the need for supplementary documentation
A stakeholder's verification was rejected and needs to be re-submitted

When receiving another info webhook, repeat the process:

Fetch the updated remainingActions via GET /v5/verifications/:trace
Submit the newly requested documents or stakeholder verifications
Wait for the status to transition back to pending

This cycle can repeat until the verification reaches a final state (verified or rejected).

Complete verification flow

The following diagram shows the complete verification lifecycle:

┌─────────────────────────────────────────────────────────────────┐
│                                                                 │
│  ┌──────────────────┐                                           │
│  │   Verification   │                                           │
│  │    Submitted     │                                           │
│  └────────┬─────────┘                                           │
│           │                                                     │
│           ▼                                                     │
│  ┌──────────────────┐                                           │
│  │     pending      │◄─────────────────────────────────┐        │
│  └────────┬─────────┘                                  │        │
│           │                                            │        │
│           ▼                                            │        │
│  ┌──────────────────┐                                  │        │
│  │   Processing     │                                  │        │
│  └────────┬─────────┘                                  │        │
│           │                                            │        │
│     ┌─────┼─────┐                                      │        │
│     │     │     │                                      │        │
│     ▼     ▼     ▼                                      │        │
│  ┌─────┐ ┌────────┐ ┌──────┐                           │        │
│  │  ✓  │ │   ✗    │ │  ℹ   │                           │        │
│  │ ver │ │  rej   │ │ info │                           │        │
│  │ ifi │ │  ect   │ │      │                           │        │
│  │ ed  │ │  ed    │ └───┬──┘                           │        │
│  └─────┘ └────────┘     │                              │        │
│                         ▼                              │        │
│                ┌──────────────────┐                    │        │
│                │  Submit Missing  │                    │        │
│                │   Information    │────────────────────┘        │
│                └──────────────────┘                             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Summary

Step	Action	Endpoint
1	Receive `info` webhook	N/A (webhook)
2	Fetch remaining actions	`GET /v5/verifications/:trace`
3	Upload missing documents	`PUT /v5/verifications/:trace/documents/:documentId`
4	Redirect stakeholders to eKYC	Use `formUrl` from remaining actions
5	Wait for `pending` webhook	N/A (webhook)
6	Receive final status	`verified`, `rejected`, or `info` (webhook)

What's next?

Now that you know how to provide missing information, learn how to list documents from a verification.