Candidate contact verification for recruitment

Recruiters and staffing firms check a candidate's phone number and e-mail address when the application arrives, so interview invitations, reminders and offers reach the person. An HLR lookup says whether the number is live, and the mailbox check says whether the address exists at a major webmail provider. The results are contact-data signals only: they must never be used to decide whether to interview or hire someone.

Why check candidate contact details?

Hiring runs on messages: "thanks for applying", "can we talk tomorrow?", "your interview is at 10:00", "here is your offer". When the contact details are wrong, a good candidate simply disappears from the process, and the recruiter often can't tell why.

Three problems come up again and again:

• Typos at application. Candidates apply on a phone, often to many roles in one sitting. A digit goes missing, a country code is wrong, or the e-mail domain is misspelled. The confirmation bounces and nobody notices.
• Stale numbers in the talent pool. CVs from two or three years ago carry numbers people have since given up. Networks reassign numbers, so an old number may now reach someone else.
• Missed interviews. Reminders sent to a dead number or a mailbox that doesn't exist never arrive, which shows up as a no-show.

The HLR lookup asks the home network whether a mobile number is reachable, unreachable or invalid (not assigned). The e-mail mailbox check says whether the mailbox exists at a major webmail provider. The carrier lookup tells you whether the number is a mobile line that can receive texts.

How does the workflow look?

At application (real time):

1. Validate the format on the form and normalize the number to E.164 using the candidate's country. Unparseable entries come back as invalid_number, free.
2. Call POST /v1/lookup with the number, the address and checks: ["hlr", "email"], plus the application reference in metadata.
3. If the number is invalid or the mailbox doesn't exist, show an inline message: "Please check your phone number" or "Please check your e-mail address". Let the candidate continue either way.
4. Store the outcome and checked_at with the application, not the full response.

Before re-engaging the talent pool (bulk):

1. Select candidates who agreed to be kept on file for future roles, within your retention period.
2. Run the free POST /v1/jobs/estimate, then POST /v1/jobs with checks: ["hlr"] and the estimate as max_cost.
3. Download the results. Each line keeps its row_no, so you join results back to your export by row number.
4. Mark invalid numbers as out of date and ask the candidate for a new one by e-mail. Keep unreachable numbers and retry later.

Before interviews:

1. Send the invitation by e-mail if the mailbox exists, and by SMS to a reachable mobile.
2. If the candidate chose WhatsApp for updates, a WhatsApp check confirms the number has an account before you send reminders there.
3. If a reminder fails, run hlr again with max_age: 0 and use another agreed channel.

Which checks answer which question?

Free tools help before any paid check: the phone number validator parses and formats numbers, the e-mail checker checks the format and the domain's mail servers, and the e-mail list cleaner removes duplicates and finds typos in an export.

What should you do with each result?

Every action is about reaching the candidate. None of them is a reason to reject an application.

What does a request look like?

This request uses the public sandbox key from the test values page, so you can run it as is. +447700900002 is a phone that is switched off, and not-registered@test.mobilevalidate.com has no mailbox.

curl https://api.mobilevalidate.com/v1/lookup \
  -H "Authorization: Bearer mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym" \
  -H "Content-Type: application/json" \
  -d '{"numbers":["+447700900002"],"emails":["not-registered@test.mobilevalidate.com"],"checks":["hlr","email"],"metadata":{"application_id":"APP-2207"}}'

// 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: ["+447700900002"],
  emails: ["not-registered@test.mobilevalidate.com"],
  checks: ["hlr", "email"],
  metadata: { application_id: "APP-2207" },
});
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: ["+447700900002"],
    emails: ["not-registered@test.mobilevalidate.com"],
    checks: ["hlr", "email"],
    metadata: { application_id: "APP-2207" },
  }),
});
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=["+447700900002"],
    emails=["not-registered@test.mobilevalidate.com"],
    checks=["hlr", "email"],
    metadata={ "application_id": "APP-2207" },
)
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' => ['+447700900002'],
        'emails' => ['not-registered@test.mobilevalidate.com'],
        'checks' => ['hlr', 'email'],
        'metadata' => [ 'application_id' => 'APP-2207' ],
    ]),
]);
$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":["+447700900002"],"emails":["not-registered@test.mobilevalidate.com"],"checks":["hlr","email"],"metadata":{"application_id":"APP-2207"}}`)
	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" => ["+447700900002"],
  "emails" => ["not-registered@test.mobilevalidate.com"],
  "checks" => ["hlr", "email"],
  "metadata" => { "application_id" => "APP-2207" }
})

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):

[
  {
    "number.hlr": {
      "service": "number.hlr", "status": "completed", "registered": true,
      "attributes": {"status": "unreachable", "ported": false, "roaming": false, "network": "Test Mobile", "mcc_mnc": "23415", "country": "GB"},
      "confidence": "high", "confidence_score": 0.99, "checked_at": "2026-11-08T02:49:49.996Z",
      "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-11-08T02:49:49.996Z",
      "cached": false, "age_seconds": 0, "billed": false, "reason": null, "poll_after_ms": null
    }
  }
]

The number exists but the phone is off right now, so it stays on file. The mailbox doesn't exist, so the confirmation e-mail would bounce: ask the candidate to check the address on the confirmation page. The response echoes metadata ("application_id": "APP-2207"), so you can match it to the application.

How much does it cost?

As of 8 November 2026, the live catalog lists these prices per conclusive answer:

A phone and e-mail check at application costs $0.012 per candidate in real time. Refreshing 20,000 talent-pool numbers with the HLR lookup in bulk costs at most $100. Unknown, unsupported-country, timeout, invalid-format and duplicate results are free, and a candidate who applies for a second role inside the freshness window is answered from your account's cache for free. Current prices are on the pricing page.

To try it with real details first, every account can run 20 phone numbers and 10 e-mail addresses through the real-time checks for free on the dashboard's Try it page. Request access; approval is automatic, usually within 10–15 minutes.

What about consent and employment law?

• Contact data only, never eligibility. Results are signals about a phone number or an e-mail address, not proof of who someone is. They are not consumer reports under the US Fair Credit Reporting Act or similar laws, and must not be used as KYC or for credit, employment, housing or insurance decisions. Don't use them to screen, rank, shortlist or reject candidates. Our acceptable use policy forbids eligibility decisions.
• Tell candidates. Say in your candidate privacy notice that you check phone numbers and e-mail addresses so that messages about their application reach them.
• Talent pools need a basis. Check only candidates who applied or agreed to be kept on file, and only within your retention period.
• Channel choice. Messaging candidates on WhatsApp or another app needs their agreement to that channel. Having an account is not consent.
• No profiling. The checks never return names, photos, employers or social profiles, and you must not try to obtain them through the service.
• Minimize. Store the outcome and checked_at, not the full response. People can object through the opt-out form.

What are the common mistakes?

• Blocking the application form on a failed check. Ask for a correction and let the candidate continue.
• Using a check in a hiring decision. It describes contact details, not the person. Keep it out of scoring and shortlisting.
• Deleting unreachable numbers. The phone is off or out of coverage; the number still exists.
• Texting a fixed line. Check line type before SMS reminders, or call instead.
• Re-engaging old CVs without a basis. Refresh numbers only for candidates who agreed to stay on file.
• Expecting answers for company e-mail domains. The mailbox check covers major webmail providers; other domains answer unknown, free.