Skip to main content
POST
Checks the transactions your wallets broadcast for a set of queued rows, then closes every row whose wallet the register now reports as verified. A confirmed row marks its customer verified, and creates the customer record when there is none.
On a Trusset register, the batch from Build Pending Registration skips some entries without reverting. It skips a wallet that already holds an unrevoked identity, and a row whose expiry has passed. It also skips any entry it runs out of gas for.A skipped wallet that the register still reports as verified confirms anyway. Its row closes, the register keeps the hash, investor type and expiries it already held, and the customer record takes that hash. The queued ones are never written. investorTypeMismatch flags a different investor type, but nothing in the response flags a different hash or expiry.Any other skipped row comes back NOT_REGISTERED_ON_CHAIN and stays queued. A row skipped for gas can be built again. A row whose wallet holds an identity past its hard expiry or frozen, or whose own expiry has passed, is skipped again every time.To put a skipped approval on the register, use Verify Identity with the row’s kycHash. It verifies the wallet or updates the identity it already holds, and closes the row if it is still queued.

Body Parameters

array
required
1 to 200 row ids, normally ids from the build. Only rows still PENDING on your instance are checked, and any other id is dropped without an error.
string
The registering transaction. On a Trusset register it is required: the batch, or a verifyIdentity or updateIdentity call. On an ERC-3643 register it is the registerIdentity or batchRegisterIdentity step. Omit it there when every wallet was already registered.
array
The claim steps you broadcast, as [{ id, txHash }] with the row id each step carried. Entries are kept per id, so for a row with two claim steps only the last entry sent is checked. A claim that fails its check is left out of the record and fails nothing else.

What the confirm checks

A failed check of txHash refuses the whole call before any row changes. The per-row outcome comes back in results, and one row’s outcome does not affect another’s.

What a confirmed row changes

  • The row turns CONFIRMED, with the transaction, its signer and the time.
  • The customer record with this wallet becomes verified, with the kycHash the register holds and the transaction. Without a record, one is created from the row’s metadata. On an ERC-3643 register the record also gets metadata.onchainId.
  • The customer audit log gets ON_CHAIN_VERIFIED, with the queued and the registered hash.
  • A hosted verification checkout behind the row turns VERIFIED, and stock escrow deposits waiting on its ID link are bound to the wallet.
  • When the row carries notifyEmail, the customer is emailed that verification is complete.
The customer write is best effort. A failure there is logged, and the row still confirms. A row that does not confirm stays PENDING, and its error says why. Build and confirm it again once the cause is fixed. A repeat call for rows that all confirmed answers NOT_FOUND, because none of them is PENDING any more.
The HTTP status is 200 and success is true even when no row confirmed. Read confirmed and each entry of results.

Response Fields

object
array

Error Codes