# Docs - [Documentation](/docs): WhatsApp inside Bitrix24 and Pipedrive, and a WhatsApp API for your own apps and AI agents. Product pages kept current, a Help Center with real customer questions, and the API reference. - Quickstart: From nothing to a delivered WhatsApp message in under five minutes. - [Quickstart](/docs/quickstart): From nothing to a delivered WhatsApp message in under five minutes. - [Create an account and a key](/docs/quickstart/create-account-and-key): Two ways to get a key — from inside Bitrix24, or on the developer console with an email and a password. No redirect URI, no PKCE, no consent screen. - [Your first call](/docs/quickstart/first-call): List the connections your key can reach, and check you have capacity before you provision another. - [Your first message](/docs/quickstart/first-message): Send a WhatsApp text, read the thread back, and give the customer blue ticks. - Product: How the WASync app in Bitrix24 works, feature by feature: Chat Flows, WASync Chat, calls, connections and CRM records. - [Product](/docs/product): The WASync app inside Bitrix24, documented feature by feature. These pages are the ones the "What's new" list in the app links to, and they are kept current as features change. - [Chat Flows](/docs/product/chat-flows): How a Chat Flow starts, which CRM record it creates or binds to, who it assigns the record to, what happens when the customer goes quiet, and how the flow editor works. - [WASync Chat](/docs/product/wasync-chat): The shared WhatsApp inbox inside Bitrix24 - who sees which conversations, changing the CRM stage, creating or linking leads, quick replies, templates, long messages and choosing the sending number. - [Calls](/docs/product/calls): How WhatsApp calls work in WASync and Bitrix24: where to turn them on, who is rung for an incoming call, answering in the Bitrix24 call card, calling a customer back, and what is logged. - [Connections](/docs/product/connections): How WhatsApp numbers connect to WASync, by QR or through the WhatsApp Business API, and how to handle disconnections, staff access and the trial. - [CRM records and timeline](/docs/product/crm-records): How a WhatsApp conversation is linked to a Bitrix24 contact, lead, deal or Smart Process item, what is written on the CRM timeline, and who becomes the responsible of the records WASync creates. - [Settings and Chat rules](/docs/product/settings): Every portal-wide setting of the WASync app in one place — the Settings page (CRM, ads, alerts, AI, country) and the Chat rules page (who sees what, new chats, stages, required fields). - [Quick replies](/docs/product/quick-replies): Saved answers typed with "/" in WASync Chat and in the CRM tab, personal or shared with the team, with variables for the customer's name, a greeting by their local time and any CRM field. - [Automations](/docs/product/automations): AI-powered Bitrix24 robots that write a personalised WhatsApp message from CRM data when a rule fires — auto-send or confirm first, per-automation model, attachments, statistics. - [Reports and export](/docs/product/reports): The Reports page of the WASync app — conversations, replies by a person, median response time, who is waiting now, a daily chart, a per-employee table — and the full export of conversations to CSV or XLSX. - [WhatsApp groups](/docs/product/groups): The Groups Bridge mirrors the WhatsApp groups a QR number is in into Bitrix24 group chats — members stay on WhatsApp, your team reads and replies from Bitrix24. - Help Center: Answers to real customer questions, one page each. - [Help Center](/docs/help-center): Answers to the questions customers actually asked, one page each: what WASync does, where to click, and the product page that explains it. - Chat Flows: Bots on WhatsApp: when they start, when they stop, reminders, ads, sources and the records they create. - [Chat Flows](/docs/help-center/chat-flows): Bots on WhatsApp: when they start, when they stop, reminders, ads, sources and the records they create. - [How do I make the WhatsApp bot stop when a colleague replies?](/docs/help-center/chat-flows/bot-stops-when-colleague-replies): It stops on its own: every flow has "Stop when a colleague replies" on by default, in Flow settings under Handover. - [The bot started when a customer only replied to a message we sent. How do I avoid that?](/docs/help-center/chat-flows/bot-started-on-a-reply-to-our-message): Keep "Flows do not start on a reply to your team" on (default): a reply within 72 hours of a human message is not a new conversation. - [How do I make the bot write only to new customers, not to people we already talk to?](/docs/help-center/chat-flows/bot-only-for-new-customers): Turn on "Only customers who never wrote to you before" on the Start card; "new" means the number never exchanged a message with any of your numbers. - [Can I start a different flow for each Meta ad?](/docs/help-center/chat-flows/different-flow-per-meta-ad): Yes: pick "From a specific ad" on the Start card and list the ad ids; several flows can share one number, the most specific one wins. - [Can the bot send a reminder if the customer does not reply, and close after that?](/docs/help-center/chat-flows/reminder-and-close-after-inactivity): Yes: "If no reply" in Flow settings or on a question sets a reminder after X minutes, an optional closing message after Y more, then the run closes. - [How do I insert a step between two steps that are already connected?](/docs/help-center/chat-flows/insert-step-between-connected-steps): Hover the line between the two steps and press the "+" that appears; the new step is wired in automatically. - [My flow has 200 steps. How do I find one?](/docs/help-center/chat-flows/find-a-step-in-a-large-flow): Press Ctrl+F in the editor and type a word from the step's title or text; the canvas jumps to it and its connections light up. - [Can a flow look something up in an external system through an API?](/docs/help-center/chat-flows/flow-calls-external-api): Yes, with the "HTTP request" step: any REST endpoint, variables in the URL, headers and body, and JSON fields mapped back into flow variables. - [Can I rotate new conversations among a group of employees?](/docs/help-center/chat-flows/rotate-conversations-among-employees): Yes: the "Assign to" step has a rotation mode over an ordered list of up to 50 employees; each step keeps its own counter. - [The general flow greeted the customer again right after another flow handed them to a person. Why, and how do I stop it?](/docs/help-center/chat-flows/general-flow-greeted-again-after-handoff): An "Any message" flow no longer starts while any flow on that number ended in the last 72 hours; the fix is built in, nothing to configure. - [Leads created by the bot get the wrong source. Can I choose it?](/docs/help-center/chat-flows/choose-crm-source-of-flow-leads): Yes: the "Source" selector on the Start card sets the CRM source of every record the flow creates; without a choice, the Open Channel's source applies. - [The flow creates a new lead although the customer already has an open deal. Can it attach to the existing one?](/docs/help-center/chat-flows/flow-attaches-to-existing-open-deal): It does: a lead flow binds to the contact's open deal, else its open lead, else an open lead holding the number, and creates a lead only when none exists. - WASync Chat: The shared inbox: who sees what, stages, quick replies, linking conversations to records, long messages. - [WASync Chat](/docs/help-center/wasync-chat): The shared inbox: who sees what, stages, quick replies, linking conversations to records, long messages. - [Can I restrict employees to see only the chats of their own leads and deals?](/docs/help-center/wasync-chat/restrict-employees-to-their-own-chats): Yes: each employee has a visibility level in Team (All, Department, Only my records); the default for everyone else is in Chat rules. - [After an agent closes the lead, I want the chat to disappear from them so another agent can take the customer. Possible?](/docs/help-center/wasync-chat/hide-chat-from-agent-after-closing-lead): Yes: Chat rules → Hide closed, with a number of days (0 = immediately); applies to the Department and Only-my-records levels. - [When I close a lead from the chat, the required field "reason" is not asked. How do I enforce it?](/docs/help-center/wasync-chat/required-fields-when-changing-stage-from-chat): Configure the fields per stage in Chat rules → Required fields per stage; the chat then asks for them before moving the record. - [Do you have quick replies? I want to type "/" like in other tools.](/docs/help-center/wasync-chat/quick-replies-with-slash): Yes: type "/" at the start of a line in WASync Chat or the CRM tab; personal and team replies, with {{greeting}}, {{contact.first_name}} and CRM fields. - [A chat stayed linked to someone else's deal. Can I move the conversation to another record?](/docs/help-center/wasync-chat/move-conversation-to-another-record): Yes: "Change record" in the chat header relinks the conversation; the thread stays whole, new timeline entries go to the new record. - [An employee filters by their own name and still sees other people's chats. Why?](/docs/help-center/wasync-chat/employee-filter-shows-other-peoples-chats): The filter also matches the contact's responsible, not only the lead or deal; a per-portal option can make the lead or deal owner win. - [Operators can change the stage from the chat. Can I hide that button?](/docs/help-center/wasync-chat/hide-stage-button-in-chat): Yes: Chat rules → Stage picker has three levels: everyone, administrators only, or hidden. - [My long message was rejected by WhatsApp (over 4,096 characters). What now?](/docs/help-center/wasync-chat/long-message-over-4096-characters): Nothing to do: on Business API numbers a long text is split automatically into several messages at paragraph, line or sentence breaks. - [When I send a template with an image, why does it ask for the image again?](/docs/help-center/wasync-chat/template-with-image-asks-for-image-again): Meta asks for the header file at every send; WASync keeps the sample you uploaded and pre-fills it, so you only confirm or replace it. - CRM records and timeline: Leads, deals, contacts, timeline comments, sources, ads attribution, Smart Processes. - [CRM records and timeline](/docs/help-center/crm): Leads, deals, contacts, timeline comments, sources, ads attribution, Smart Processes. - [The same message appears on lead 1, lead 2 and the contact. Can it be logged on one record only?](/docs/help-center/crm/one-timeline-comment-per-conversation): Yes: Settings → CRM → "Where to write the timeline", option "One comment on the conversation's record"; older entries stay where they are. - [All timeline comments are signed by the person who installed the app. Can they be signed by the operator?](/docs/help-center/crm/timeline-comments-signed-by-operator): They are: messages sent from the Open Channel, WASync Chat or the CRM tab are signed by the operator; incoming ones by the app's technical user. - [The customer writes to number X (from an ad) but already has a deal on another number. I want a separate lead per number.](/docs/help-center/crm/separate-lead-per-whatsapp-number): Turn on "Each number creates its own lead" in Chat rules → New chats from unknown numbers; the record then belongs to the conversation on that number. - [The lead was lost, the customer writes back an hour later, and a new lead is created. Can it reattach?](/docs/help-center/crm/recontact-window-after-lost-lead): Yes: set a re-contact window, in hours, in Chat rules; a lost lead closed inside that window takes the conversation back, optionally reopened. - [Which ad brought the customer? I want the campaign and ad set, not only the ad id.](/docs/help-center/crm/which-ad-brought-the-customer): Add a Meta Ads token in Settings; conversations from Click-to-WhatsApp ads then carry campaign, ad set and ad in the UTM fields of the record. - [Can I send WhatsApp from a CRM Marketing campaign or an automation rule?](/docs/help-center/crm/send-whatsapp-from-crm-marketing-or-automation-rule): Yes: WASync is a Bitrix24 message provider, selectable in CRM Marketing, the "Send message" rule and the message button on a record. - [We work with Smart Processes. Does WASync work on them?](/docs/help-center/crm/smart-processes-support): Yes: the WASync tab, conversations linked to items, timeline, robots and Chat Flows work on every Smart Process type. - [Can the customer's WhatsApp name and photo be copied to the CRM contact?](/docs/help-center/crm/copy-whatsapp-name-and-photo-to-contact): Yes, as an option in Settings → CRM, off by default; it fills only empty fields and never overwrites a name or a photo you already have. - [All new chats land on me, the administrator, instead of the Open Channel queue. Why?](/docs/help-center/crm/new-chats-land-on-the-administrator): Records created by WASync go to the user whose token installed the app unless the rule in Chat rules → New chats from unknown numbers says otherwise. - WhatsApp calls: Answering in the Bitrix24 call card, who is rung, what is logged. - [WhatsApp calls](/docs/help-center/calls): Answering in the Bitrix24 call card, who is rung, what is logged. - [How do I answer a WhatsApp call in Bitrix24 without hunting for the notification?](/docs/help-center/calls/answer-whatsapp-call-in-bitrix24): The call rings in the Bitrix24 call card (Answer, Ignore, Mute, End) and the conversation opens in the WASync tab; Business API numbers with calling on. - [If the responsible person does not answer, do colleagues ring too?](/docs/help-center/calls/colleagues-ring-if-responsible-does-not-answer): Yes: the responsible rings first for a few seconds, then everyone online who has access to that number. - [Who is rung first for an incoming call?](/docs/help-center/calls/who-is-rung-first): Either the contact's responsible or the responsible of the customer's latest open deal; choose in Settings → Calls. - [The call duration in the CRM is wrong; it includes the ringing time.](/docs/help-center/calls/call-duration-includes-ringing): It does not any more: the timer starts when the call is answered, and a missed call is logged with a duration of zero. - Connections and numbers: QR and Business API numbers: disconnections, bringing a number, coexistence, deleting a connection, reliability. - [Connections and numbers](/docs/help-center/connections): QR and Business API numbers: disconnections, bringing a number, coexistence, deleting a connection, reliability. - [Why did my WhatsApp disconnect?](/docs/help-center/connections/why-did-my-whatsapp-disconnect): The alert names the likely cause (device removed by WhatsApp, logout from the phone, number moved); reconnect from Connections with the QR. - [Can I bring my WhatsApp Business API number from Twilio, 360dialog or Wazzup?](/docs/help-center/connections/bring-number-from-another-provider): Yes, with the "Bring a number" wizard: the number, its display name, verification and approved templates come along; the old provider works until the move. - [Can I keep WhatsApp Business on my phone and still have the number in Bitrix24?](/docs/help-center/connections/keep-whatsapp-business-on-phone-and-in-bitrix24): Yes, in coexistence: the number stays in the WhatsApp Business app and is also on the Business API; templates and the 24-hour window apply, calls do not. - [I scanned the QR twice with the same phone and now I have duplicate notes.](/docs/help-center/connections/scanned-qr-twice-duplicate-notes): A second pairing of a number that is already connected is refused; the duplicates from before that guard stay in the timeline and can be deleted. - [I want to delete a connection. What do I lose?](/docs/help-center/connections/what-do-i-lose-when-deleting-a-connection): The number, its conversations in WASync Chat, the Open Channel line created for it and its flows; CRM records, timeline comments and files stay. - [A message sent from the phone at 8 pm did not appear in Bitrix24. Can that happen?](/docs/help-center/connections/message-from-phone-missing-in-bitrix24): Rarely, and only if the connection was down at that moment; a connected number delivers every message, with retries, even during Bitrix24 outages. - API, MCP and billing: Files through the MCP, payments, invoices. - [API, MCP and billing](/docs/help-center/api-and-billing): Files through the MCP, payments, invoices. - [Can the MCP send files, or only text?](/docs/help-center/api-and-billing/mcp-send-files): Files too: the send_whatsapp_file tool takes a public https URL (preferred) or a base64 file up to 5 MB, with a name, a type and an optional caption. - [My card is refused by Stripe. How else can I pay?](/docs/help-center/api-and-billing/card-refused-by-stripe): Write to support: we send a Revolut payment link, and after the payment the licence is activated manually, usually the same day. - [Do I get an invoice?](/docs/help-center/api-and-billing/invoices): Yes: Stripe emails an invoice for every payment; all invoices and your VAT number live in the customer portal (Connections → the number → Manage subscription). - Administration: Plans, trial and invoices; team and access; data and security. - [Administration](/docs/administration): Plans, trial and invoices; who on your team may use which number and what they may do in the app; what WASync stores, for how long, and where. - [Plans, trial and invoices](/docs/administration/billing): A licence per WhatsApp number — WAPP (QR) $19, WABA (Business API) $29, API & agents add-on $12 per month in USD — a 7-day trial, payment by card through Stripe, invoices in the customer portal. - [Team and access](/docs/administration/team-and-access): Who may use which WhatsApp number, what each person may do in the WASync app, which conversations they see, and what Bitrix24 administrators get automatically. - [Data and security](/docs/administration/data-and-security): What WASync stores, for how long, where media lives, what is deleted when a number or the app is removed, and the agreements that cover it. - Concepts: The model behind the API: workspaces, connection kinds, licences, scopes and failure handling. - [Concepts](/docs/concepts): The model behind the API: workspaces, connection kinds, licences, scopes and failure handling. - [Workspaces](/docs/concepts/workspaces): A key belongs to exactly one workspace. What that means for multi-tenant apps, and how a Bitrix24 portal differs from a standalone workspace. - [Connection types](/docs/concepts/connection-types): The provider field is qr or cloud_api. What each one can do, and where the two genuinely differ. - [Licences & trial](/docs/concepts/licences-and-trial): A 7-day free trial per number, then a monthly licence per number. What a slot is, and what happens when one expires. - [Scopes](/docs/concepts/scopes): Four scopes, resolved live on every request. Which endpoints need which, and why marking read is a send. - [Errors & idempotency](/docs/concepts/errors-and-idempotency): Branch on the error code, not the status. And make every retry that costs money safe. - Guides: End-to-end recipes: n8n, MCP, webhooks, pairing, and OAuth2 for third-party apps. - [Guides](/docs/guides): End-to-end recipes: n8n, MCP, webhooks, pairing, and OAuth2 for third-party apps. - [n8n](/docs/guides/n8n): Install the community node, create the credential, build a first workflow, and understand the single-webhook caveat before you add a trigger. - [MCP](/docs/guides/mcp): Connect Claude, Cursor or any MCP client to the remote WASync server. Six tools, no code on your side. - [Webhooks](/docs/guides/webhooks): One signed endpoint per account. Signature verification, the event catalog, the retry policy and secret rotation. - [Pairing code & QR](/docs/guides/pairing-and-qr): The QR rotates every 20 seconds. Ship both paths, because a one-device onboarding cannot photograph its own screen. - [Bring a number from another provider](/docs/guides/bring-your-own-number): Move a WhatsApp Business API number you already run at another provider onto WASync with the in-app wizard, and keep your reputation with Meta. - [HTTP request step in Chat Flows](/docs/guides/chat-flows-http-request): Ask an external system over HTTPS from a flow and use the answer in the next steps. Where the request is made from, what it may call, and how to map the response. - [Leads from WhatsApp chats](/docs/guides/leads-from-whatsapp-chats): How WASync turns a new WhatsApp conversation into a Bitrix24 lead, who it goes to, what happens when the number is already in your CRM, and the re-contact window that keeps a customer who writes back after a closed lead on the same record. - [Campaign and ad set on conversations from ads](/docs/guides/meta-ads-campaign-attribution): Give WASync a Meta Ads token and every conversation that starts from a Click-to-WhatsApp ad carries the campaign, the ad set and the ad in the UTM fields of the lead or deal, with their names on the timeline. - [Smart Processes (SPA) in WASync](/docs/guides/smart-processes): Use WhatsApp on Bitrix24 Smart Process items — the WASync tab in the item card, conversations linked to items, robots and Chat Flows on SPA automation rules, and what an item needs for that to work. - [WhatsApp templates (WABA)](/docs/guides/waba-templates): Create WhatsApp Business API message templates in WASync, follow their approval by Meta, and send them from the CRM chat, from Bitrix24 automation rules and from Chat Flows. - [OAuth2 for third-party apps](/docs/guides/oauth2): Only for apps that other WASync customers install. Authorization Code with PKCE, rotating refresh tokens, and one structural limit. - API Reference: Generated from the OpenAPI contract — one page per operation. - [API Reference](/docs/api-reference): Every endpoint of the WhatsApp Platform API, generated from the OpenAPI contract. - Connections: Discover and manage the WhatsApp connections an access token may use. - [List authorized connections](/docs/api-reference/connections/listConnections): Returns the WhatsApp connections this access token may use. Only connections with an active API add-on appear; an expired add-on hides the connection. Call this first to discover which `id` to send from or read. - [Create a new connection](/docs/api-reference/connections/createConnection): Provisions a new WhatsApp connection inside this grant. The core starts a QR pairing session and returns an initial QR code. Render `qr` (a data-URI PNG) and poll `GET /connections/{id}` every 3–5 s until `status` is `"connected"`, re-rendering the `qr` from every response. **WhatsApp rotates the pairing code roughly every 20 seconds**, so the `qr` in this create response is stale within seconds: a QR left on screen simply never pairs, and nothing surfaces an error to explain why. Do not cache it, and do not treat the create response as the pairing code. **With an API key there is no bootstrap step:** a key is issued against your workspace directly, so this endpoint creates the FIRST connection as readily as the tenth — nothing has to be clicked in a portal UI first. (An OAuth grant, by contrast, can only be issued over connections that already exist, so an OAuth-only integration still needs one connection to exist before it can create more. That is the reason to start with a key.) Standalone workspaces only — a Bitrix24-owned portal is rejected with 403 `forbidden_portal_kind`. Check `GET /account` first: creating past your slot quota leaves the new connection without an active licence. Connections created here are QR/WAPP (`provider: qr`); WABA numbers are onboarded through Meta embedded signup, not this endpoint. **Idempotency (optional).** Creating a connection provisions a WhatsApp session and consumes a paid SLOT at pairing time, so an HTTP client that times out and retries would otherwise create a SECOND connection — and you would silently pay for two slots for one customer. Send an optional `Idempotency-Key` header to make the retry safe: within 24 h the same key + the same body returns the SAME connection with **200** and `Idempotency-Replayed: true` instead of provisioning again; the same key with a DIFFERENT body is rejected with 400 `idempotency_key_reuse`; and while the first request is still in flight the retry gets 409 `idempotency_in_progress` with `Retry-After: 1`. Generate ONE key per customer-onboarding ATTEMPT (a fresh UUID minted right before the call, reused only by that call's retries) — never one per process, per API key, per day, or a constant. Omit the header and behaviour is exactly as before. This is the only endpoint that supports it. - [Get connection status](/docs/api-reference/connections/getConnection): Returns the current status and metadata of a single connection. Poll every 3–5 s during QR pairing — `status` becomes `"connected"` once the user scans the code. The `qr` field carries a NEW pairing code on each poll — re-render it every time. WhatsApp rotates the code roughly every 20 s, so a QR displayed for longer than that will not scan. - [Delete a connection](/docs/api-reference/connections/deleteConnection): Permanently removes the connection and its adapter session. This cannot be undone — the user will need to create a new connection and go through QR pairing again. - [Restart a connection session](/docs/api-reference/connections/restartConnection): Restarts the WhatsApp adapter session without deleting the connection record. After a restart, poll `GET /connections/{id}` and re-render the QR code if `status` returns to `"connecting"`. - [Log out a connection](/docs/api-reference/connections/logoutConnection): Logs the WhatsApp session out and clears session credentials. The connection record is preserved. To reconnect, call `POST /connections/{id}/restart` and re-scan the new QR code. - [Request a pairing code (link with phone number)](/docs/api-reference/connections/requestPairingCode): Issues a WhatsApp **pairing code** for a connection that is waiting to be paired — the alternative to scanning the QR. The customer opens WhatsApp → Settings → Linked devices → **Link with phone number** and types the 8-character code you return. **Why you want it:** a QR needs two devices — a screen showing the code and a phone photographing it. A large share of real onboardings happen on ONE device: the customer completes your flow on the same phone that runs WhatsApp, and cannot photograph its own screen. For those customers the QR path is not inconvenient, it is impossible. **A pairing code is NOT always available.** The engine can decline to issue one, and that is an ordinary outcome rather than an outage — it answers **502 `pairing_code_unavailable`**. **Your application must keep the QR flow on screen as a fallback.** An integration that offers only the pairing code will strand customers with no way to connect at all. **Re-requestable.** Calling this again on the same connection returns a NEW code and does not rebuild the session, so a "send me another code" button is safe. It is capped: **5 requests per connection per 15 minutes**, then **429 `rate_limited`** with `Retry-After`. The cap is not bureaucracy — repeatedly requesting codes for one number is exactly the pattern WhatsApp's anti-abuse systems act on, and the number at risk is your customer's. **Nothing extra is consumed.** This does not provision anything: the connection, its paid slot and its 7-day trial behave exactly as with QR pairing. The licence is claimed when the number actually pairs, whichever way it paired. **Status monitoring is unchanged.** Poll `GET /connections/{id}` until `status` is `"connected"`, and/or listen for the `connection.connected` webhook. There is no separate "code accepted" event. QR/WAPP connections only (`provider: qr`). Meta/WABA numbers (`provider: cloud_api`) are onboarded through Meta embedded signup and answer 409 `not_supported_for_provider`. - Account: Slot quota and connection health for the token's workspace — check before provisioning another connection. - [Slot quota and connection health](/docs/api-reference/account/getAccount): Answers "can I onboard another connection right now?" before you take the order. Everything is scoped to the token's workspace — there is no way to ask about another one. `slots.available` is what `POST /connections` can still consume with an active licence; `slots.nextExpiry` is the date you must renew before, so a slot never expires underneath a customer who already paid. `connections.needsReconnect` counts numbers waiting for their owner to scan a fresh QR (the same state that fires the `connection.disconnected` webhook). **A slot is capacity, not a phone number** and not something you bind to a customer: it attaches when a number actually pairs, and deleting a connection returns its slot to the pool carrying whatever time is left on it, ready for the next number you connect. Map WASync's connection `id` (a stable cuid, echoed by every REST response and by `connection_id` on every webhook) to your own customer record — we mint the id, you map it. Do not try to track slots per customer; track connections. - Messages: Read recent messages and send WhatsApp messages (text, images, video, audio/voice notes, documents). - [List recent messages](/docs/api-reference/messages/listMessages): Returns recent messages (newest first) scoped to the token's connections. Cursor-paginated. - [Send a WhatsApp message (text or media)](/docs/api-reference/messages/sendMessage): Sends a message from one of the authorized connections. Supply either `text` (text message) or `media` (image, video, audio, document, voice note) — not both. Pass an `idempotencyKey` on text sends to make retries safe. - [Mark inbound messages as read (blue ticks)](/docs/api-reference/messages/markMessagesRead): Sends a WhatsApp **read receipt** so the customer sees the blue ticks on the messages they sent you. Call this the moment one of your operators opens the conversation in your own UI. If your agents read WhatsApp inside your CRM, nobody ever opens the chat in WhatsApp — the customer's messages stay on double grey ticks and the conversation feels ignored. **Scope is `whatsapp.send`, not `whatsapp.read`:** marking read TRANSMITS a receipt from your number to the customer's device, so it is an outbound action. Any client that can already send can mark read — no new scope, no re-consent. Supply `connectionId` plus at least one of `phone` / `messageId`. `messageId` is WASync's stable id (a cuid) of an INCOMING message — not `waMessageId`. When both are given, `messageId` wins. Idempotent by nature: re-marking an already-read conversation is a no-op, so no `idempotencyKey` is accepted and no rate limit applies. Retry freely. Connection differences: WAPP/QR connections mark the whole chat; WABA (official API) connections can only mark one specific message, so a `phone`-only request resolves your most recent inbound message from that number automatically. - Webhook: Point WASync at your endpoint and manage the signing secret. Self-service — no app, no consent step. - [Read the webhook configuration](/docs/api-reference/webhook/getWebhook): Returns the endpoint URL, the event types delivered to it, and whether a signing secret is set. **The secret is never returned here.** A read is routinely logged, cached and pasted into support tickets; a secret that leaks through it is a secret you cannot reason about. If you lost yours, rotate it — which is what you would have to do after a leak anyway. - [Set the webhook endpoint](/docs/api-reference/webhook/setWebhook): Points WASync at your URL and returns the signing secret for it. Idempotent — calling it again with a different URL moves the endpoint. The URL must be HTTPS on a publicly reachable host; http, localhost and private ranges are rejected with 400 `invalid_webhook`. Signature scheme (unchanged): every delivery carries `X-WASync-Signature: sha256=` = HMAC-SHA256 of `${X-WASync-Timestamp}.${rawBody}` keyed with this secret. `X-WASync-Timestamp` is epoch milliseconds; reject anything older than 5 minutes. Verify over the RAW body, before parsing. Full contract: https://developers.wasync.app/docs/webhooks - [Rotate the webhook signing secret](/docs/api-reference/webhook/rotateWebhookSecret): Issues a new signing secret and invalidates the old one immediately — there is no overlap window. Deploy the new secret to your receiver promptly; the retry policy (3 attempts with exponential backoff) covers a rollout measured in seconds, not hours. Signature scheme (unchanged): every delivery carries `X-WASync-Signature: sha256=` = HMAC-SHA256 of `${X-WASync-Timestamp}.${rawBody}` keyed with this secret. `X-WASync-Timestamp` is epoch milliseconds; reject anything older than 5 minutes. Verify over the RAW body, before parsing. Full contract: https://developers.wasync.app/docs/webhooks - Security: How keys are stored, how to pin them to addresses, and how fast a revocation takes effect. - [Security](/docs/security): How keys are stored, how to pin them to addresses, and how fast a revocation takes effect. - [API keys](/docs/security/api-keys): Shown once, stored as a hash. What that means for you, and how to handle a key you cannot read back. - [IP allowlist](/docs/security/ip-allowlist): Pin a key to addresses or CIDR ranges. A refusal returns a different code from a bad key, on purpose. - [Revocation timing](/docs/security/revocation): Nothing is cached in the credential. Revoking a key takes effect on the very next call. - [Developer console sign-in](/docs/security/developer-console): Password, email code or passkey to sign in; a mandatory second step for new accounts; devices, activity and how to get back in if you lose access. - Changelog: New endpoints, improvements and breaking changes — newest first. - [Changelog](/docs/changelog): New endpoints, improvements and breaking changes to the WhatsApp Platform API — newest first. - [21 October 2026](/docs/changelog/2026-10-21): A customer who sends several messages before the bot's first reply no longer gets the opening sequence of a Chat Flow twice; the burst starts one run, and a run that was replaced stops sending at its next step. - [20 October 2026](/docs/changelog/2026-10-20): Chat Flows "If no reply" gains an optional closing message the customer receives when a run is closed for inactivity; the inactivity reminder no longer counts as a message from your team, so a customer who answers late starts a fresh run; on Business API numbers a free-text send outside the 24-hour window no longer vanishes — the composer locks and says why; a lead flow no longer creates a second lead next to an open lead that holds the number without a CRM contact; edits or deletions inside a WhatsApp group stay in the group chat instead of opening a one-to-one chat and a lead; and videos or documents sent from Bitrix24 on a QR number no longer fail at 15 seconds while the file still reaches the customer. - [19 October 2026](/docs/changelog/2026-10-19): Campaign and ad set ids on conversations from ads (with a Meta Ads token); WASync is a Bitrix24 message provider — pick "WASync WhatsApp" in CRM Marketing campaigns, in the "Send message" rule and in the message button of a record, and the customer gets a WhatsApp message; flows respect "Each number creates its own lead"; the inbox no longer trips Bitrix24's request limit at the start of a busy day; robots keep working when the portal's first user was deactivated. - [18 October 2026](/docs/changelog/2026-10-18): A "What's new" list inside the app with an unread dot, Chat Flows can start only for customers who never wrote to you, flows no longer create a second lead for a customer with an open lead or deal, records created by a flow follow your "new chats" rule, a flow can choose the CRM source of the record it creates, and the editor gets "Find a step" and highlighted connection lines. - [16 October 2026](/docs/changelog/2026-10-16): A Chat rules setting for the CRM stage picker, and Bring a number now works before your first WABA connection. - [15 October 2026](/docs/changelog/2026-10-15): Smart Processes (SPA) — WASync tab on item cards, conversations linked to items, robots and Chat Flows on SPA automation; re-contact window after a closed lead. - [14 October 2026](/docs/changelog/2026-10-14): Chat Flows gain an HTTP request step, and a guide for bringing a number from another provider. - [13 October 2026](/docs/changelog/2026-10-13): The MCP server can now send files, with a new send_whatsapp_file tool. - [12 October 2026](/docs/changelog/2026-10-12): A "Customer writes first" flow set to "Any message" no longer starts on a conversation another flow has just finished or handed to a person. - [11 October 2026](/docs/changelog/2026-10-11): CRM timeline comments are no longer doubled for replies sent from the Open Channel, a new option writes each message on the conversation's record only, sent messages are credited to the operator who wrote them, and a linked conversation can be moved to another record from WASync Chat. - [10 October 2026](/docs/changelog/2026-10-10): Quick replies with “/” filled in for the open customer, in-product help for them, a fix for duplicate leads with “Each number creates its own lead”, a disconnection alert that explains why WhatsApp removed the device, and QR numbers moved to the Cloud API no longer alerting. - [9 October 2026](/docs/changelog/2026-10-09): A chat flow per Meta ad and several inbound flows per number, a “+” on connection lines in the flow editor, flows that ignore re-delivered messages, and a choice of who is rung first for incoming calls. - [8 October 2026](/docs/changelog/2026-10-08): Answer WhatsApp calls in Bitrix24's own call card with the conversation beside it, the team rung after 8 seconds and through Staff access, an option for one lead per WhatsApp number, and an employee filter that follows each person's visibility. - [7 October 2026](/docs/changelog/2026-10-07): Create or link a lead from WASync Chat, rotation within a group in the Chat Flows “Assign to” step, long messages split on the WhatsApp Business API, honest durations for calls you place, the team rung when the responsible is offline, and the customer's WhatsApp photo and name in Bitrix24. - [6 October 2026](/docs/changelog/2026-10-06): Required fields before a stage change in WASync Chat, templates that keep their header image, chat visibility after a record is closed, the first step of the Chat Flows editor redesign, and leads that always come with a contact. - [30 September 2026](/docs/changelog/2026-09-30): Message media now lives in EU object storage and is served through short-lived signed links; deleted WhatsApp messages and edits apply on QR connections; voice notes sent through the WhatsApp Business API arrive as voice notes; a real health check behind every deploy. - [29 September 2026](/docs/changelog/2026-09-29): One conversation per contact across several numbers, made explicit with a sending-number picker; and a fix for new users whose first two hours of messages showed as read. - [25 September 2026](/docs/changelog/2026-09-25): Chat visibility rules per employee (all / department / only their records), enforced on the server, and automatic lead creation with round-robin assignment for chats from new numbers. - [24 September 2026](/docs/changelog/2026-09-24): Insert CRM fields into chat-flow messages, attach the file stored on the deal or lead, contact and company fields in flows, and values written the way a person would. - [21 September 2026](/docs/changelog/2026-09-21): A conversation whose deal was deleted repairs its own CRM link instead of writing into nothing. - [19 September 2026](/docs/changelog/2026-09-19): Passkeys, two-step sign-in and a security page for the developer console. - [18 September 2026](/docs/changelog/2026-09-18): Late delivery failures reach the Open Channel, and Click-to-WhatsApp attribution always reaches the deal. - [17 September 2026](/docs/changelog/2026-09-17): Call permission recorded and shown in the widget, buttons and the call-permission card in the template builder, tapped template buttons reach chat flows, two new flow nodes. - [15 September 2026](/docs/changelog/2026-09-15): Delete a number and close a workspace from the developer console, and a Click-to-WhatsApp attribution that survives Bitrix rejecting a freshly created deal. - [14 September 2026](/docs/changelog/2026-09-14): Create and revoke API keys from inside Bitrix24, and a checkout that repairs a stale Stripe customer on its own. - [8 September 2026](/docs/changelog/2026-09-08): A precise error when WhatsApp cannot find the recipient, and purchased slots that apply themselves. - [18 August 2026](/docs/changelog/2026-08-18): Pairing codes — connect a number without scanning a QR. - [17 August 2026](/docs/changelog/2026-08-17): API keys as the default credential, IP allowlists, webhook self-service, Idempotency-Key, and the canonical host. - [8 August 2026](/docs/changelog/2026-08-08): Connection lifecycle events and GET /account slot quota. - [25 July 2026](/docs/changelog/2026-07-25): Read receipts, and messageId becomes WASync's stable id. - [13 July 2026](/docs/changelog/2026-07-13): Webhooks reference, llms-full.txt and a CORS-open spec. - [2 July 2026](/docs/changelog/2026-07-02): 402 responses carry a payment link when the API add-on is inactive. - [19 June 2026](/docs/changelog/2026-06-19): WhatsApp Platform API launch.