How to Send WhatsApp Messages From Your Website Using an API
If you want to connect your website's checkout, registration, or booking system to WhatsApp, you need to understand the structural costs and technical guardrails before you write a single line of code. This is not like sending an email. It is not free, and it is not unlimited. If you build this system incorrectly, your website will slow to a crawl, your messages will fail to deliver, or Meta will ban your phone number within forty-eight hours.
This guide explains how to set up the official WhatsApp Cloud API for your website, the exact costs you will face in India and Pakistan, and how to structure your backend code to handle the integration reliably.
The Real Costs and Limits for India and Pakistan
Meta charges for WhatsApp API usage based on 24-hour conversation windows. You do not pay per individual message. Instead, you pay for the category of conversation you open. These categories are Utility (OTPs, order updates, appointment reminders), Authentication (login codes), and Marketing (promotions, cart abandonment offers).
The rates vary significantly depending on the country code of the recipient. The table below shows the approximate costs for India and Pakistan in their respective local currencies, based on Meta's standard pricing model.
| Recipient Country | Utility Conversation Cost | Marketing Conversation Cost | Free Tier Allowance |
|---|---|---|---|
| India (+91) | About 0.11 INR | About 0.72 INR | 1,000 user-initiated conversations per month |
| Pakistan (+92) | About 4.60 PKR (0.0165 USD) | About 13.30 PKR (0.0477 USD) | 1,000 user-initiated conversations per month |
Business-initiated conversations (messages you trigger from your website database to a user) do not qualify for the free tier. Every single utility or marketing message you trigger to a customer who has not spoken to you first will cost you money from the very first message.
In addition to financial costs, Meta imposes daily messaging limits on new accounts. When you first register your phone number, you are placed in Tier 1. This limits you to sending messages to 1,000 unique customers within a rolling 24-hour period. If your website attempts to send an order confirmation to the 1,001st unique customer in that window, Meta's API will reject the request and return error code 131048.
To move to Tier 2 (10,000 unique customers) and eventually Tier 3 (100,000 unique customers), you must maintain a high quality rating. If users click "Report Spam" when they receive your website's automated messages, your quality rating will drop to Red. When this happens, Meta throttles your daily limit back down to 250 messages or suspends your API access entirely.
Why Your Website Backend Needs an Asynchronous Queue
When a customer clicks "Place Order" on your e-commerce site, your server processes the payment, updates the database, and sends a response to the user's browser. If you write synchronous code that calls the WhatsApp API during this request-response cycle, you are making a major architectural mistake.
The Meta Graph API is secure, but it is not always fast. A standard POST request to the API endpoint can take anywhere from 800 milliseconds to 3 seconds to return a response. If your website waits for WhatsApp to confirm delivery before showing the customer their order confirmation page, your customer will experience a noticeable, frustrating delay. If Meta's servers experience high latency, your checkout process will time out, leading to duplicate orders and abandoned carts.
You must use an asynchronous queue. When an event occurs on your website, your backend should immediately save the transaction to your database, push a lightweight job to a queue runner like Redis, RabbitMQ, or a database-backed queue table, and return a success page to the user. Your queue runner then processes the API call to Meta in the background, completely separate from the user's browser session.
If the API call fails because of a temporary network issue or a Meta rate limit, your queue runner can retry the job three minutes later without affecting the user experience.
How to Structure the API Request
To send a message from your website, you must send an HTTP POST request to Meta's Graph API. You cannot send arbitrary text to a user who has not messaged you in the last 24 hours. You must use a pre-approved template.
Before writing your code, you must create this template inside your Meta Business Suite. For an order confirmation, your template might look like this: "Hello {{1}}, your order {{2}} has been confirmed." Meta's automated system will review and approve this template, which usually takes under five minutes.
Once approved, your website backend must send a JSON payload to the following endpoint: https://graph.facebook.com/v19.0/YOUR_PHONE_NUMBER_ID/messages.
The request must include an Authorization header containing your permanent system user access token. Do not use the temporary 24-hour token generated during setup; your integration will break the next day. The Content-Type header must be set to application/json.
The JSON body must contain the following specific parameters:
- messaging_product: This must always be the string "whatsapp".
- to: The recipient's phone number, including the country code, with no leading zeros, plus signs, or spaces. For example, use "923001234567" for Pakistan or "919876543210" for India. If you include a plus sign, the API will fail.
- type: Set this to "template".
- template: An object containing the "name" of your template, the "language" code (such as "en" or "ur"), and the "components" array which holds the variables (parameters) that replace the placeholders in your template.
If your template expects two text variables, your JSON payload must pass those variables in the exact order they appear in the template. If you pass the wrong number of variables, Meta will return error code 132001, indicating that the parameters do not match the template definition.
When This API is the Wrong Choice for Your Website
Using the official WhatsApp Cloud API is not always the correct path. It requires technical upkeep, developer hours, and a clear budget for conversation fees.
Do not use this system if you want to run cold marketing campaigns. Buying a list of phone numbers in Karachi or Mumbai and triggering automated API messages to them is a fast way to lose your number. Because Meta charges for every conversation, and because cold lists have high block rates, you will spend a large amount of money only to have your API account banned within hours.
Do not use the API if you simply want a button on your website that allows users to chat with you. If a user wants to ask a question about a product, you do not need an API integration. You should use a simple wa.me link instead. These links are completely free, require no developer setup, and open the user's WhatsApp app instantly with your number pre-filled. You can use services like WA Link to generate these links, but keep in mind that such link generators only facilitate user-initiated chats; they do not send automated database-driven alerts from your server.
You should also avoid using unofficial, gray-market APIs that run on virtual Android emulators or automated WhatsApp Web sessions. While these services often promise flat monthly rates with no per-message fees, they are highly unstable. To understand the risks of these platforms, read about the difference between official APIs and gray-market options. These unofficial tools frequently lose connection when WhatsApp updates its web interface, which means your website's critical OTPs and order confirmations will simply stop sending without warning. You can learn more about why these unofficial setups constantly drop connections before risking your business operations on them.
Handling Customer Replies
When you send an automated order confirmation or shipping alert, some customers will inevitably reply directly to that message. They might ask to change their delivery address, ask about shipping times, or simply say "thank you."
If you have not configured a webhook, these replies will disappear. The customer will see that their message was delivered, but you will have no way of reading or replying to it. This creates a terrible customer experience.
To handle these replies, you must setup a dedicated webhook endpoint on your website. This is a public URL on your server that Meta's servers will call via an HTTP POST request whenever a user sends a message to your API number. Your webhook must quickly validate the request, process the incoming message payload, and return a 200 OK response to Meta to prevent them from retrying the delivery.
Once you capture these messages via your webhook, you must either build an internal chat interface for your customer support team or route these messages to a third-party customer relationship management tool. If you do not have the resources to build or manage this, a website API might be too complex for your current operations, and you may want to stick to standard email notifications until your team grows.