Testing Your WhatsApp Integration with cURL and Postman Before You Go Live

Most integration bugs show up after the code is already wired into a form handler, a CRM webhook, or a cron job — which makes them annoying to isolate. The fix is to test the API on its own first, with nothing but a terminal, before any of that code exists. Fifteen minutes with cURL (or Postman, if you prefer a GUI) catches the three things that cause almost every "it doesn't work" ticket: a number in the wrong format, a WhatsApp session that isn't actually paired, and a misread of what a 202 response versus a 429 actually means.

This walks through that sequence against the TextMeFlow API, step by step.

Get your API key and confirm your account

Every account gets an API key of the form tmf_<your_api_key> at signup. Before sending anything, confirm the key works and see your current plan and usage:

curl -s https://api.textmeflow.eu/v1/accounts/me \
  -H "Authorization: Bearer tmf_your_api_key_here"

A 200 with your account JSON means the key is valid. A 401 means you copied it wrong or it's for a different environment — check that before debugging anything downstream. If you're on Postman instead, set {{api_key}} as a collection variable and reuse it in every request's Authorization header, rather than pasting the key into each request.

Confirm WhatsApp is actually paired

The API key being valid doesn't mean WhatsApp is connected. TextMeFlow links to a real WhatsApp account via a QR-code pairing flow, and messages sent before pairing (or after a session drops) will fail even though the request itself is well-formed. Check pairing status before you test sending:

curl -s https://api.textmeflow.eu/v1/accounts/me \
  -H "Authorization: Bearer tmf_your_api_key_here" | jq '.session_status // .status'

If it's not connected, pair first (POST /v1/accounts/me/pair returns a QR code to scan), then poll /v1/accounts/me/pair/{pair_id}/status until it flips to connected. Skipping this step is the single most common reason a "working" integration suddenly sends nothing — usually because the paired phone went offline or someone logged the WhatsApp session out elsewhere.

Send a real test message

With a valid key and an active session, send a message to your own number first — not a customer's:

curl -s -X POST https://api.textmeflow.eu/v1/messages \
  -H "Authorization: Bearer tmf_your_api_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+32472000000",
    "text": "Test message from the API — ignore"
  }'

A successful call returns 202 Accepted with a message_id and status: "queued" — not "sent". That distinction matters: 202 means the API accepted the job into the send queue, not that WhatsApp has delivered it yet. Save the message_id and check it a few seconds later:

curl -s https://api.textmeflow.eu/v1/messages/<message_id> \
  -H "Authorization: Bearer tmf_your_api_key_here"

For a media test, add a media_url field pointing at a public image or PDF URL — attachments up to 100 MB work the same way, no separate endpoint.

Deliberately trigger the errors you'll hit in production

Testing the happy path only tells you the API works when everything is perfect, which is not the environment your production code runs in. Trigger the failure modes on purpose so your error handling has actually been exercised:

• Bad phone format — send "to": "0472000000" instead of E.164 (+32...). You should get a 4xx with a clear message, not a silently dropped send. If your form collects numbers without country codes, this is the bug you'll hit most in the wild — see the phone number validation guide for the fix.
• Rate limit — fire ten requests in under a second from a quick shell loop. TextMeFlow enforces roughly 1 message per second sustained; past that you'll get 429 Too Many Requests. Confirm your integration backs off and retries rather than looping tightly — see handling rate limits and message status for the retry pattern.
• Expired or disconnected session — log out of WhatsApp Web on the paired device (or call DELETE /v1/accounts/me/session) and send again. You want to see what error comes back so your code can alert you instead of failing silently for days.

Legacy TextMeBot-style testing

If you're migrating from TextMeBot, the drop-in GET /send.php endpoint accepts the same query-string shape your old code already uses:

curl "https://api.textmeflow.eu/send.php?recipient=%2B32472000000&apikey=tmf_your_api_key_here&text=Hello"

It returns plain HTML with Result: <b>Success</b> or Result: <b>Failed</b>, so any code doing substring matching on that string keeps working unmodified while you plan the move to /v1/messages. Full details are in the TextMeBot migration checklist.

Build a Postman collection once, reuse it forever

If your team will touch this integration more than once, turning these cURL calls into a small Postman collection pays for itself: one request per endpoint (accounts/me, pair, messages POST, messages/{id} GET), the API key as a collection variable, and a saved example response for each. New team members can then verify the integration is alive in under a minute without reading code — useful when a support ticket comes in asking "is the WhatsApp thing down" and you need a yes/no answer fast.

The full request and response shapes, including every field and error code, are documented in the API reference.

Once your test calls behave the way you expect — 202 on send, a real message_id, clean errors on bad input — wiring the same calls into your actual application is the easy part. Sign up for the free plan and run through this checklist against your own account before you write a single line of integration code.