Description of webhook processing from Fireblocks (transaction creation)
Is everything correct according to this processing logic for sending and receiving assets?
The received webhook contains information about the sender’s asset address and the recipient’s asset address (or several recipient’s asset addresses).
We try to find the corresponding asset in our database by the sender’s address. If we find it, we create a record by transaction, which is linked to this sender’s asset.
We try to find the corresponding asset in our database by the recipient’s address. If we find it, we create a record by transaction, which is linked to this recipient’s asset.
When we receive a webhook with a updated status, we update only the status according to the transaction creation data.
Could you please additionally advise, which statuses should we consider as final status for Sending assets, and Receiving assets? And which are temporary statuses?
Correct, the initial webhook event is of TRANSACTION_CREATED type, for both directions and will contain source and destination addresses. Transaction Webhooks
For an outgoing transaction, if the transaction request is valid and the txId record is created it will trigger a webhook event for TRANSACTION_CREATED after txId records creation.
For incoming it is a bit different but if you received a webhook event then it means we already detected an incoming transaction based on the destination address to your vault and created a txId record for it which happens before the webhook is even triggered.
However, if the relevant destination base asset wallet address does not exist in the said vault we will not detect it and not create a txId which in turn will not trigger a webhook. This is more relevant for EVM transactions since the address is shared across multiple networks, for example, if you have only an ETH wallet and now someone sent you to the same ETH address MATIC it will not create a txId unless you have a MATIC wallet, the only option to create the txId now is to add the wallet manually and request support to rescan the incoming txHash to create a record.
A TRANSACTION_STATUS_UPDATED event will be triggered on any update of the transaction details which can happen a few times during the transaction status life cycle but generally each status will be seen only once, and you and Fireblocks can trigger it manually even on final status. Resend webhooks for a transaction by ID
Regarding status, those are the final statuses:
COMPLETED
CANCELLED
BLOCKED
FAILED
*REJECTED - This depends on AML and the incoming transaction is technically completed on the chain just frozen so you can manually bypass it which will change the status but it’s a manual update in this case and generally considered final.
I have a related question to the above and thought that asking in this topic could be better than creating a new one.
Could you clarify please how should a system treat REJECTED status for outgoing transactions (that is sending BTC from Fireblocks vault to one time address)?
From your message above I understand that for incoming REJECTED transactions there could be another manual step, but what about outgoing transactions? Documentation states After an outgoing transaction is marked as rejected, all associated assets are available for new transactions., so does it mean that we can treat it as final status in this case and there will be no additional updates to this particular transaction?