Introduction
Generally, when you make a request to an API endpoint, you expect to get a near-immediate response. However, some requests may take a long time to process, which can lead to timeout errors. In order to prevent a timeout error, a pending response is returned. Since your records need to be updated with the final state of the request, you need to either:- Make a request for an update (popularly known as polling) or,
- Listen to events by using a webhook URL.
Polling vs Webhooks
Polling requires making aGET request at regular intervals to get the final status of a request. For example, when you issue an address to a customer for deposits, you keep making a request for transactions linked to the address until you find one.
With webhooks, the resource server, Blockradar in this case, sends updates to your server when the status of your request changes. The change in status of a request is known as an event. You’ll typically listen to these events on a POST endpoint called your webhook URL.
The table below highlights some differences between polling and webhooks:
| Polling | Webhooks | |
|---|---|---|
| Mode of update | Manual | Automatic |
| Rate limiting | Yes | No |
| Impacted by scaling | Yes | No |
Create a webhook URL
A webhook URL is simply a POST endpoint that a resource server sends updates to. The URL needs to parse a JSON request and return a200 OK:
200 OK in the HTTP header. Without a 200 OK in the response header, we’ll keep sending events for the next 2 hours and 35 minutes:
- We’ll attempt to send webhooks 5 times with an increasing delay between each attempt, starting with 5 minutes and increasing exponentially up to 80 minutes. The total duration for these 5 attempts will span approximately 2 hours and 35 minutes.
Testing Webhooks Locally
During development, you can configure your webhook URL in your TEST master wallet environment to a local address, such ashttp://localhost or 127.0.0.1.
To expose your local server to the internet for testing purposes, consider using a tool like ngrok or webhook.site. These tools allow you to see what the webhook payload looks like and simulate webhook events locally before deploying your application to a live environment.
Using these tools, you can ensure that your webhook integration is functioning correctly and handle any issues in a controlled, local environment before moving to production.
Resend Transaction Webhook
Incase where for some reasons you don’t receive transaction webhook and the backoff time is elapse, we’ve provided an API you can use to resend a transaction webhookVerify event origin
Since your webhook URL is publicly available, you need to verify that events originate from Blockradar and not a bad actor. There are two ways to ensure events to your webhook URL are from Blockradar:- Signature validation (recommended)
Signature validation
Events sent from Blockradar carry the x-blockradar-signature header. The value of this header is a HMAC SHA512 signature of the event payload signed using your secret key. Verifying the header signature should be done before processing the event:Go Live Checklist
Now that you’ve successfully created your webhook URL, here are some ways to ensure you get a delightful experience:- Add the webhook URL on your Master wallets on the Blockradar dashboard
- Ensure your webhook URL is publicly available (localhost URLs cannot receive events)
- If using
.htaccess, kindly remember to add the trailing/to the URL - Test your webhook to ensure you’re getting the JSON body and returning a
200 OKHTTP response - If your webhook function has long-running tasks, you should first acknowledge receiving the webhook by returning a
200 OKbefore proceeding with the long-running tasks - If we don’t get a
200 OKHTTP response from your webhooks, we flag it as a failed attempt - We’ll attempt to send webhooks 5 times with an increasing delay between each attempt, starting with 5 minutes and increasing exponentially up to 80 minutes. The total duration for these 5 attempts will span approximately 2 hours and 35 minutes.
Types of events
Here are the events we currently raise. We would add more to this list as we hook into more actions in the future.Event Examples
Below are examples of webhook payloads for some of the most common events:- Deposit Success
- Deposit Processing
- Withdraw Success
- Signed Success
- Signed Failed
- Swap Success
- Deposit Swept Success
- Withdraw Failed
- Swap Failed
- Deposit Failed
- Deposit Swept Failed
- Staking Success
- Custom Smart Contract Success
- Gateway Deposit Success
- Gateway Deposit Failed
- Gateway Withdraw Success
- Withdraw Failed
Complete Event List
| Event | Description |
|---|---|
deposit.success | Triggered when a deposit transaction is successfully received and confirmed on the blockchain. |
deposit.processing | Triggered when a deposit transaction is being processed. |
deposit.failed | Triggered when a deposit transaction fails to be processed or confirmed. |
deposit.cancelled | Triggered when a deposit transaction is cancelled before completion. |
deposit.swept.success | Triggered when funds from a deposit are successfully swept (transferred) to the master wallet. |
deposit.swept.failed | Triggered when the auto-sweep process fails to transfer funds to the master wallet. |
withdraw.success | Triggered when a withdrawal transaction is successfully executed and confirmed on the blockchain. |
withdraw.failed | Triggered when a withdrawal transaction fails to execute. This can occur due to insufficient funds, network congestion, or other blockchain-related issues. |
withdraw.cancelled | Triggered when a withdrawal transaction is cancelled before completion. |
gateway-deposit.success | Triggered when a USDC deposit to the Gateway Wallet contract is successfully finalized and credited to the unified Gateway balance. |
gateway-deposit.failed | Triggered when a USDC deposit to the Gateway Wallet contract fails or is rejected. |
gateway-deposit.cancelled | Triggered when a gateway deposit transaction is cancelled before completion. |
gateway-withdraw.success | Triggered when USDC is successfully minted and withdrawn on the destination chain through the Gateway Minter contract. |
gateway-withdraw.failed | Triggered when a withdrawal (mint) transaction via Gateway fails to execute, which may occur because of insufficient unified balance, invalid signature, or blockchain issues. |
gateway-withdraw.cancelled | Triggered when a gateway withdrawal transaction is cancelled before completion. |
signed.success | Triggered when a signed transaction is successfully executed, however, transaction is not broadcast on the blockchain. |
signed.failed | Triggered when a signed transaction fails to execute. This can occur due to network congestion, or other blockchain-related issues. |
signed.cancelled | Triggered when a signed transaction is cancelled before completion. |
swap.success | Triggered when a swap transaction is successfully executed and the assets are exchanged. |
swap.failed | Triggered when a swap transaction fails to execute. This can occur due to insufficient funds, network congestion, or swap contract errors. |
swap.cancelled | Triggered when a swap transaction is cancelled before completion. |
custom-smart-contract.success | Triggered when a custom smart contract transaction is successfully executed. This indicates that the contract interaction completed successfully on the blockchain. |
custom-smart-contract.failed | Triggered when a custom smart contract transaction fails to execute. This can occur due to various reasons such as insufficient funds, network congestion, or smart contract errors. |
custom-smart-contract.cancelled | Triggered when a custom smart contract transaction is cancelled before completion. |
staking.success | Triggered when a staking transaction is successfully executed and the assets are staked. |
staking.failed | Triggered when a staking transaction fails to execute. This can occur due to insufficient funds, network congestion, or staking contract errors. |
staking.cancelled | Triggered when a staking transaction is cancelled before completion. |
unstaking.success | Triggered when an unstaking transaction is successfully executed and the assets are unstaked. |
unstaking.failed | Triggered when an unstaking transaction fails to execute. This can occur due to insufficient staked balance, network congestion, or staking contract errors. |
unstaking.cancelled | Triggered when an unstaking transaction is cancelled before completion. |
unstaking.withdraw.success | Triggered when unstaked assets are successfully withdrawn to the user’s address. |
unstaking.withdraw.failed | Triggered when the withdrawal of unstaked assets fails to execute. This can occur due to insufficient balance, network congestion, or other blockchain-related issues. |
unstaking.withdraw.cancelled | Triggered when an unstaking withdrawal transaction is cancelled before completion. |
restaking.success | Triggered when a restaking transaction is successfully executed and the assets are restaked. |
restaking.failed | Triggered when a restaking transaction fails to execute. This can occur due to insufficient funds, network congestion, or staking contract errors. |
restaking.cancelled | Triggered when a restaking transaction is cancelled before completion. |
auto-settlement.success | Triggered when an auto-settlement transaction is successfully executed and the settlement is completed. |
auto-settlement.failed | Triggered when an auto-settlement transaction fails to execute. This can occur due to insufficient funds, network congestion, or settlement contract errors. |
auto-settlement.cancelled | Triggered when an auto-settlement transaction is cancelled before completion. |
salvage.success | Triggered when a salvage operation is successfully executed and the assets are recovered. |
salvage.failed | Triggered when a salvage operation fails to execute. This can occur due to insufficient funds, network congestion, or salvage contract errors. |
salvage.cancelled | Triggered when a salvage operation is cancelled before completion. |
Transaction Types and Statuses
Transaction Types
The following transaction types are used in webhook payloads:| Type | Description |
|---|---|
DEPOSIT | A deposit transaction where funds are received into a wallet address |
WITHDRAW | A withdrawal transaction where funds are sent from a wallet to an external address |
SIGNED | A signed transaction where transaction is only signed and not broadcast to network |
GATEWAY_DEPOSIT | A deposit transaction where funds are received into a gateway wallet address |
GATEWAY_WITHDRAW | A withdrawal transaction where funds are sent from a gateway wallet to an external address |
SALVAGE | A salvage operation to recover stuck or lost funds |
AUTO_SETTLEMENT | An automatic settlement transaction |
AUTO_FUNDING | An auto-funding transaction that mints and moves stablecoins |
STAKING | A staking transaction where assets are staked |
UNSTAKING | An unstaking transaction where staked assets are unstaked |
RESTAKING | A restaking transaction where assets are restaked |
UNSTAKING_WITHDRAW | A withdrawal of unstaked assets |
CUSTOM_SMART_CONTRACT | A custom smart contract interaction |
SWAP | A swap transaction where one asset is exchanged for another |
Transaction Statuses
The following statuses indicate the current state of a transaction:| Status | Description |
|---|---|
PENDING | Transaction is being processed but not yet confirmed |
PROCESSING | Transaction is currently being processed |
SUCCESS | Transaction has been successfully executed and confirmed |
FAILED | Transaction failed to execute or was rejected |
INCOMPLETE | Transaction is incomplete and may require additional steps |
CANCELLED | Transaction was cancelled before completion |
These transaction types and statuses are used in the
type and status fields of webhook payloads to help you understand what kind of transaction occurred and its current state.
