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, Build Pending Registration puts a wallet that already holds an active identity into its own updateIdentity step, so the queued hash, investor type and expiries replace what the register held. Send each of those as updateTxResults. The batch still skips a row whose expiry has passed and any entry it runs out of gas for.A batch built before a wallet’s identity became active can still skip it. Such a wallet that the register reports as verified confirms anyway: its row closes, the register keeps the hash, investor type and expiries it held, and the customer record takes that hash. investorTypeMismatch flags a different investor type, but nothing in the response flags a different hash or expiry. Build the row again instead, so it is renewed.Any other skipped row comes back NOT_REGISTERED_ON_CHAIN and stays queued. A row skipped for gas, or one whose identity has since become active, can be built again. A row whose own expiry has passed is skipped again every time, and a frozen wallet stays NOT_REGISTERED_ON_CHAIN until it is unfrozen.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 the batch, or a verifyIdentity or updateIdentity call, and it is required unless every row is confirmed through updateTxResults. On an ERC-3643 register it is the registerIdentity or batchRegisterIdentity step. Omit it there when every wallet was already registered.
array
Trusset register only. The renewal steps you broadcast, as [{ id, txHash }] with the row id each updateIdentity step carried. Each must be a mined, successful updateIdentity for the row’s wallet, carrying the row’s queued kycHash, signed by a verified wallet registered to your instance, or the whole call fails with TX_ENTRIES_MISMATCH or UNAUTHORIZED_SIGNER. A confirmed renewal also writes the row’s investor type name to the customer record, and its history entry carries operation: update.
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.
  • When the verification profile the row was queued under has an eligibility register, the wallet’s admission to it is queued for your wallet to sign. See Eligibility registers.
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