WhatsApp Business Platform for real estate teams

The WhatsApp Business app is designed for businesses that manage conversations directly in the app with features such as a business profile and saved replies. The WhatsApp Business Platform is the API-based option for connecting WhatsApp to business software, automated workflows, shared agent handling, and reporting. The right choice depends on the workflow and team, not on which name sounds more advanced.

An individual agent with manageable volume may need only disciplined use of the app. A brokerage may need the Platform when conversations must enter a shared queue, retain portal context, trigger ownership rules, or connect to an existing CRM. Document the problem first because moving to an API does not automatically create clean data, good replies, or accountable handoffs.

Meta’s Cloud API is the hosted API within the WhatsApp Business Platform. At a high level, business software sends approved WhatsApp messages through Meta’s interfaces and receives inbound messages and message-status events through webhooks. A production design therefore needs both a sending path and a reliable event-receiving path.

Current Meta documentation describes webhook events for incoming messages and for delivery states such as sent, delivered, and read. Store the platform message identifier so retries or redelivered events can be deduplicated. Delivery is not the same as a useful response, but reliable delivery state is essential for knowing whether the workflow reached the buyer and whether the team needs another action.

The Platform transports messages. Your operating system still has to decide which property the message concerns, whether the contact already exists, who owns the conversation, which information is approved, and when an agent must act. Treating an API connection as the finished integration leaves the most important real-estate decisions undefined.

Create one canonical conversation record that can retain multiple property interests without duplicating the person. Store the original source and listing separately from inferred requirements. A portal event, a WhatsApp message, and a human note are different kinds of evidence; preserving that distinction makes later routing and review more dependable.

WhatsApp distinguishes user-initiated service conversations from business-initiated messages. Current Meta documentation uses a 24-hour customer service window for non-template replies after a user message, while approved templates support eligible business-initiated communication outside that window. These rules, categories, and prices can change, so verify the live documentation during implementation and before each major campaign change.

Do not make the window a hidden technical detail. It affects follow-up design, agent tasks, template approval, and what happens when a buyer replies after a long pause. The workflow should tell an agent whether a normal reply is available, whether an approved template is required, and whether the planned message still matches what the buyer expected.

A template is a pre-approved format used for a defined business-initiated purpose. It is not permission to send any message to any old lead. Keep an inventory with template name, category, intended event, required variables, owner, approval status, language, and last review date. Remove obsolete templates so agents do not choose between several near-duplicates.

Variables should insert known facts, not hide substantive claims. A viewing reminder can safely use a confirmed date, property, and agent. A template should not assemble uncertain prices or availability from an unreviewed source. Preview every language version and failure state, including missing variables and a contact who has opted out.

Webhook handling must be durable because a buyer may send several messages quickly and delivery events may arrive independently. Record the event and platform message identifier, preserve ordering information, and make duplicate processing harmless. An acknowledgement should not be sent twice because the same event was delivered again.

Plan for unavailable downstream systems. If the property source or lead store cannot be reached, do not invent a generic successful path. Surface the failure for an operator, retain the inbound message safely, and recover in a way that does not lose ownership. Test retries, delayed events, malformed content, unsupported media, and a manual agent reply arriving during automation.

A handoff policy is only useful if the integration can enforce it. The system needs a conversation state that indicates whether automation or a person is active, an event that transfers control, and a visible way for the agent to release or retain that control. Parallel replies from a bot and agent create confusion even when each message is individually correct.

Current Meta documentation includes webhook patterns and agent-control concepts that can support shared handling, but the exact architecture depends on the implementation. Define the user experience independently: tell the buyer when a person is taking over, pass the full context, and keep a direct route to assistance. Review the live platform documentation for the supported mechanism before building.

WhatsApp’s Business Messaging Policy requires businesses to contact people in line with consent and to honour requests to stop. The business remains responsible for the method of permission and applicable law. Store when and how permission was obtained, which business was named, the expected message category, and any later change in preference.

Inbound interest in one property does not automatically justify unrelated bulk promotion. Design stop processing across every sending path so an opt-out recorded by an agent also blocks automation and campaigns. Test wording beyond an exact keyword: ‘please leave it’, ‘not looking anymore’, and ‘contact me in December’ need different outcomes but all need to be visible.

Use a test number and synthetic data first. Then pilot one source, one team, and a controlled property set. Monitor webhook failures, duplicate events, template errors, delivery states, unanswered inbound messages, ownership gaps, and handoff delays. Keep a manual recovery route until the team can diagnose those failures without vendor intervention.

The review should include agents, not only developers. A correct API response can still create an unusable queue or a confusing buyer exchange. Measure whether the Platform improves source context, first useful response, assignment, and recovery. Expand after those basics work consistently; do not use message volume as the definition of success.