---
title: "Reliable Bitrix24 Outbound Webhooks: Delivery, Retries and Delivery Logs"
description: "Deliver Bitrix24 events to your server without losing them. Set up outbound webhooks in OIA Shield24 with instant acknowledgement, retry backoff and a delivery log."
url: https://oia-shield24.infinitybht.app/blog/bitrix24-outbound-webhooks-reliable-delivery
published: 2026-10-29
updated: 2026-10-29
author: "OIA Shield24 Team"
category: "Events & Webhooks"
tags: ["webhooks", "events", "retries", "reliability", "bitrix24"]
site: https://oia-shield24.infinitybht.app
---

# Reliable Bitrix24 Outbound Webhooks: Delivery, Retries and Delivery Logs

![Diagram of Bitrix24 sending an event to OIA Shield24, which replies 200 immediately and places the event in a durable delivery queue that retries a failing handler with growing delays until it succeeds, with each attempt recorded in a delivery log.](https://oia-shield24.infinitybht.app/blog/img/bitrix24-outbound-webhooks-reliable-delivery.svg "OIA Shield24 acknowledges Bitrix24 at once, then retries delivery to your handler with backoff, up to 14 attempts over about seven hours.")

Bitrix24 can tell your server when something happens: a deal is created, a lead changes stage, a task is completed. It does this by calling a handler URL you provide. The weak point is what happens when your server is slow, restarting or briefly offline. The event arrives, nobody is there to catch it, and it is gone. You find out weeks later when a report does not add up.

This guide shows how to route Bitrix24 events through OIA Shield24 so they are acknowledged instantly, retried automatically, and recorded attempt by attempt.

> **Short answer:** Add your handler under Outbound Events in OIA Shield24 and choose the Robust Queue delivery mode. Bitrix24 gets an immediate 200 reply, and a durable queue in your chosen region calls your handler, retrying failures with growing delays for up to 14 attempts over roughly seven hours. A delivery log shows every attempt.

## Why events get lost

Bitrix24 event handlers are fire-and-forget from Bitrix24's point of view. If your handler is down, returns an error or takes too long, there is no promise that Bitrix24 will try again on your schedule. Three situations cause most losses:

- **Deploys and restarts.** A few seconds of downtime during a release is enough to miss an event.
- **Slow handlers.** If your code does heavy work before replying, the call can time out.
- **Longer outages.** A server or database problem overnight means every event in that window is gone.

Meanwhile the opposite problem also exists. If a handler is flooded after an outage, it may be unable to keep up. A queue gives you a controlled way to deliver and to stop.

## How OIA Shield24 delivers events

Two delivery modes are available on each webhook:

| Mode | How it behaves | Use it when |
|---|---|---|
| **Robust Queue** (recommended) | Bitrix24 is answered with 200 immediately. A durable queue in your chosen region calls your handler and retries failures with exponential backoff | Events matter and your server is not always available |
| **Direct / Real-time** | The event is forwarded straight away, once, with no retries | You want the lowest latency and can tolerate a missed event |

In Robust Queue mode the first retry comes after about 30 seconds, and each following delay grows until it reaches a cap of one hour. A failing handler is called up to 14 times in total, which spans roughly seven hours, long enough to outlive an ordinary overnight outage. If every attempt fails, the rule is switched off with the status `disabled_errors` so it cannot keep hammering a broken server, and you re-enable it once the handler is fixed.

Because retries mean the same event can reach your handler more than once, your handler should be **idempotent**. A simple way is to key your processing on the record ID and event name, so a repeated call changes nothing.

## Step by step: set up a reliable webhook

1. **Prepare the handler.** It must be a public `http://` or `https://` URL that answers with a 2xx status within 10 seconds. Addresses on private networks, loopback addresses and cloud metadata addresses are rejected, which protects against server-side request forgery. Acknowledge first and do the real work afterwards:

```js
import http from 'node:http';

http.createServer((req, res) => {
  let body = '';
  req.on('data', (chunk) => (body += chunk));
  req.on('end', () => {
    res.writeHead(200).end('ok');          // reply fast so the attempt counts as delivered
    queueMicrotask(() => processEvent(body)); // heavy work happens after the reply
  });
}).listen(3000);
```

2. **Open Outbound Events.** In the OIA Shield24 sidebar choose **Outbound Events** and add a new webhook.
3. **Pick the events.** Search the list of Bitrix24 events, or type a custom event name such as `ONCRMDEALADD`.
4. **Enter the handler URL.** Use the address from step 1, for example `https://your-server.com/webhook`.
5. **Choose the delivery mode and region.** Select **Robust Queue**, and set the region under Dynamic Location Hint. The default Auto-Detect is recommended, or lock a region if your data must stay in one jurisdiction.
6. **Send a test delivery.** Use **Send Test Delivery** and confirm your server received it.
7. **Trigger a real event.** Create a deal in Bitrix24 and watch your handler receive the event.
8. **Practise a failure.** Stop your server, create another deal, start the server again, and confirm the event still arrives on a retry.

## Read the delivery log

Open **Observability** and choose the **Outbound Events** tab. The log has one row for every delivery attempt, not every event, so a retried event appears as several rows sharing one delivery ID, with a rising attempt number. Each row ends in one outcome:

| Outcome | What happened |
|---|---|
| `delivered` | Your handler answered with a 2xx status |
| `failed` | Your handler answered, but not with a 2xx status |
| `timeout` | Your handler did not answer within 10 seconds |
| `network_error` | Your handler could not be reached at all |
| `exhausted` | Every retry was used and the event was dropped; the rule is now disabled |
| `queue_full` | The rule's retry backlog reached its limit and the delivery was refused |
| `no_handlers` | The event arrived but no active rule matched it |
| `suspended` | Delivery is paused because the subscription is not active; your rules are kept |

Two details matter for trust. The log stores **metadata only**: timestamp, event name, handler host name, status code, outcome, attempt number, latency and payload size. The payload your handler received and the reply it sent are never written, so no CRM record content ends up in the log. And the delivery log, with its 90-day history, is an Enterprise plan feature. On plans without the log, events are still delivered, but you cannot query the history afterwards.

## When something is wrong

- **Many `failed` rows with the same status code.** Your handler is rejecting the event, for example on an authentication check. Fix it and re-enable the rule if it was disabled.
- **`timeout` rows.** Your handler is doing work before replying. Acknowledge first, then process.
- **`exhausted`.** The outage outlasted the retry window. Fix the handler, re-enable the rule, and reconcile any gap with a REST query for records changed since the outage started.
- **An empty log when you expect events.** A request with an unknown webhook secret or a body over 1 MB is refused before it can be attributed to your portal, so it never appears in anyone's log. Check the secret and payload size first.

## Frequently asked questions

### Does OIA Shield24 store the content of my events?

No. The delivery log records metadata such as the event name, status code and timing, but never the payload or your handler's reply.

### How many times is a failing handler called?

Up to 14 times in Robust Queue mode, starting at about 30 seconds and growing to a one-hour cap, over roughly seven hours. After that the rule is disabled until you re-enable it.

### Can I send events to a server on my private network?

Not directly. Handler URLs must be public. Addresses on private networks, loopback and cloud metadata ranges are blocked on purpose to prevent server-side request forgery. Expose the handler through a public HTTPS address instead.

### Which region processes my events?

The one you choose with Dynamic Location Hint, or an automatically chosen one if you leave it on Auto-Detect. Locking a region keeps processing in that legal jurisdiction.

Events often follow an API integration. To protect the calls going the other way, read [how to protect and monitor the Bitrix24 REST API](https://oia-shield24.infinitybht.app/blog/bitrix24-rest-api-protection-and-monitoring).

## Next step

**Never lose a Bitrix24 event again** Install OIA Shield24, add your handler URL under Outbound Events, and let the delivery queue retry while your server recovers. Every attempt is recorded.

- [Install on Bitrix24](https://www.bitrix24.com/apps/app/infinitybht_llc.oia_shield24/)
- [Book a meeting](https://oia-shield24.infinitybht.app/#get-started)

---

Published by [OIA Shield24](https://oia-shield24.infinitybht.app). OIA Shield24 is a zero-trust API gateway for Bitrix24. It gives vendors, integrators and AI agents scoped, rate-paced, auditable access to your portal REST API through a proxy endpoint, so nobody needs your master webhook or OAuth token.

Canonical URL: https://oia-shield24.infinitybht.app/blog/bitrix24-outbound-webhooks-reliable-delivery