Bitrix24 API integration for brokerages: what connects to what

What is the Bitrix24 REST API, in plain words?

Bitrix24 is a business platform that bundles a CRM (a database of leads, contacts and deals), tasks, chat and calls. An API is a doorway that lets another program talk to it. REST is simply the common way those doorways are built. Through Bitrix24's REST API a program can create a lead, update a deal, read a contact, add a task or log a call.

Bitrix24's developer documentation describes two ways in:

• Webhooks: An inbound webhook is a secret web address. Anyone holding it can call Bitrix24 with the permissions of the employee who created it, limited to the areas chosen. An outbound webhook goes the other way: Bitrix24 sends a message to your address when something happens, such as a deal changing stage. The documentation says an administrator, or an employee the administrator allows, can create inbound webhooks.
• Apps: Local apps that you build for one account, or apps published in the Bitrix24 Market for anyone to install.

Treat an inbound webhook address like a password. If it leaks, someone can read or change your lead data.

What limits should an owner know about?

• Request speed: Bitrix24's limits page says each account has a counter. On Enterprise plans the counter drains at 5 requests a second with a blocking threshold of 250. On all other plans it drains at 2 a second with a threshold of 50. Go over and Bitrix24 returns an error until the counter drops. Several connected tools share the same counter.
• Run-time limit: On the cloud version Bitrix24 also tracks how long each method runs, and blocks a method that uses too much time.
• Plan access: The webhook documentation names no plan for inbound webhooks, only that the account needs REST access. Bitrix24's pricing page, however, advertises unlimited REST API access on its Vibe+ plans, so ask Bitrix24 or your partner to confirm what your plan allows before you plan a build.

For a mid-sized brokerage this is usually not a problem if connectors are written sensibly, for example by sending requests in batches instead of one at a time.

How do Property Finder, Bayut and Dubizzle leads get into Bitrix24?

Bitrix24 does not read your portal accounts by itself. A connector has to collect enquiries from each portal and create a lead. There are two routes. The Bayut side is explained in what Bayut's API offers brokerages.

Ready-made app. PropBridge, an app in the Bitrix24 Market made by VortexWeb, a Dubai Bitrix24 partner, creates a Bitrix24 lead for each enquiry from Property Finder, Bayut and Dubizzle (UAE property listing portals; Dubizzle is a classifieds site from Bayut's group). Its page says each lead carries name, phone, email, portal, listing reference, message and time, and that it removes duplicates by phone and email. It lists monthly prices in dirhams, from a free tier of 10 leads, AED 99 for 100 leads, AED 249 for 300 leads, to AED 499 for unlimited leads. The page also says you must ask your account manager at each portal to enable API or developer access. Note that the app asks for broad access to your CRM data, so read what permissions you are granting.

Custom connector. A developer writes a small service that checks regularly for, or receives, enquiries from each portal and calls Bitrix24's lead method. It costs more up front but you control the rules: which agent gets the lead, what happens at midnight, how duplicates merge. I cover the portal side in more detail where I compare the platforms themselves, but the principle is the same: the portal must grant access, and without that no connector can help you.

If a vendor tells you a portal link is "automatic," ask who holds the portal credentials, what happens when a token expires, and who gets alerted if leads stop arriving. Silent failure is the real risk here.

What about WhatsApp, Meta ads and your phone system?

• WhatsApp: Bitrix24's pricing page lists WhatsApp integration from the Basic plan and WhatsApp marketing from Standard. The chat itself still needs a WhatsApp Business connection (the official business version of WhatsApp for companies), and message rules are set by Meta, the company that owns WhatsApp, Facebook and Instagram, not Bitrix24. Check Bitrix24's current connector page for how it connects.
• Meta ads: Leads from Facebook and Instagram lead forms can be passed into Bitrix24 either by a built-in connector or by a middleman such as Zapier or Make (tools that link apps together without code). I compare those two in my Zapier vs Make guide. The pricing page lists ad automation from the Professional plan; I have not verified exactly which ad platforms are covered, so confirm that before you buy.
• Phone system: The pricing page lists telephony integration from Basic. Whether your particular UAE provider connects directly depends on the provider. If it exposes an API or webhook, a developer can log each call, and attach it to the right lead.
• Website forms: Bitrix24 has its own web forms, and its documentation includes a tutorial on connecting website forms to the CRM through the API.

How can software and AI make these integrations pay off?

Getting leads in is only the first half. A connector earns its keep with what it does next.

• Speed to first reply: When a portal lead arrives, the connector can assign it by your rules and message the agent on WhatsApp within a minute. An AI model can draft a first reply from the listing and the enquiry text. A human agent should still read it and send it, or you approve a short fixed template for after-hours.
• Duplicate and cross-portal matching: The same buyer often enquires on Property Finder and Bayut. A connector can merge them into one lead so two agents do not call the same person.
• A silent-failure alarm: A simple check that alerts you if no portal lead has arrived in four hours during working time.
• What a human still does: Qualify the buyer, build trust, and handle anything involving a contract or compliance. AI does not know your market, and it can get a price or an availability wrong if it is guessing.

I build and maintain these connectors, plus the dashboard that shows leads by source and uncontacted leads, and you own the code and the accounts. If your needs are bigger than one connector, my AI integration services page explains how I work.

To test the idea cheaply, give Claude, an AI assistant, a sample of five anonymized portal enquiries and the agent roster and ask: "Draft a two-line first reply in English for each, ask one qualifying question, and say which agent should take it and why." You will see quickly how good a draft is and where it needs a human.

What the limit errors mean in practice

When a connector misbehaves, the cause is often one of a few documented errors. Knowing them helps you ask your developer sensible questions.

• Too many requests (error QUERY_LIMIT_EXCEEDED, HTTP 503): The connector sent calls faster than the account's counter drains. The fix is to slow down and retry with growing pauses, and not to run several parallel streams from the same server. Bitrix24's page says limits are tracked per account and apps on the same server address share them.
• Too much processing time (error OPERATION_TIME_LIMIT, HTTP 429): One method has used too much run time in the last ten minutes. Only that app or webhook method is paused, and the response says when to retry.
• Timeouts: A single cloud request must finish within 60 seconds. Big jobs should be split into smaller pieces.

At the 2 requests a second drain rate of non-Enterprise plans, Bitrix24 notes that adds up to about 172,800 requests a day, which is plenty for lead routing but a poor fit for copying your whole history. The documentation also says the API is not built for bulk transfer of large datasets and points to its built-in BI connector (a reporting feed) for that.

The risk most owners are never told about: lost events

If you want Bitrix24 to tell another system "a lead just changed stage" (an outbound webhook or event), read this. Bitrix24's performance guidance says events follow user actions and cannot be throttled, so a bulk update can fire thousands at once. It also says it does not resend an event if your receiving address does not answer properly. For a brokerage that means a busy portal launch day is exactly when a badly built connector drops leads. The recommended design is for the receiving address to accept the message and reply immediately, store it in a queue, and process it separately. Ask any developer: "What happens to an event if your server is down for ten minutes?" If they have no answer, they have not built for it. A cheap safety net is a nightly check that compares the day's leads in Bitrix24 with what the downstream system received.

Webhook, local app or Market app: a decision rule

• Inbound webhook if one developer needs to push or pull data for your own account and no screen is needed. Fastest, but the address is a password.
• Local app if agents need a custom screen inside your own Bitrix24 account, such as a simple "today's calls" view.
• Market app if you are happy with a ready-made tool others use, such as a portal connector, and want it installed by an admin. Read the permissions it requests.

Before you sign off on a connector

1. Written confirmation that each portal has enabled API access on your account.
2. Who owns the portal credentials and the webhook address, and where they are stored.
3. What happens on a duplicate, an error and a downtime, and who is alerted.
4. A plan-level check of REST access and limits on the plan you actually pay for.
5. A way to remove the connector's access in one step if the relationship ends.

How would I approach it?

I would start with one source, usually the portal that sends the most leads, and get that arriving reliably with an alert if it stops. Then add WhatsApp, then ad leads. I would not build anything until the portals have confirmed your API access in writing, because that is the step you cannot code around. Confirm any portal terms with the portal itself.