WA Lookup
An abstract phone-number verification workflow ending in a confirmed result
A synchronous request gives a workflow a current signal before its next decision.

Use a current signal where the decision happens

Lead qualification is often treated as a later cleanup step. That is useful for some workflows, but it is not the only moment when a registration signal matters. A form submission, a support request, or a CRM update may need an answer before the next rule runs.

WA Lookup provides that answer through a synchronous API. The caller can submit one phone number or a small batch of up to 100 numbers and receives the selected WhatsApp results in the same HTTP response. That makes the response suitable for a workflow that needs to decide whether to enrich records, select a queue, or request more information now.

The result is deliberately narrow. It reports the fields documented for the selected product at the time of the check. It does not identify the person behind a number, prove consent, reveal online status or message history, or guarantee future reachability.

Choose the smallest signal that answers the workflow question

All WA Lookup checks use the same request shape; service_type defines the response fields.

Service type Result to use Example workflow decision
ws registered Continue a lead-routing rule only after recording the current registration signal.
ws_avatar registered, avatar, avatar_url Add the documented profile-availability fields to a CRM review flow.
ws_business registered, business Route a record to a B2B review path when that distinction is useful.

Use the least expensive product that answers the immediate question. An avatar or Business field adds context; it does not make the registration result more authoritative.

Send one clear request and use the response contract

Normalize the identifier before calling the API. E.164 gives an international number a clear country-code form and avoids treating an ambiguous local number as if it were globally complete.

curl -X POST "https://walookup.com/api/v1/check" \
  -H "X-API-Key: sk_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"service_type":"ws","identifier":"+14155552671"}'

A completed registration result is returned in the public response envelope:

{
  "code": 0,
  "msg": "ok",
  "data": {
    "service_type": "ws",
    "identifier": "+14155552671",
    "registered": true
  }
}

Only use data.registered after a completed result. An invalid request, an insufficient balance response, a concurrency rejection, a timeout, or an undetermined check is not evidence that the number is unregistered. Keep that operational outcome separate from the registration observation and follow the documented retry or correction path.

Store an observation, not an identity claim

A useful CRM record preserves what was submitted, what was checked, and when the result was observed. This makes later refreshes explainable instead of silently replacing an older value.

  • Store the source value and the normalized E.164 identifier separately.
  • Store the selected service_type with the returned fields.
  • Record the check time with the completed result.
  • Keep request errors and undetermined outcomes distinct from registered=false.
  • Recheck when a later workflow needs a newer observation.

Account balance can be used on the dashboard or API; refer to the current pricing and API documentation for operational details.

A simple routing rule

The safe rule is straightforward: branch only on a completed response, then treat the fields as current workflow inputs rather than permanent truth. For example, a CRM can save registered=true with its timestamp and service type, while a temporary failure remains retryable and does not overwrite a previous completed observation.

That is where synchronous verification is most useful: it gives the workflow a structured answer at the point where a decision is actually being made.

Sources