What is the WhatsApp Business API, and how do you connect a business number?

Example scenario: Picture a tour agency in Antalya. The booking number lives in the WhatsApp Business app on the reception phone. At each shift change the phone passes from hand to hand, and the chat history stays on that device. If the phone breaks or goes missing, reaching the history depends on a backup. With an API connection the message arrives in software and the team reads it there; when the shift changes, no phone has to pass from hand to hand.

The app serves one person or a very small team; when several people start looking at the same number, the API enters the picture. Which to pick at each stage is covered in WhatsApp Business app or API.

A business that gets the API is surprised on day one: the API itself offers no screen. A message arrives, lands on a server, and unless software shows it, nobody sees it. That is why the API is always paired with an inbox; the question is less the API itself than which record the message lands on.

Getting the message onto the customer card is a separate decision. If it stays only in a chat screen, the problem has moved from the phone to the computer, not been solved. You can read how this step is set up on the WhatsApp CRM integration page.

• A Meta business account is opened and the company details entered.
• For higher sending limits and a trusted appearance, the business is verified; documents and domain are checked.
• The number is chosen and confirmed with a code sent by SMS or voice call.
• The display name customers will see goes through Meta review.
• The number is connected to inbox software, either directly through Meta's cloud API or through a solution partner.

If the number is in the phone app today, the conditions for moving it depend on Meta's current rules. Before setup, ask two things: can the number keep working in the app too, and what happens to the old chat history? Do not move the number without both answers in writing. Who will have access on setup day to the line where the verification code arrives by SMS or voice call is also decided in advance; if the code does not reach that line, the connection is not completed.

• Is the number registered to the company, or is it an employee's personal line?
• Who will read the messages, and who will have permissions?
• Which notifications go out often: orders, appointments, payment reminders?
• Where is customer consent kept?
• Do you need the old chat history?

Once the questions on the list have written answers, it is clear what changes on the day of the switch. Say a dental clinic sends appointment reminders one by one from the receptionist's phone today. When it moves to the API, the reminder becomes a template, passes Meta review, and is sent from the software. If the template text is not written in advance, reminders stop on the day of the move.

A furniture shop wants to say an order has shipped. If the customer has been quiet since the last exchange, the message cannot go as free text; it needs a pre-approved utility template. Templates fall into categories such as marketing, utility, and authentication, and are priced by category.

The length of the service window and the price table are in Meta's current documentation and change from time to time; who the message fee is paid to, as an item separate from the licence, is covered in the guide to CRM cost. Getting the customer's consent before sending marketing messages is a separate rule; check the Turkish rules on commercial messages for your own case with your legal adviser.

The everyday meaning of this rule is simple. Answering a customer's question quickly is good for the customer and keeps the free reply window open. The longer the reply takes, the more the conversation needs a template, and a natural exchange turns into a formal notice.

Template text needs care too. Meta can reject content that does not fit the template category, or change the template's category, so adding a promotion to a message sent as a utility notice can come back rejected or recategorised. Writing templates plainly and to their purpose makes approval smoother. For an online shop, order confirmation, shipping notice, and return status are separate templates; each carries its own purpose and is approved in its own category. The template list should also sit with one owner on the team.

Some tools read the web session left open on a phone and carry the messages into a panel. Setup is easy, which makes them tempting. But when the phone switches off or the session drops, the link breaks. If bulk or automated sending is detected, the number can be restricted, and the number your customers know stops answering one day.

Another problem with these tools is the record. Messages are read from the phone's session; when the phone changes or the session closes, the history in the panel can end up incomplete. If the aim is to keep customer history with the company, this route does not serve that aim either.

The message lands in the Corex360 inbox and, if the number is registered, on the customer's card; if not, a new card opens. We described how the conversation turns into an opportunity and a quote once it is on the card in how a WhatsApp conversation lands on the customer card. When several people look after the number, each conversation is assigned to an owner and the unanswered comes forward. The inbox is the same in the browser and in the mobile app; the salesperson in the field and the team in the office see the same card.

Messages are kept in the Corex360 core, on Corex360 Cloud or on your own server. Access is role-based and logged, and personal data is processed under KVKK (Turkey's personal data protection law). You will find the details on the Corex360 security and access model. We build the demo with your own WhatsApp number and review together how the number is used today.