# Customer support channel routing

> Before a support reply or service notification goes out, check which channels the customer's number and e-mail can actually receive on, then route to one that arrives.

Canonical: https://mobilevalidate.com/use-cases/customer-support-channel-routing · Last updated: 2026-09-29

![A globe inside the MobileValidate shield over a glowing platform, circled by flag pins, with the words Global coverage, validate anywhere in the world.](https://mobilevalidate.com/media/library/global-coverage-platform-1600.webp)

*One API for numbers from every supported country.*


Customer support channel routing checks which channels a customer can actually receive on before a reply or notification is sent. One lookup tells you whether the number is registered on messaging apps such as WhatsApp, Telegram or Viber, whether the mobile line is reachable, and whether the e-mail mailbox exists. You then pick a consented channel that will arrive.

## Why do support messages go unanswered?

Support teams often send on whatever channel the ticket arrived on, or on a fixed default such as e-mail. That breaks in predictable ways:

- **The e-mail address was mistyped at sign-up.** Replies bounce or land nowhere, and the customer thinks you ignored them. The [e-mail mailbox check](/services/email-verification) tells you whether the mailbox exists at major webmail providers.
- **The customer changed phones or apps.** A number that had a messaging-app account a year ago may not have one now. A reply sent there waits unread.
- **The number is switched off or out of coverage.** For a time-critical message, such as a technician arriving within the hour, an SMS to an unreachable phone is too late. The [HLR lookup](/services/hlr-lookup) answers whether the mobile line is reachable at the moment you ask.
- **The channel doesn't suit the message.** A photo of a damaged part, a document to sign or a quick-reply button needs a channel that supports it. A fixed line can't receive SMS at all. The [carrier lookup](/services/carrier-lookup) reports the `line_type`.

A lookup doesn't choose the channel for you. It removes channels that can't work, so your routing rules choose among the ones that can.

## How does support channel routing work?

1. **Collect channel consent.** When a customer opens a ticket, signs up or updates their profile, record which channels they agreed to be contacted on for support.
2. **Check the consented channels.** Call `POST /v1/lookup` with the customer's number in `numbers`, their address in `emails`, and only the checks for channels you can send on, for example `["whatsapp", "telegram", "viber", "email"]`.
3. **Store the answer, not the raw response.** Save one row per channel with `registered` and `checked_at` in your help-desk or CRM.
4. **Route each message.** Pick the customer's preferred channel among those with `registered: true`. If none is `true`, use SMS for a mobile line, e-mail if the mailbox exists, or a voice call.
5. **Refresh on events.** Re-check when a message fails, when the customer changes their details, or when the stored answer is older than your refresh window, for example 30 days.
6. **Add bulk-only channels ahead of time.** iMessage and [RCS](/services/rcs-capability-check) checks run in bulk jobs only, so include them in a periodic job over active customers.

The same logic works for service notifications such as order updates, outage notices and account alerts, as long as the customer agreed to receive them on that channel.

## Which checks answer which question?

| Check | What it answers | When to run it | Link |
|---|---|---|---|
| `whatsapp`, `telegram`, `viber` | Is the number registered on this messaging app? | Ticket opened, profile updated, delivery failed | [WhatsApp](/services/whatsapp-number-check), [Telegram](/services/telegram-number-check), [Viber](/services/viber-number-check) |
| `email` | Does the mailbox exist at a major webmail provider? | Sign-up, e-mail change, bounce | [E-mail mailbox check](/services/email-verification) |
| `carrier` | Is the number mobile, fixed line or VoIP? | Once per number, before choosing SMS or voice | [Carrier lookup](/services/carrier-lookup) |
| `hlr` | Is the mobile line reachable right now? | Before a time-critical SMS | [HLR lookup](/services/hlr-lookup) |
| `imessage`, `rcs` (bulk only) | Can the number receive iMessage or RCS? | Periodic bulk job over active customers | [iMessage](/services/imessage-number-check), [RCS](/services/rcs-capability-check) |

Check only the channels you actually send on. Each channel is a separate check and a separate charge.

## What should you do with each result?

| Result | Suggested routing |
|---|---|
| Preferred app `registered: true` | Send the reply there |
| Preferred app `registered: false` | Skip that app; try the next consented channel |
| Any check `registered: null` (unknown) | Keep the customer's last working channel; check again later |
| Mailbox `registered: false` | Don't rely on e-mail; ask the customer to confirm their address on the next contact |
| Mailbox `unknown` with `UNSUPPORTED_PROVIDER` | Normal for company domains; send e-mail as usual and watch for bounces |
| `line_type: fixed_line` | No SMS; use voice, e-mail or an app if one is registered |
| HLR `status: unreachable` | Hold the SMS or send on an app or e-mail; retry later |

## What does a request look like?

This test-mode request checks one number on two messaging apps and one e-mail address. `+447700900001` answers `registered: true` for every yes/no service, and `not-registered@test.mobilevalidate.com` answers `registered: false`.

```bash
curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer $MOBILEVALIDATE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"numbers": ["+447700900001"], "emails": ["not-registered@test.mobilevalidate.com"], "checks": ["whatsapp", "viber", "email"], "wait": 5}'
```

Response (excerpt, test mode: the `checks` of the phone row, then of the e-mail row):

```json
[
  {
    "whatsapp.registered": {
      "service": "whatsapp.registered", "status": "completed", "registered": true, "attributes": null,
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-29T09:14:02.118Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    },
    "viber.registered": {
      "service": "viber.registered", "status": "completed", "registered": true, "attributes": null,
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-29T09:14:02.118Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  },
  {
    "email.valid": {
      "service": "email.valid", "status": "completed", "registered": false, "attributes": null,
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-09-29T09:14:02.118Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  }
]
```

Both apps are reachable and the mailbox doesn't exist, so this reply should go on the customer's preferred app, and the next agent contact should confirm the e-mail address. Rows come numbers first, then e-mails. For a ready-made version of this logic, see the [choose-channel recipe](/docs/recipes/choose-channel).

## How much does it cost?

You pay per check, and only for conclusive answers. Unknown answers are free, and so are invalid, duplicate and unsupported-country results. The request above runs three checks and can bill up to three. Company e-mail domains the mailbox check doesn't cover return `unknown` and cost nothing.

Support routing is cheap to run because channel data is stable: check once, store the answer, and re-check only on events. Repeat checks of the same number inside the freshness window come free from your account's cache. For a whole customer base, a bulk job costs less per check than real-time lookups, and `POST /v1/jobs/estimate` shows the maximum cost for free before you start. If you add the HLR lookup for urgent messages, it costs $0.005 per number. See [pricing](/pricing) for every current rate.

## What about consent and compliance?

Channel checks tell you what is technically possible, not what the customer wants or what you're allowed to do.

- **Consent comes first.** Check only channels the customer agreed to for support or service messages. Messaging platforms have their own business rules. For example, [WhatsApp's Business Messaging Policy](https://business.whatsapp.com/policy) requires opt-in before a business messages someone there.
- **Service is not marketing.** A support opt-in doesn't cover promotions. Keep the two consents separate in your records.
- **Minimize what you store.** Keep `registered` and `checked_at` per channel, not full responses. Say in your privacy notice that you check contact channels to deliver service messages.
- **Existing customers only.** Don't run channel checks on people who haven't contacted you or given you their details. Our [acceptable use policy](/legal/acceptable-use) forbids using checks to find people to message, and requests that look like number-range scans are rejected.

Platform names are used descriptively. MobileValidate isn't affiliated with or endorsed by any messaging platform.

## What are the common mistakes?

- **Treating `unknown` as "not registered".** Unknown means no conclusive answer. Switching channel because of a timeout sends customers to a worse channel for no reason.
- **Checking every channel on every message.** It multiplies cost and adds latency to replies. Check on events and store the result.
- **Ignoring the customer's stated preference.** A customer who asked for e-mail should get e-mail, even if a messaging app is registered.
- **Never refreshing.** Numbers change hands and people drop apps. Use `checked_at` to find stale answers.
- **Sending urgent SMS blind.** For time-critical notices, an HLR check first tells you whether the phone is reachable, so you can switch to another channel straight away.

For background on how messaging habits differ by market, read [choosing a messaging channel by country](/blog/choosing-a-messaging-channel-by-country). For the marketing side of the same question, see [channel selection for consented messaging](/use-cases/channel-selection).

## Frequently asked questions

### What is support channel routing?

It means sending each support reply or service notification on a channel the customer can actually receive, chosen from the channels they agreed to. A lookup tells you which messaging apps the number is registered on, whether the mobile line is reachable and whether the e-mail mailbox exists.

### Does an app account mean I can message the customer there?

No. A registered account shows the channel can reach the number. Whether you may use it depends on the customer's consent and the platform's business messaging rules, which usually require opt-in for business messages.

### Should I check before every support message?

No. Channel data changes slowly. Check when a ticket is opened or a customer updates their details, store the result with checked_at, and re-check when a delivery fails or the stored result is older than your refresh window.

### What happens when a check returns unknown?

Unknown means no conclusive answer, for example a timeout. It is not charged and it is not a no. Keep the customer's usual channel, or fall back to e-mail or SMS, and check again later.

### Can I check iMessage and RCS in real time?

No. iMessage and RCS checks are available in bulk jobs only. Run them over your active customer base ahead of time and store the result in your help-desk or CRM.

### Do you return the customer's name or profile from the messaging app?

No. Channel checks answer registered, not registered or unknown, with the time we checked. Names, photos, status texts and profile details are never returned.

### Is the HLR check needed for support routing?

Only when reachability matters, for example before a time-critical SMS such as a delivery window or an outage notice. For most replies the messaging-app and e-mail checks are enough.