How to Send WhatsApp Messages From Your Website Using an API

The most common request we get from small web teams is some version of: when someone fills in the form on our site, send them a WhatsApp message. It sounds like a five-minute task. It usually takes an afternoon, mostly because of decisions people didn't expect to make.

This post walks through the shape of that integration. We'll keep it independent of any one language, so a PHP, Node or Python developer can follow it.

The one rule: never call it from the browser

Your website has two halves. The front end runs in the visitor's browser. The back end runs on your server. The call to the WhatsApp API must come from the back end, always. If you put an API key in JavaScript that loads in the browser, anyone can open developer tools, copy it, and send messages as you.

So the flow looks like this. The visitor submits a form. Your server receives it, checks it, saves it, and then asks the WhatsApp API to send a message. The browser never sees the key. We dig into this in keeping WhatsApp API keys safe.

The steps, in order

1. 1Collect the phone number with the country code, and ask for consent in the same form.
2. 2Validate the number on the server. Strip spaces and symbols, and reject anything that doesn't look like a real mobile number.
3. 3Save the submission first. Your own database is the source of truth, not WhatsApp.
4. 4Queue the message rather than sending it inside the page request.
5. 5Call the API from a background job, with the API key read from an environment variable.
6. 6Record the result and any message ID, so you can match delivery updates later.

Why a queue matters even on a small site

If your page waits for WhatsApp to respond before showing 'thank you', a slow reply makes your site feel broken. Worse, if the API call fails, the visitor may think their form didn't go through and submit it three times. Put the send into a background job, return the page immediately, and retry quietly if it fails.

A queue also protects you from sending too fast. We cover that in why your messages need a queue and a sensible pace.

Writing the request

Every provider has its own field names, so follow their documentation. In general, a send request carries four things: your API key in a header, the recipient number, the message type (text, template or media), and the content. On a gateway like WA Getway, you create an API key in the dashboard and use it with the REST API, and the message goes into a paced queue on the gateway side.

If you are using Meta's official Cloud API, remember that a message to someone who hasn't messaged you in the last day must be a template. A free-text message will simply be rejected. See the 24-hour window for the details.

Handling failures

• A wrong or non-WhatsApp number is normal. Log it and move on, don't retry forever.
• A network timeout deserves a retry after a short delay, with a limit on attempts.
• An authentication error means your key is wrong or revoked. Stop and alert someone.
• A rate-limit response means slow down. Wait, then resume at a gentler pace.

Keep failures out of the visitor's sight. They don't need to know your WhatsApp send retried twice.

Tracking what happened next

Small details that save support calls

• Show the visitor a clear message such as: We will WhatsApp your confirmation shortly. Do not promise instant delivery.
• Let users correct a typo in their number before they leave the page.
• Send from a recognisable business name and profile picture, so the first message does not look like spam.
• Add a way to reply STOP or contact you, and honour it.
• Keep an internal log of every attempt with a timestamp, so you can answer the question: did we actually send it?

None of this is exciting, but it is where integrations either feel solid or feel flaky to the people using them.

Sending is only half the job. You want to know if the message arrived and if the customer replied. That's done by receiving callbacks from the API at an address on your site. We explain the idea in WhatsApp webhooks for non-developers and the status meanings in sent, delivered and read.

If you would rather not build this plumbing yourself, we do custom integrations for exactly this. Take a look at our services or tell us what your site does and we'll suggest the lightest approach.