Integrations

Available on Android panels since v3.25.8.

Use webhooks to connect BAS-IP panels with third-party services and receive real-time alerts for access events, user actions, or automation triggers:

1 Webhook settings structure
2 Creating and testing a webhook
3 Webhook request format
4 Retry mechanism and delivery logic

Webhook settings structure

All webhook settings are located under Integrations in the web interface. This section includes several blocks:

Webhooks stats — shows general statistics for the selected period: number of executed, pending, failed, and successful webhooks;
Webhooks — displays the list of configured webhooks with key parameters: URL, Event types, Timeout, and Max retries.;
Webhooks events — logs all triggered webhook events, including status, server response, and retry count;
Webhooks event retries — logs retry attempts for webhooks with more than zero retries configured.

Creating and testing a webhook

Go to Integrations → Webhooks.
Click New webhook.
In the General settings tab:

Secret ensures request authenticity, prevents forgery, and protects data integrity.

Set the Timeout (ms) — we recommend between 1000 and 30000;
Define Max retries — the number of retry attempts (0 to 5);
Optionally, fill in the Description for internal reference.

Open the Events tab and select the events that will trigger this webhook, such as Unknown identifier.

Check Enabled to activate the webhook;
Enter the destination URL where webhook requests will be sent;
Set the Secret token used for signing and verifying webhook requests;

Open the Headers tab and optionally add custom headers.

Do not use standard HTTP headers when adding custom headers. These include:

Display control: "host", "connection", "keep-alive", "transfer-encoding", "upgrade", "via", "te", "trailer";
Content handling: "content-length", "content-type";
Security: "authorization", "origin", "permissions-policy";
Client/browser: "user-agent", "accept", "accept-encoding", "accept-language";
Proxy infrastructure: "x-forwarded-for", "x-forwarded-host", "x-forwarded-proto", "x-real-ip", "forwarded";
Date/time: "date", "expires", "last-modified";
Cache control: "cache-control", "etag", "if-match", "if-none-match";
CORS policy: "access-control-allow-origin", "access-control-allow-methods", "access-control-allow-headers", "access-control-expose-headers".

Click Confirm to save the webhook.

To test the webhook manually, click the ▶️ button next to it in the list.

Go to the Webhooks events block and click the Refresh button to review event execution:

Event type, Status, Server response, and Retry count are displayed for each event;
Click any entry to open detail view.

Check in the Webhook event details:

Request: URL, headers, and payload.
Server response (e.g., 200 OK).
Retry history, if any.

Common server response codes:
200 OK — successful request;
400 Bad Request — invalid data;
401 Unauthorized — authentication required or failed;
404 Not Found — incorrect URL;
500 Internal Server Error — server issue on the receiver’s side.

If the first attempt fails — for example, if the server is temporarily unavailable — the system will try again several times, gradually increasing the time between each attempt. Once the system receives a response with code 2xx, the status will update to Success, even if there were failed attempts before.

The Retries column shows only retry attempts and does not include the initial one. For example, if Max retries is set to 1, the table will show 0 of 1 before retry begins, while the event details will show 1/2 attempts — one initial attempt and one retry.

Webhook request format

Your webhook server receives two parts in each request:

Custom headers for validation and tracking:
- X-Webhook-Timestamp — time of the request in UNIX format;
- X-Webhook-Attempt — current attempt number (starting from 0);
- X-Webhook-Signature — HMAC signature generated using your secret token.
JSON payload, for example:

{
  "created_at": 175011039636,
  "data": {
    "test": "success"
  },
  "event_id": 50,
  "event_type": "log.access_denied_by_unknown_card"
}

Retry mechanism and delivery logic

For webhooks with Max retries > 0:

The system resends failed webhooks using exponential delays:

Retry delay progression: 0, 15, 30, 60, 120, 240 seconds ±20% random jitter.

You can track retry progress in Webhooks events and Webhooks event retries:
- Retry status: current state (e.g., Retrying, Failed);
- Next retry: when the next attempt is scheduled;
- Last retry: when the last attempt occurred;
- Use the Refresh button to update status.

After all attempts fail, the event is marked as Failed, — e.g., after receiving a 404 response.

Clicking the Retry webhook event button for a failed event starts a single additional attempt, which runs immediately in the background.

This manual retry is not added to the Webhooks event retries queue because it does not initiate a sequence of retries — only one attempt is made.

Your webhook is now fully configured and ready to use. Monitor real-time events in Webhooks events, and rely on automatic retries for delivery assurance.

To change event triggers or settings, just edit the webhook from the list.