TextMeBot to TextMeFlow: a migration checklist for production traffic

Swapping api.textmebot.com for api.textmeflow.eu is, technically, a one-line change — the TextMeBot-compatible endpoint accepts the same query parameters and returns the same Result: Success / Result: Failed body. But "the request shape matches" and "I'm confident cutting production traffic over" are two different things. If you're running live automations — booking confirmations, order updates, reminders — through TextMeBot today, here's the checklist we'd actually follow.

1. Inventory every place that calls TextMeBot

Before touching anything, grep your codebase, your n8n/Make/Zapier scenarios, and any Google Apps Script or cron job for textmebot.com. It's common to find three or four call sites: a backend service, a spreadsheet macro someone wrote two years ago, and a Zapier webhook nobody remembers configuring. Migrating "the app" and missing the spreadsheet macro is how a client stops getting order confirmations and nobody notices for a week.

2. Test on the free plan before touching production

Create a free TextMeFlow account (50 messages/month, no card required), scan the QR code with a spare or secondary number, and point a copy of one integration at api.textmeflow.eu with a test API key. Send a handful of real-shaped messages — including whatever variables your templates interpolate — before you touch the production key or number.

3. Map TextMeBot's bare "Failed" to TextMeFlow's specific reasons

This is the part teams skip and then regret. TextMeBot's compat response only tells you Result: Failed. TextMeFlow's /send.php endpoint runs the request through the same validation pipeline as the native API and returns a specific reason in the body — invalid_apikey, recipient_opted_out, quota_exceeded, and so on. If your existing code only checks for the literal string Success, it'll keep working unchanged. But it's worth spending twenty minutes updating your error handling to branch on the reason string — it turns "message silently didn't arrive" into "this customer opted out, stop retrying them."

4. Check your button slots, if you use them

If any of your TextMeBot messages use button1/button1id through button3/button3id, know that TextMeFlow supports the same three-slot shape, rendered as native CTA-URL buttons. The label comes from buttonN, the destination URL from buttonNid. Non-URL button payloads are ignored — same constraint TextMeBot has, since WhatsApp itself caps native buttons at three.

5. Pick an actual cutover window, don't just flip it live

Even a "one-line" change deserves a rollback plan. Keep the old TextMeBot key active and unchanged while you switch one integration at a time — start with the lowest-stakes one (an internal alert, not a customer-facing order confirmation). Watch it for a day. Only then move the higher-stakes flows. If something breaks, reverting is just pointing the URL back.

6. Decide when to leave the compat endpoint behind

/send.php exists so migration costs you nothing on day one — but it's a bridge, not a destination. Once you're confident in the cutover, new code (and eventually old code, on your own schedule) should move to the native POST /v1/messages JSON API. It returns structured errors instead of a string to parse, and a message id you can poll for delivery status. Pair it with inbound webhooks — HMAC-signed, with retries — if you also want replies routed back into your system instead of just sitting in WhatsApp.

7. Know what changes underneath, even if your code doesn't

The request shape is compatible; the backend behind it isn't the same product. Messages route through EU infrastructure (Paris, France), paid plans carry an automatic GDPR data processing agreement, and every send — compat endpoint or native API — passes through the same anti-spam layer: per-number rate limits, STOP handling, and quiet hours. None of that requires code changes on your end, but it's worth knowing it's there, especially if a compliance question comes up later. For background on why we built it that way, see our note on the TextMeBot alternative question.

The whole migration, in order

Inventory call sites → test on free plan → update error handling for specific reasons → verify buttons if used → cut over integration by integration → keep the compat endpoint as long as you need it → move to the native API when you're ready. None of these steps are hard on their own; skipping them is what turns a "one-line change" into a Monday-morning incident.

Start on the free plan — 50 messages/month, no credit card, and the same anti-spam pipeline production traffic gets.