How we run it / Trestle

How we use Trestle to verify mobile numbers before cold calling

One API call, one field. If line_type does not say Mobile, the row drops. Here is the call, the drop list, and why I stopped reading the score.

By Corey Leon · Sep 21, 2026 · about 4 min read

Every data vendor will sell you a verified mobile. About one in six of the first batch I checked was an office line. The vendor was not lying. Verified means their model predicts the number reaches that person. It does not mean the line is a cell phone.

Trestle tells you what the line is. That is the whole reason it is in my stack. It runs last, it costs per query, and the only field I read is line_type.

My exact words when I made it the rule: must be mobile, not a landline or fax. The score I care less about. Here is how it runs.

The gate, in six steps

  1. 01

    Keep one value and drop everything else

    The rule is one line. Keep the number if line_type equals Mobile. Drop it if it says Landline, FixedVOIP, NonFixedVOIP, TollFree, Voicemail or Unknown. Drop it if the number is invalid. That is it.

    The activity score gets recorded, and it only breaks a tie when two mobiles survive for the same person. It never cuts a row on its own.

  2. 02

    Run it last, after the reveal

    Trestle needs a real number to score, and it bills per lookup. So it runs after the search, after the still-in-role check, after the paid reveal. Cheap gates first, expensive reveals second, Trestle at the end on a list that has already earned it.

    Last week's whole build was 456 lookups. The old way was an hourly sweep over every lead in the CRM, about 2,900 calls a day. That sweep got a kill switch. The gate is small and it stays small.

  3. 03

    Make the call with curl, not a library

    GET phone_intel on the 3.0 API with the number and a country hint, and the key in an x-api-key header. Use curl. Trestle's edge returns 403 to Python's default user agent, the same way two other vendors in my stack do.

    The key lives in one env file that one script reads. That script runs inside the sourcing job, before import, so a non-mobile never becomes a lead in Close.

  4. 04

    Ignore the score, on purpose

    I ran the score three ways. For a month I kept 70 and above. Then I dropped anything under 30, the bar Trestle's own team suggested to me. Then a client with a small market got an override: cut nobody. In September I retired the score cut altogether.

    The score grades the line, not the person. A live line belonging to someone who left the company scores 100 and sails through. The still-in-role check catches that. Trestle cannot.

  5. 05

    Look at what it catches

    First run, 31 numbers a vendor had marked verified mobile. Trestle said 5 were not mobiles, two of them Bell and Distributel landlines, two fixed VOIP, plus one invalid. About 16 percent. Last week, 306 lookups: 287 mobile, 10 landline, 5 fixed VOIP, 4 non-fixed VOIP. About 6 percent dropped. A third batch: 150 in, 129 mobile.

    A vendor's verified mobile is a claim. line_type is the check.

  6. 06

    Know what it costs you not to

    In August I dialed one client's list with line type empty on 59 of 60 leads. Four weeks: 675 dials, 21 conversations, 3.1 percent. Across every client on the honest bar, the book connects at 7.4 percent.

    The mobile-only rebuild of that same list finished last week and gets measured this week. I will put the number here when I have it, not before.

Run this today

  1. Get a Trestle key. Put it in one env file that one script reads.
  2. Run the curl below on ten numbers your vendor called verified mobile. Count the non-mobiles.
  3. Write the drop list into your import script. Anything not Mobile never becomes a lead.
  4. Record activity_score. Use it only to pick between two surviving mobiles.
  5. Move the gate to the end of the pipeline, after the reveal.
  6. Write Line Type and Validator back to the CRM on every gated lead.
  7. If you have a sweep that runs on a clock, give it a kill switch today.

Free

The Trestle mobile gate checklist

The call, the keep rule, the drop list, and the two fields to write back.

curl -s "https://api.trestleiq.com/3.0/phone_intel?phone=%2B14165551234&phone.country_hint=CA" \
  -H "x-api-key: $TRESTLE_KEY"

KEEP   line_type == "Mobile"
DROP   Landline, FixedVOIP, NonFixedVOIP, TollFree, Voicemail, Unknown, invalid
SCORE  record activity_score; tiebreak only, never a cut
ORDER  search -> still-in-role (Apify) -> reveal -> Trestle -> CRM
WRITE  custom.Line Type = Mobile ; custom.Validator = Trestle
NOTE   curl, not python urllib: the edge 403s the default user agent
NOTE   never run it as a sweep over the whole CRM; gate the short list, once

Free

The 10 prompts that run this.

Text me the word prompts and I text you the pack. Then tell me what you sell and I'll say which one to run first.

Text me 'prompts'

or text prompts to +1 (617) 710-6179

Want to read them first? The 10 prompts are here.

FAQ

The questions I get on this.

Is line type Mobile enough on its own?

For the phone, yes. It tells you the line is a cell. It does not tell you the person still works there, which is why Apify runs first. And it does not tell you they will pick up, which is what dialing is for.

What about the activity score?

I record it and use it as a tiebreaker when two mobiles survive for one person. I stopped cutting on it. It grades the line, not the person, so a stale contact on a live line scores perfectly.

How much does Trestle cost?

It bills per lookup, and that is exactly why it runs last on a list that has already been qualified and revealed. My last full build was 456 lookups. The old hourly sweep was 2,900 a day, and it got switched off.

Do you ever dial a landline?

Not from a gated list. A row without a Mobile line type never becomes a lead in the dial queue. If the only number is the office line, that call is an attempt through a gatekeeper, and those never count as conversations anyway.