How to Send WhatsApp Messages Using a REST API

Overview

Sending WhatsApp from your backend is one HTTP request once three pieces are ready: an account, a connected WhatsApp instance, and an instance API key. This guide walks through that path with FlareSend's REST API.

Prerequisites

• A FlareSend account (sign up — free 4-day trial)
• A phone with WhatsApp installed (business SIM recommended but not required)
• Any HTTP client: curl, Axios, Laravel HTTP, Python requests, etc.

Steps

1. Create a FlareSend account and open the dashboard.
2. Create an instance and scan the QR code with WhatsApp until status is connected.
3. Copy the instance API key from API Keys (not a login cookie).
4. Call the send endpoint from your server.

Example curl request

# Instance is implied by YOUR_INSTANCE_API_KEY (no instance_id in the body).
curl -X POST https://api.flaresend.com/send-message \
  -H "Authorization: Bearer YOUR_INSTANCE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "recipients": ["2547xxxxxxx"],
    "type": "text",
    "text": "Hello from the WhatsApp REST API"
  }'

Request fields that matter

Do not invent fields like to or message for this endpoint — FlareSend expects recipients, type, and text.

Tips that prevent failed sends

• Strip spaces and + from phone numbers.
• Keep the WhatsApp session connected; watch disconnect alerts.
• Start with transactional content to people who expect it.
• Log HTTP status and response body; retry carefully with backoff.
• For many recipients, batch within plan limits and add delays.

Beyond the first message

• OTP flows
• Webhooks for inbound
• Bulk messaging
• Full reference: /docs

Troubleshooting

Ship the happy path first, then add monitoring around instance health and API errors.

End-to-end example in plain language

Your server decides a customer should receive a message. It loads the FlareSend instance API key from a secret store. It formats the phone as digits only. It posts JSON with recipients, type, and text. FlareSend delivers through the linked WhatsApp session. Your server stores the API response for support.

That flow is intentionally boring. Boring messaging infrastructure is what lets product teams ship OTP and receipts without reinventing WhatsApp sessions.

Choosing text vs media

Start with type text for OTP and receipts. Add images or documents only when the customer benefit is clear (for example a PDF receipt). Media increases complexity: MIME types, file size, and device offline behavior. Get text reliability right first.

Idempotency patterns

If a payment webhook retries, your job should check whether WhatsApp was already sent for that payment id. A simple unique key in Redis or a database column prevents double messages that confuse customers and burn reputation.

Testing matrix

Test connected instance, disconnected instance, invalid number, empty recipients, and oversized batches. Automate those five cases in CI against a sandbox key if you have one, or against mocked HTTP in unit tests plus a weekly live smoke check.

Observability

Emit metrics for send attempts, successes, client errors, and server errors. Alert when the connected instance drops. Product managers should see WhatsApp health next to payment success rates, not only in engineering dashboards.

Practical scenarios

Here are concrete situations teams solve with this topic.

Scenario A — early-stage product

You need to prove WhatsApp automation this week. Connect a QR-linked number, send a transactional message, and measure whether customers understand and act. Keep the copy short. Log every API response. Expand only after the first path is reliable.

Scenario B — growing SME

Volume is rising and manual WhatsApp replies are failing. Automate the top one or two events first (usually payment or OTP). Train support on what the system already sends. Add scheduling and webhooks after the basics are stable.

Scenario C — developer platform

You are embedding WhatsApp into your own SaaS. Wrap FlareSend behind your service layer so product code never hard-codes HTTP details. Use queues, idempotency keys, and environment-specific API keys. Document the contract for your teammates.

Quality bar before you go live

1. Happy-path send works on a real phone.
2. Failure path shows a clear customer message or retry.
3. Disconnects are visible to an operator.
4. Consent or transactional justification is written down.
5. Someone owns monitoring for the next 30 days.

Common mistakes

• Treating WhatsApp like email blast infrastructure
• Mixing marketing copy into OTP or payment messages
• Ignoring quiet hours across African timezones
• Skipping idempotency on payment webhooks
• Leaving staging keys pointed at production numbers

Fix those five and most production incidents disappear before they start.

What to read next on FlareSend

Browse related solution pages from the footer Solutions menu, skim the FAQ for safety and pricing questions, and keep the API docs open while you implement. When you are ready, start the free trial and ship one real customer workflow end to end.

Implementation checklist

• Confirm consent or transactional context before sending.
• Store API responses for support audits.
• Prefer background jobs so web requests stay fast.
• Respect quiet hours for your customers' timezones.
• Link every automation to a clear customer benefit.

Related FlareSend resources

• Features
• Pricing
• Compare vs Meta Cloud
• Blog hub
• API docs