Customer support channel routing

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 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 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 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 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 only the channels you actually send on. Each channel is a separate check and a separate charge.

#What should you do with each result?

#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 [email protected] answers registered: false.

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" \
  -H "Content-Type: application/json" \
  -d '{"numbers":["+447700900001"],"emails":["[email protected]"],"checks":["whatsapp","viber","email"],"wait":5}'

// npm install mobilevalidate · Node.js 20+ · save as check.mjs and run: node check.mjs
import { MobileValidate } from "mobilevalidate";

// Omit apiKey to read MOBILEVALIDATE_API_KEY from the environment.
const mv = new MobileValidate({ apiKey: "mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" });
const { data, error } = await mv.lookup({
  numbers: ["+447700900001"],
  emails: ["[email protected]"],
  checks: ["whatsapp", "viber", "email"],
  wait: 5,
});
if (error) console.error(error.code, error.message);
else console.dir(data.results, { depth: null });

// Node.js 18+, Deno, Bun or the browser console (ES module: save as .mjs or use "type": "module").
const res = await fetch("https://api.mobilevalidate.com/v1/lookup", {
  method: "POST",
  headers: {
    Authorization: "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    numbers: ["+447700900001"],
    emails: ["[email protected]"],
    checks: ["whatsapp", "viber", "email"],
    wait: 5,
  }),
});
console.log(res.status, res.headers.get("x-request-id"));
console.dir(await res.json(), { depth: null });

# pip install mobilevalidate-sdk
from mobilevalidate import MobileValidate

# Omit api_key to read MOBILEVALIDATE_API_KEY from the environment.
mv = MobileValidate(api_key="mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym")
result = mv.lookup(
    numbers=["+447700900001"],
    emails=["[email protected]"],
    checks=["whatsapp", "viber", "email"],
    wait=5,
)
print(result)

<?php
$ch = curl_init('https://api.mobilevalidate.com/v1/lookup');
curl_setopt_array($ch, [
    CURLOPT_POST => true,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_HTTPHEADER => [
        'Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym',
        'Content-Type: application/json',
    ],
    CURLOPT_POSTFIELDS => json_encode([
        'numbers' => ['+447700900001'],
        'emails' => ['[email protected]'],
        'checks' => ['whatsapp', 'viber', 'email'],
        'wait' => 5,
    ]),
]);
$response = curl_exec($ch);
echo curl_getinfo($ch, CURLINFO_RESPONSE_CODE), PHP_EOL, $response, PHP_EOL;

package main

import (
	"fmt"
	"io"
	"net/http"
	"strings"
)

func main() {
	body := strings.NewReader(`{"numbers":["+447700900001"],"emails":["[email protected]"],"checks":["whatsapp","viber","email"],"wait":5}`)
	req, err := http.NewRequest("POST", "https://api.mobilevalidate.com/v1/lookup", body)
	if err != nil {
		panic(err)
	}
	req.Header.Set("Authorization", "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym")
	req.Header.Set("Content-Type", "application/json")
	res, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	defer res.Body.Close()
	out, _ := io.ReadAll(res.Body)
	fmt.Println(res.Status, string(out))
}

require "net/http"
require "json"

uri = URI("https://api.mobilevalidate.com/v1/lookup")
req = Net::HTTP::Post.new(uri)
req["Authorization"] = "Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym"
req["Content-Type"] = "application/json"
req.body = JSON.generate({
  "numbers" => ["+447700900001"],
  "emails" => ["[email protected]"],
  "checks" => ["whatsapp", "viber", "email"],
  "wait" => 5
})

res = Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| http.request(req) }
puts res.code, res.body

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

[
  {
    "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.

#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 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 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 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. For the marketing side of the same question, see channel selection for consented messaging.