Skip to main content
Missed webhook notifications can occur due to various issues such as temporary downtime, connectivity problems, or unexpected errors in your webhook handler. These issues can prevent your server from acknowledging or processing events sent by Fireblocks. To ensure no critical events are lost, Fireblocks provides multiple solutions for you to address your particular use case.

​
Auto-retry mechanism

First, the Fireblocks server will look for a response to confirm the webhook notification was received. All webhook events should receive an HTTP 200 (OK) response. If no response is received, Fireblocks will resend the 5xx request several more times. The retry schedule (in seconds) follows an exponential backoff of 10, 30, 120, 300, 900, 1800, 3600, 7200, and 14400.

​
Retries for 4xx errors

Fireblocks will not attempt to retry sending webhook notifications for client-side errors (HTTP 4xx) except for the following cases:
  • 429 - Too Many Requests: Indicates rate limits have been exceeded.
  • 408 - Request Timeout: Indicates the server took too long to respond.
After a total of 10 failed attempts, the notification will be marked as failed, and no further retries will be made.

​
Resending a single notification

Use this method when you need to troubleshoot or ensure the delivery of a specific event, such as a transaction update or status change.
Example use caseIf your server fails to process a specific transaction notification, you can use this endpoint to retry only that notification, minimizing unnecessary retries.

​
Via the Fireblocks Console

  1. In the Fireblocks Console, go to Developer center > Webhooks, and then select the relevant endpoint URL from the Webhooks list.
  2. In the Notification activity list, find the notification you want to resend and then select it.
  3. On the Notification attempts dialog, select Resend notification.
  4. Validate that you received the notification successfully.

​
Via the Fireblocks API & SDKs

First, run the getNotifications command, which uses the Get all notifications by webhook id endpoint. 
curl --request GET \
     --url 'https://api.fireblocks.io/v1/webhooks/webhookId/notifications?order=DESC&pageSize=100' \
     --header 'accept: application/json'
After you retrieve the id value from the notification you want to resend, use the resendNotificationById command, which uses the Resend notification by ID endpoint. 
curl --request POST \
     --url 'https://api.fireblocks.io/v1/webhooks/webhookId/notifications/notificationId/resend' \
     --header 'accept: application/json'
Lastly, validate that you received the notification successfully.

​
Resending multiple notifications by resource ID

Use this method when you need to resend notifications for a particular resource, such as a vault account or transaction, after resolving server-side issues. This method will resend all notifications generated over the last 30 days for that resource.
Example use caseIf your webhook server missed updates for a specific transaction due to an outage, you can use this endpoint to retrieve all missed notifications related to that transaction.

​
Via the Fireblocks API & SDKs

First, run the getNotifications command, which uses the Get all notifications by webhook id endpoint. 
curl --request GET \
     --url 'https://api.fireblocks.io/v1/webhooks/webhookId/notifications?order=DESC&pageSize=100' \
     --header 'accept: application/json'
After you retrieve the resourceId value you need, run the resendNotificationsByResourceId command, which uses the Resend notifications by resourceId endpoint. 
curl --request POST \
     --url 'https://api.fireblocks.io/v1/webhooks/webhookId/notifications/resend_by_resource' \
     --header 'accept: application/json' \
     --header 'content-type: application/json'
Lastly, validate that you received the notifications successfully.
Resource ID in the ConsoleYou can also find a notification’s resource ID in the Fireblocks Console by going to Developer Center > Webhooks and then selecting the relevant endpoint URL from the Webhooks list. Then, in the Notification activity list, you can find and copy the relevant resource ID.

​
Resending all notifications for an endpoint

Use this method when you need to resend all the notifications for a particular endpoint after resolving server-side issues. This method will resend all notifications generated over the last 24 hours for that endpoint.

​
Via the Fireblocks Console

  1. In the Fireblocks Console, go to Developer center > Webhooks, and then select the relevant endpoint URL from the Webhooks list.
  2. In the Notification activity list, select Resend notifications.
  3. Validate that you received the notifications successfully.

​
Endpoint auto-deactivated due to circuit breaker

In Webhooks V2, the circuit breaker monitors error rates for each webhook endpoint and suspends endpoints that exceed predefined thresholds. Errors include timeouts and any non-2xx status code. The circuit breaker evaluates error rates using a rolling 60-minute window, assessed on each delivery attempt. Suspension policies vary by error rate severity:
  • 50–80% error rate: If your endpoint sustains this error rate for 4 consecutive hours, Fireblocks suspends it automatically.
  • Above 80% error rate: If your endpoint’s error rate exceeds this threshold within the rolling 60-minute window, Fireblocks suspends it immediately.
When your endpoint is suspended, Fireblocks notifies all Admin users in the workspace by email.

​
Reactivating a suspended endpoint

Suspension is not automatically lifted. To reactivate your endpoint:
  1. Identify and resolve the underlying issue causing delivery failures.
  2. Reactivate the endpoint via the Developer Center or by calling the Update Webhook endpoint with enabled set to true.
  3. Once reactivated, the circuit breaker immediately resumes monitoring the endpoint. If the error rate exceeds the above thresholds again, the endpoint will be suspended again.
No cooldown period before reactivationThere is no cooldown period before reactivation. It is your responsibility to ensure the issue is resolved before reactivating to avoid repeated suspension.