# WhatsApp or SMS? How to choose the channel before you send, and fall back when WhatsApp fails > A WhatsApp message only arrives if the recipient uses WhatsApp, has opted in to hear from you and can receive it; otherwise the Cloud API reports a failure such as error 131026. This guide shows how to choose the channel per recipient, read Meta's delivery errors, and fall back to SMS automatically. - Canonical URL: https://www.broadnet.me/blog/whatsapp-or-sms-choose-channel-before-you-send - Language: en - Last updated: 2026-09-27 - Publisher: BroadNet (https://www.broadnet.me) - Published: 2026-09-27 - Author: BroadNet Editorial Team Send on WhatsApp when the recipient has opted in to hear from you there and has a working WhatsApp account; send by SMS, or fall back to SMS, in every other case. On the WhatsApp Cloud API, a message to a number that cannot receive it fails with error 131026, and you only learn that from the status webhook, not from the send response. The reliable pattern is to record each customer's channel consent at opt-in, check what you lawfully can before sending, and let a failed WhatsApp status trigger an SMS. BroadNet runs both channels behind one [Omnichannel API](https://www.broadnet.me/products/omnichannel) with explicit fallback rules. ## Key takeaways - Error 131026 means Meta could not deliver the message. Meta lists three possible reasons: the number is not a WhatsApp number, the recipient has not accepted the latest terms, or the recipient uses an old WhatsApp version. - A successful API response only means the request was accepted. Delivery is reported later by the status webhook: sent, delivered, read or failed, with an errors array on failure. - Having a WhatsApp account is not permission to message someone: Meta's policy requires the person's number and their opt-in to hear from you. - Outside the 24-hour customer service window, WhatsApp only accepts template messages (error 131047 otherwise). - Line type is the first filter: an SMS to a fixed-line or toll-free number usually fails and still costs the message fee. - Fallback works best as a rule in the sending platform: WhatsApp first where the customer chose it, SMS on a failed status or no WhatsApp consent. ## What does WhatsApp error 131026 mean? In Meta's Cloud API error reference, 131026 is "Unable to deliver message". Meta gives three possible reasons: "The recipient phone number is not a WhatsApp phone number", the recipient "has not accepted the new Terms of Service and Privacy Policy", or the recipient is "using an old WhatsApp version". Meta's suggested fix is to ask the person, "using a non-WhatsApp communication method", to confirm they can message your business number, accept the latest terms or update the app. In other words, 131026 is a routing signal, not a bug in your code. For a one-time passcode, a delivery notice or an appointment reminder, the non-WhatsApp method Meta refers to is usually SMS, and it should be sent automatically rather than after a support ticket. ## Why doesn't a message ID mean the message was delivered? Sending is asynchronous. The API accepts the request and returns a message ID; what happens next arrives on your webhook. Meta's message-status webhook reports these values: | Status | Meta's description | What to do | |---|---|---| | sent | The message was successfully sent from Meta's servers | Wait for delivered or failed | | delivered | The message was successfully delivered to the WhatsApp user's device | No fallback needed | | read | The message was displayed in an open chat thread on the user's device | No fallback needed | | failed | Failure to send or deliver the message to the user's device | Read errors[].code; fall back to SMS for time-sensitive messages | A failed status carries an errors array with a numeric code, a title, a details field and a link to the error reference. Log the code with the message: it tells you whether to retry, switch channel or fix a template. The same logic applies to SMS, where the delivery receipt (DLR) from the operator plays the role of the status webhook. ## Can you message someone on WhatsApp just because they have an account? No. The WhatsApp Business Messaging Policy says you "may only contact people on WhatsApp if: (a) they have given you their mobile phone number or username; and (b) you have received opt-in permission from the recipient confirming that they wish to receive subsequent messages or calls from you." You must also respect any request, on or off WhatsApp, to stop. So channel choice starts at opt-in, not at send time. Ask customers which channels they accept, store that choice with a timestamp, and send only on channels they agreed to. Local law adds its own rules on top: see our guide to [UAE PDPL for SMS and WhatsApp marketing](https://www.broadnet.me/blog/uae-pdpl-sms-whatsapp-marketing-2026) for one example. ## What about the 24-hour window and error 131047? A free-form WhatsApp message is only allowed within 24 hours of the customer's last message to you. Outside it, the Cloud API returns 131047, "More than 24 hours have passed since the recipient last replied to the sender number", and Meta's fix is to "send the recipient a template message instead". See [what the WhatsApp 24-hour window is](https://www.broadnet.me/answers/whatsapp-24-hour-window). For fallback design this means two different failures: 131047 is solved by switching to an approved template on WhatsApp, while 131026 is solved by switching channel. Treat them differently in your retry logic. ## Which channel should you use first? There is no single answer per market; it depends on the message and on what each customer agreed to. A per-recipient rule set covers most cases: | Situation | First channel | Fallback | |---|---|---| | Customer opted in to WhatsApp and has messaged you before | WhatsApp (template outside 24 hours) | SMS on failed status | | Customer opted in to WhatsApp, no history yet | WhatsApp template | SMS on failed status or no status in your time limit | | No WhatsApp consent recorded | SMS | Voice for OTP where supported | | Previous WhatsApp message failed with 131026 | SMS | Ask the customer to confirm their WhatsApp at the next contact | | Number is fixed-line or toll-free | Not SMS: it usually fails | Voice call, or ask for a mobile number | | Customer opted in to RCS, Telegram or Viber | That channel where you can send on it | SMS | For the per-market view (where WhatsApp, RCS or SMS lead), read our [SMS vs WhatsApp vs RCS channel guide](https://www.broadnet.me/blog/sms-vs-whatsapp-vs-rcs-channel-guide-2026). ## What can you check before you send? The first check is not about apps at all: it is the line type. An SMS to a landline or toll-free number usually fails and still costs the message fee. [MobileValidate](https://www.broadnet.me/products/mobilevalidate), a BroadNet brand in private preview, returns line type, current carrier and, for a ported number, the original carrier; BroadNet [HLR Lookup](https://www.broadnet.me/products/hlr-lookup) adds live network status, telling you whether the line is reachable now. For customers who opted in to other channels, MobileValidate can also check whether their number is registered on Telegram, Viber or Zalo in real time, and on Signal, iMessage, RCS, LINE or Botim in bulk jobs; the RCS check reports the handset platform when available. Its acceptable-use policy limits these checks to fraud prevention and to channel selection for contacts who opted in. The full list of checks is on [mobilevalidate.com](https://mobilevalidate.com/services). MobileValidate is an independent service, not affiliated with, endorsed or sponsored by the platforms it checks; their names are used only to describe what a check covers. For WhatsApp itself, the dependable signals are the ones Meta gives you: the customer's own opt-in, their replies, and the delivered or failed status of your last message. Store the last WhatsApp outcome per customer and let it steer the next send. ## How does BroadNet handle the fallback? BroadNet is an official Meta Business Solution Provider and runs [WhatsApp Business API](https://www.broadnet.me/products/whatsapp-business-api), SMS, RCS and voice on one platform. The [Omnichannel API](https://www.broadnet.me/products/omnichannel) takes one request with explicit fallback rules across SMS, WhatsApp, RCS and voice, and returns unified receipts, so a failed WhatsApp status becomes an SMS without extra code in your application. - For one-time passcodes, the [OTP API](https://www.broadnet.me/products/otp) sends with automatic fallback across SMS, WhatsApp, voice and Flash Call; [MyOTP.App](https://www.broadnet.me/products/myotp) covers SMS, WhatsApp and Telegram from one account. - Set a time limit for time-sensitive messages: if neither delivered nor failed arrives in time, send the fallback. - Keep templates approved for every message type you may need outside the 24-hour window. - Suppress a channel for a customer after a 131026 until they confirm it again, so you do not pay for repeated failures. For more patterns, read our [multi-channel failover strategy](https://www.broadnet.me/blog/multi-channel-failover-strategy). ## What does a per-recipient routing checklist look like? 1. At opt-in, record which channels the customer accepts, with the date and the wording they agreed to. 2. Check the line type of new numbers and ask for a mobile number when it is fixed-line or toll-free. 3. Pick the first channel from the customer's consent and history, not from a country default alone. 4. Outside the 24-hour window, send WhatsApp templates only. 5. Listen to status webhooks and delivery receipts; treat failed and time-outs as fallback triggers. 6. Fall back to SMS for time-sensitive messages and log the WhatsApp error code with the message. 7. Review failures weekly: a rise in 131026 in one segment usually means stale numbers or missing consent. ## Frequently asked questions ### What does WhatsApp error 131026 mean? "Unable to deliver message." Meta lists three possible reasons: the number is not a WhatsApp number, the recipient has not accepted the latest Terms of Service and Privacy Policy, or the recipient uses an old WhatsApp version. ### Should I retry a message that failed with 131026? Not on WhatsApp straight away. Send time-sensitive content by SMS instead, and ask the customer through another channel to confirm their WhatsApp number. ### Does a 200 response from the WhatsApp API mean the message was delivered? No. It means the request was accepted. Delivery is reported by the status webhook as sent, delivered, read or failed. ### Can I message a customer on WhatsApp if I know they have an account? No. Meta's policy requires that the person gave you their number and opted in to receive messages from your business on WhatsApp. ### What is error 131047? More than 24 hours have passed since the customer last replied. Send an approved template message instead of a free-form message. ### Which channel should be the fallback for WhatsApp? SMS in most cases, because it reaches any mobile number. For one-time passcodes, voice is a further fallback where the platform supports it. ### Can I check a number before sending? Yes, within your legal basis. Check the line type first; for customers who opted in, MobileValidate can check registration on apps such as Telegram, Viber and RCS, and BroadNet HLR Lookup gives live network status. ### How does BroadNet send the SMS fallback? The Omnichannel API applies your fallback rules in one request, and the OTP API falls back automatically between SMS, WhatsApp, voice and Flash Call. We read every source below on 27 September 2026. See our [editorial standards](https://www.broadnet.me/about/editorial-standards). ## Sources - Meta for Developers — WhatsApp Cloud API error codes (131026, 131047), accessed 27 September 2026: [developers.facebook.com](https://developers.facebook.com/docs/whatsapp/cloud-api/support/error-codes). - Meta for Developers — message status webhook reference, accessed 27 September 2026: [developers.facebook.com](https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/reference/messages/status). - WhatsApp Business Messaging Policy — opt-in and opt-out requirements, accessed 27 September 2026: [whatsappbusiness.com/policy](https://whatsappbusiness.com/policy/). - MobileValidate — services reference and carrier lookup, last updated 25 September 2026: [mobilevalidate.com/docs/services](https://mobilevalidate.com/docs/services), [mobilevalidate.com/services/carrier-lookup](https://mobilevalidate.com/services/carrier-lookup). - MobileValidate — acceptable-use policy, accessed 27 September 2026: [mobilevalidate.com/legal/acceptable-use](https://mobilevalidate.com/legal/acceptable-use).