Troubleshoot phone-number lookup results

Start by separating a failed request from a successful lookup that could not answer every requested property.

Confirm the international phone-number format, supported property names and API key scope. Compare your request with the API reference. Capture the error code and request time before changing the input.

Run the TypeScript or Python example with a number you control to isolate application parsing from the SDK call.

Read that property's status before accessing its value. A status other than ok means the requested answer is not available; it does not mean the value is false or zero. Keep this distinction in your database and customer-facing decisions.

Use phone-number lookup for the property meanings and pricing for base and optional-property billing.

Check whether you are comparing equivalent fields and observation times. Porting can change the serving network. Do not substitute a historical carrier field for a current-network result without understanding the source's meaning.

The migration guides explain why provider-specific fields should be mapped individually.

Inspect the rule applied to unanswered signals, number types and errors. A timeout or unsupported property should follow the explicit fallback path you designed, rather than being coerced into a definitive verdict.

Review the signup example for separating lookup from possession verification. Validate rules with representative, permitted test inputs before expanding enforcement.

Provide the timestamp, request/error identifier when available, requested properties and the unexpected field or status. Mask personal numbers where the full value is not necessary.

Return to Lookup resources.