WhatsApp Number Validator — Live Bulk Check

Validate consented phone lists against an authorized WhatsApp provider through an Apify Actor usable via Apify MCP. It accepts E.164 phone numbers, treats each normalized number as one record, and returns the input number, normalized number, live registration result, provider status, checked time, and any non-fatal warnings. The outcome is a stable dataset row per processed number, plus compact execution diagnostics for downstream automation.

Best fit and connected workflows

This Actor fits workflows where the source list already exists and the goal is to confirm WhatsApp registration status for each consented number.

Common routing patterns include:

• CRM hygiene for consented contact lists.
• Pre-support validation for numbers your organization is authorized to process.
• Agent workflows that need a compact, machine-readable live registration result.
• Data pipelines that want normalized E.164 numbers and provider status fields for downstream decision-making.

focused workflow

WhatsApp Number Validator — Live Bulk Check is designed as a focused workflow.

Practical scenario

Maya manages support operations and has a consented list of customer numbers exported from her CRM. She submits the E.164 numbers, then reads back normalizedNumber, isRegisteredOnWhatsApp, providerStatus, checkedAt, and warnings. Based on isRegisteredOnWhatsApp, she decides whether a contact should move into a WhatsApp follow-up queue or another contact path. Her next action is to sync the returned fields back into the CRM record set.

Input

Provide one or more consented phone numbers in E.164 format. Local-format numbers are treated as invalid rather than guessed from a country setting.

Field	Type	Required	Default	Description
phoneNumbers	array of string	Yes	["+12025550123"]	One E.164 phone number per item. Maximum 10,000 unique numbers per run.
maxConcurrency	integer	No	2	Parallel provider requests. Range: 1 to 10.
batchSize	integer	No	25	Numbers grouped per provider request. Range: 1 to 100.
consentConfirmed	boolean	No	false	Confirms you are authorized to validate the submitted numbers.

Focused JSON example

{
  "phoneNumbers": [
    "+14155550123",
    "+442071838750"
  ],
  "maxConcurrency": 2,
  "batchSize": 25,
  "consentConfirmed": true
}

Output

Each dataset record represents one provider-backed validation result for one processed, normalized number.

Field	Type	Description
inputNumber	string	The number exactly as supplied by the caller.
normalizedNumber	string	The E.164 number sent to the provider.
isRegisteredOnWhatsApp	boolean	Live registration result returned by the configured provider.
providerStatus	string	Provider status normalized for safe diagnostics.
checkedAt	string	ISO 8601 timestamp when the provider-backed result was received.
warnings	array of string	Non-fatal warnings relevant to the record.

Illustrative output record

{
  "inputNumber": "+14155550123",
  "normalizedNumber": "+14155550123",
  "isRegisteredOnWhatsApp": true,
  "providerStatus": "valid",
  "checkedAt": "2026-07-21T12:00:00.000Z",
  "warnings": []
}

The Actor also writes compact run data to OUTPUT and detailed safe diagnostics to RUN_SUMMARY.

How it works

The Actor validates consented numbers, normalizes them into E.164 format, groups them into provider requests according to batchSize, and controls parallel execution with maxConcurrency. It uses the configured authorized WhatsApp provider through the WHAPI_API_KEY secret. Each completed result is stored in the dataset with the fields above.

Required owner secret (WHAPI_API_KEY)

Live checks require a Whapi.Cloud Bearer token stored as an Apify account secret named WHAPI_API_KEY and referenced on this Actor version as @WHAPI_API_KEY (see .actor/actor.json environmentVariables).

If that secret is missing, the run ends as CONFIG_ERROR / FAILED with no dataset rows. The Actor never invents successful validation results.

Alternate providers were checked and are not wired:

• TikHub (TIKHUB_API_KEY) — local value is a placeholder; OpenAPI has no WhatsApp number-check route.
• ScrapeCreators / SociaVault — no usable WhatsApp registration-check endpoint for this contract.

After you add the Whapi secret in Apify Console, push/redeploy is not required if the @WHAPI_API_KEY env reference is already on the version; just re-run with consentConfirmed: true.

Pricing

This Actor uses Pay per Event plus Apify platform usage pass-through.

Charging is based on two events:

• Actor start
• Live WhatsApp number validation

The primary event is charged only when a provider-backed registration result is persisted for one normalized number. For example, if you process three persisted validation records in one run, the execution includes one actor-start event and three live-validation events. Invalid inputs and provider requests that are not persisted are not charged. Open the live Pricing tab on the Apify Actor page for current pricing details.

Use with AI agents (MCP)

This Actor is usable through Apify MCP as a tool that validates consented phone numbers and returns per-number live registration records from the dataset.

Exact Actor identity: khadinakbar/whatsapp-number-validator

Tool description: a provider-backed WhatsApp number validation tool for consented E.164 phone lists. It returns one dataset row per processed number, plus execution diagnostics in key-value storage.

Validate this consented list of E.164 phone numbers with khadinakbar/whatsapp-number-validator, then return the dataset rows with inputNumber, normalizedNumber, isRegisteredOnWhatsApp, providerStatus, checkedAt, and warnings. Summarize any non-fatal warnings and keep the result scoped to one record per input number.

Output interpretation:

• isRegisteredOnWhatsApp reflects a live provider registration result.
• providerStatus is normalized for safe diagnostics.
• checkedAt shows when the provider-backed result was received.
• warnings can add record-level context without changing the registration result.

Provenance and scope:

• Results come from the configured authorized provider.
• The Actor processes only the submitted numbers.
• It returns dataset items one row per processed number.

Pagination and cost guidance:

• Dataset records are returned one row per processed number.
• Cost scales with persisted validation events plus platform usage.
• batchSize and maxConcurrency shape request grouping and parallelism, while billing remains event-based.

Apify API example

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({
    token: process.env.APIFY_TOKEN,
});

const input = {
    phoneNumbers: ['+14155550123', '+442071838750'],
    maxConcurrency: 2,
    batchSize: 25,
    consentConfirmed: true,
};

const run = await client.actor('khadinakbar/whatsapp-number-validator').call(input);

console.log('Run finished:', run.id);

const datasetItems = await client.dataset(run.defaultDatasetId).listItems();
console.log('Dataset items:', datasetItems.items);

Best results and outcome guidance

Provide E.164 numbers exactly as received from a consented source. Set consentConfirmed to true when your workflow has a lawful basis to validate the list. Keep batchSize aligned with your provider-session workflow, and use maxConcurrency to shape parallel requests within the supported range. For downstream automation, read the dataset first and then map isRegisteredOnWhatsApp and providerStatus into your CRM or agent logic.

Continue the workflow

• Then use Yandex Maps Scraper to extend WhatsApp Number Validator — Live Bulk Check with a neighboring local-business research source when the brief calls for Yandex data.
• Then use Universal B2B Lead Finder — Extract Emails, Phones & Business Contacts to extend WhatsApp Number Validator — Live Bulk Check with a neighboring local-business research source when the brief calls for Universal data.

Design note

I found that the dataset contract requires a complete record for every processed number, including inputNumber, normalizedNumber, isRegisteredOnWhatsApp, providerStatus, checkedAt, and warnings, which makes the output suitable for row-level automation.

FAQ

When should I use this Actor instead of a general phone lookup workflow?

Use this Actor when the goal is a live WhatsApp registration check for consented numbers. If you need other signals such as format, carrier, or fraud-related fields, use a phone lookup workflow that is designed for those outputs.

Can I use this Actor for a list I already own in CRM?

Yes. It is designed for consented phone lists and returns normalized per-number results that are easy to sync back into CRM records.

What does one output record represent?

One output record represents one processed, normalized phone number and its provider-backed registration result.

How should an AI agent consume the result?

Have the agent read the dataset rows, then route based on isRegisteredOnWhatsApp, inspect providerStatus for diagnostics, and use warnings only as supplementary context.

What should I do if I need to process a larger list?

Send the list in E.164 format, keep phoneNumbers within the schema bounds, and let the Actor process one record per unique normalized number.

Responsible use

Use this Actor only for phone numbers you are authorized to validate. Keep the workflow aligned with consent, lawful basis, and the provider account terms that back the registration check. It is intended for validation and routing workflows, and it returns provider-backed registration results and dataset diagnostics.