Skip to main content
Human guide: work with your agent → Find one contact’s phone number, then check whether it meets your line-type requirement. Your first goal is a reviewed lookup, not an uploaded call list.

​
Before you start

Use an authorized workspace and a known person’s identity. The maintained Play requires first_name and last_name. A domain, email, or LinkedIn URL provides additional context. country helps normalize national-format numbers. It is not a promise of automatic geographic provider selection.

​
1. Inspect the maintained contract

These commands inspect access and validate the Play. They do not start a phone lookup. Read the required inputs, supported billing mode, and result fields.

​
2. Decide whether landlines are acceptable

The default accepts a valid line. Set require_mobile: true when your task requires mobile numbers. The Play rejects a validated non-mobile candidate and continues its configured route. Do not infer a mobile-only guarantee from the Play’s display name.

​
3. Run one representative lookup

Replace the illustrative identity with a person you are authorized to query. This command starts provider-backed work and can incur usage:
Save the returned run ID. Read its result before requesting another lookup:

​
4. Check the returned evidence

Inspect phone, phone_validated, phone_line_type, phone_source, and any phone_reject_reason. Retain unresolved outcomes and attempt evidence. A completed run need not contain an accepted number.
Continue only when the returned number meets the requested rule and matches the intended person. Review the recorded Deepline usage separately.
For a file, inspect prebuilt/person-to-phone-batch before using its CSV contract. Follow Batch CSV enrichment for row identity and export.

​
Continue

Use the phone workflow guide to define an acceptance policy. Ask your agent to explain a rejected candidate before changing require_mobile or repeating the lookup.