- Send the event to your Webhook endpoint
- Capture a trace of the event so you can later check all Webhook Events sent to your webhooks (through List Webhook Events or Get Webhook Event endpoints)
We only keep a trace of Webhook Events in our system for a retention period of 31 days. Past that, they are discarded, so you cannot see them using List Webhook Events or Get Webhook Event endpoints.
wallet.transfer.requested
” delivered to your webhook:
Supported Webhook Events
The list below shows which event kinds webhooks can subscribe to ⬇️ (see Webhook Event Data section for details on each event kind)Event Enum | Description |
---|---|
wallet.blockchainevent.detected | A wallet event has been detected on chain (eg. a deposit). Note: This is only available for Tier-1 chains. |
wallet.created | A wallet has been created. |
wallet.exported | A wallet has been exported. |
wallet.delegated | A wallet has been delegated. |
wallet.signature.requested | A generate signature request has been created. |
wallet.signature.failed | A generate signature request has failed to process. |
wallet.signature.rejected | A generate signature request with a policy approval has been rejected. |
wallet.signature.signed | A generate signature request has completed. |
wallet.transaction.requested | A broadcast transaction request has been created. |
wallet.transaction.failed | A broadcast transaction request has failed to process. |
wallet.transaction.rejected | A broadcast transaction request with a policy approval has been rejected. |
wallet.transaction.broadcasted | A broadcast transaction request has been submitted to the mempool. |
wallet.transaction.confirmed | A broadcast transaction request has been confirmed on chain. Note: This is only available for Tier-1 chains. |
wallet.transfer.requested | A wallet transfer request has been created. |
wallet.transfer.failed | A wallet transfer request has failed to process. |
wallet.transfer.rejected | A wallet transfer request with a policy approval has been rejected. |
wallet.transfer.broadcasted | A wallet transfer request has been submitted to the mempool. |
wallet.transfer.confirmed | A wallet transfer request has been confirmed on chain. Note: This is only available for Tier-1 chains. |
policy.triggered | A policy got triggered upon some activity (the policy rule got evaluated, and it triggered) |
policy.approval.pending | A new Approval process has been created and is pending. |
policy.approval.resolved | A new Approval process is finalized: it’s either approved or rejected. |
Webhook Event Data
Each webhook event has a “data
” property, which shape depends on its kind. Here’s an overview of the shape of the data for each kind:
- For
wallet.created
,wallet.exported
,wallet.delegated
see the Get Wallet response:
data
- For
wallet.transfer.requested
,wallet.transfer.failed
,wallet.transfer.rejected
,wallet.transfer.broadcasted
,wallet.transfer.confirmed
see the Get Transfer response:
data
- For
wallet.transaction.requested
,wallet.transaction.failed
,wallet.transaction.rejected
,wallet.transaction.broadcasted
,wallet.transaction.confirmed
see the Get Transaction response :
data
- For
wallet.signature.requested
,wallet.signature.failed
,wallet.signature.rejected
,wallet.signature.signed
see the Get Signature response:
data
- For
wallet.blockchainevent.detected
various event kinds are available depending on the indexed chain:\
Kind | Chains |
---|---|
NativeTransfer | All |
Aip21Transfer | Aptos |
AsaTransfer | Algorand |
CoinTransfer, LockedCoinTransfer | Iota |
Erc20Transfer, Erc721Transfer | Evm |
Tep74Transfer | Ton |
Trc10Transfer, Trc20Transfer, Trc721Transfer | Tron |
Sep41Transfer | Stellar |
SplTransfer, Spl2022Transfer | Solana |
UtxoTransfer | Bitcoin, Litecoin, Dogecoin, Kaspa |
data
- For
policy.triggered
data
- For
policy.approval.pending
andpolicy.approval.resolved
, see the List Approvals response:
data
Webhook Event Ordering
Dfns doesn’t guarantee delivery of events in the order in which they’re generated. For example, when a wallet Transfer is picked up on-chain by our blockchain indexers, we might generate the following events:wallet.transfer.confirmed
- this event notifies you that the Transfer Request that you made has been confirmed on chainwallet.blockchainevent.detected
- this event notifies you of the new Blockchain Event detected and added to your Wallet History blockchain events
Webhook Event Deliveries & Retries
During an webhook event delivery attempt, if we cannot reach your webhook endpoint, or if your endpoint returns anything else than a 200 status code in the response, we consider the delivery of this event has failed. In such a case, Dfns is going to retry delivering it to your webhook, up to 5 total attempts over 24 hours, with an exponential backoff (delays from first attempt: 1m, 12min, 2h, 1d). Every event delivery attempt will create a new Webhook Event, with its own unique ID, containing the samedata
than the previous event which failed delivering. So in the List Webhook Events endpoint, every Webhook Event you will see is a unique delivery attempt (potentially of the same original event).
The event that your webhook handler will receive (in your server), will include the attempt number in the payload (deliveryAttempt: 1
for the first attempt). Also, if it includes the field retryOf: "whe-xxxxxxx"
, it indicates that this event you are receiving, is a “retry of” a previous Webhook Event which failed delivering.
Additionally, if you fetch Webhook Events we tried delivering, using the List Webhook Events or Get Webhook , you will be able to see the deliveryFailed
boolean field indicating if delivery succeeded or not, as well as the nextAttemptDate: "2024-01-24-xxxxxx"
date showing you around which time the next delivery attempt to your webhook will occur (if delivery failed).
If you want to fetch all Webhook Events which failed delivering to your webhook, you can use the List Webhook Events with the query parameter deliveryFailed=true
. And amongst all those returned, you can see those which failed delivering, and will not retry in future (because reached maximum retry attempt), by filtering those which have no nextAttemptDate
.
If your webhook has been disabled or deleted when Dfns attempts a retry, future retries of that event are prevented. However, if you disable and then re-enable a webhook endpoint before Dfns can retry, you can still expect to see future retry attempts.