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.
No data is lost during endpoint suspensionIf your endpoint is suspended by the circuit breaker, Fireblocks continues to record every notification generated for the webhook. Once you resolve the underlying issue and re-enable the endpoint, you can resend all failed notifications from the last 24 hours using the Recover from Downtime flow (resend_failed), or resend a filtered subset with Resend notifications by query.

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.
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.
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.
After you retrieve the resourceId value you need, run the resendNotificationsByResourceId command, which uses the Resend notifications by resourceId endpoint.
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.

Recovering from downtime (resend_failed)

Use this method when your webhook server was offline (for example, due to a deployment, an outage, or an endpoint suspension by the circuit breaker) and you need to redeliver everything that missed your endpoint during the incident. It schedules an asynchronous job that resends all notifications for the endpoint that are still eligible for delivery — this includes notifications marked FAILED, notifications currently ON_HOLD, and notifications that are still between retry attempts.
Example use caseYour webhook server returned 504 timeouts for an extended period and Fireblocks suspended the endpoint. After you fix the outage and re-enable the endpoint, trigger Recover from Downtime (which calls resend_failed under the hood) to redeliver every notification that was affected during the incident — no data was lost while the endpoint was suspended.
When you need resend_failedThe auto-retry mechanism stops after 10 failed delivery attempts and marks the notification as FAILED. If your outage lasted long enough for retries to be exhausted, the retry schedule will not resume on its own after you recover — trigger resend_failed (or the Recover from Downtime action in the Console) to redeliver those notifications.

Delivery pacing

Resent notifications are dispatched on a best-effort basis, ordered by their original creation time. Fireblocks does not fire the whole batch at your endpoint in a single burst, and it respects 429 Too Many Requests responses — your endpoint can signal back-pressure and Fireblocks will automatically retry the notification with backoff.

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. Select Recover from Downtime (or Resend notifications in the Notification activity list).
  3. Validate that notifications start arriving at your endpoint successfully.
The Console’s Recover from Downtime dialog calls the resend_failed endpoint under the hood.

Via the Fireblocks CLI

The Fireblocks CLI is often the fastest way to trigger a recovery from a shell or an operational runbook:

Via the Fireblocks API & SDKs

See the full endpoint reference for request/response schemas, permissions, and language SDK snippets:

Resending notifications by query (resend_by_query)

resend_by_query is a more granular and robust alternative to resend_failed. Use it when you need to redeliver only a targeted slice of missed notifications — a specific event type, a specific resource, a specific time window inside a longer outage, or a specific status set. The endpoint accepts optional filters (statuses, start/end time, events, resource ID) and runs asynchronously as a job. Because it lets you scope the resend precisely, resend_by_query is the recommended choice whenever you don’t need the full “everything that missed my endpoint” behavior of resend_failed — it avoids redelivering notifications your server already processed and keeps recovery jobs small.
Example use caseYour outage only affected transaction notifications between 08:00 and 09:00 UTC. Instead of resending everything for the endpoint, call Resend notifications by query with startTime, endTime, and events: ["transaction.status.updated"] to redeliver just the affected notifications.

Via the Fireblocks CLI

Via the Fireblocks API & SDKs

See the full endpoint reference for the complete filter schema (defaults, time-window constraints, allowed statuses and events), permissions, and language SDK snippets:

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.
Notifications generated during suspension are preservedWhile your endpoint is suspended, Fireblocks stops attempting delivery but continues to record every notification. After you reactivate the endpoint, use Recovering from downtime (resend_failed) to redeliver everything from the last 24 hours, or Resend notifications by query to target a specific window or event type.

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. Trigger Recovering from downtime to resend notifications that failed while the endpoint was suspended.
  4. 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.