Real Contact API 2.0 adds two IP-based signals, IP Trust Score and IP Distance-to-Address that help you judge whether a lead, signup, or contact looks legitimate. They return inside the ip_address object whenever you pass an IP address captured at the point of interaction, and they’re available in Real Contact API 2.0.
Contact data can check out completely and still come from a submission you’d never want in your pipeline. A bot cycling through stolen identities can hand you a valid phone, a deliverable email, and a name that aligns with both, and the person on the other end will still tell you they never inquired themselves. Phone, email, and address verification confirm that an identity is real and reachable. IP intelligence checks help answer a different question: Does this specific interaction look like it actually came from that real person?
To use these signals well, it helps to understand the data underneath them.
What is an IP address? #
An IP (Internet Protocol) address is essentially the street address of the internet. It’s a unique identifier assigned to a device on a network so it can send and receive data. When someone fills out your web form, the public IP address tied to that session is the closest thing you have to where the interaction came from.
There are two formats in use today, both governed by the Internet Assigned Numbers Authority (IANA):
- IPv4: The legacy format, a 32-bit number that allows roughly 4.3 billion unique addresses. It’s still the primary format, but because supply is limited, IPv4 addresses are heavily shared (more on that below).
- IPv6: The newer 128-bit format, which expands the pool to roughly 340 undecillion addresses. It’s effectively an unlimited supply of potential IP addresses.
Addresses are handed down through a hierarchy: IANA allocates blocks to the five Regional Internet Registries (RIRs), which allocate to Internet Service Providers (ISPs), which assign them to end users and devices. That chain is what later lets a provider tie an IP back to an owning organization, a registered region, and a network type.
What Makes IP Intelligence Different Than Other Identity Signals #
The key thing to understand before reading any IP signal is that an IP-to-person connection is not durable the way a phone, email, or address is. A person tends to keep the same mobile number or home address for years. IP addresses don’t work that way.
Most consumer connections use dynamic IP addresses. Your ISP leases you an address that can change between sessions, rather than static addresses which stay consistent and are mostly used by businesses. Additionally, a single public IP is often shared by many people at once. So, unlike your other contact attributes, an IP is better understood as a signal about this interaction, in this specific moment, than as a permanent identifier of a person.
That’s why IP intelligence complements contact verification instead of replacing it. Contact data answers, “Is this a real, reachable identity?” The IP answers, “Does the connection behind this submission look trustworthy?”
One IP for Multiple Identities #
Because IPv4 addresses are a limited resource, sharing and anonymization are normal, not inherently suspicious. Understanding the common types helps explain why a single signal is never the whole story.
Network Address Translation (NAT) and Carrier-Grade NAT (CGNAT) #
This type of IP lets many devices share one public IP. CGNAT is especially common on mobile networks, where everyone connecting in an area (sometimes up to a whole city) can appear under the same public IP. High traffic volume from one IP is not automatically bad, and the link between a mobile IP and any one individual is weak.
VPNs and Proxies #
Both let a user route traffic through another server, masking their true IP. They overlap heavily. The main technical difference is that VPN traffic is encrypted while proxy traffic typically isn’t. Plenty of legitimate people use a VPN for work, travel, or privacy, so a VPN connection alone isn’t a red flag. But commercial, consumer-oriented anonymization services carry more risk than, say, a corporate or government VPN.
Privacy Relays #
A growing category built into modern devices (such as iCloud Private Relay and Google One’s VPN). These use a two-hop design where no single server sees both your identity and your destination. The result is a highly shared, location-approximate IP. But importantly, a low-risk one.
The Tor Network #
Free, open-source software that routes encrypted traffic through thousands of volunteer-run relays, concealing the user’s identity and location. The address you ultimately see is a Tor “exit node.” Because Tor is slow and built for strong anonymity, it tends to be used either by very privacy-conscious people or by bad actors, making it a high-risk connection type.
Residential Proxies #
The hardest category to detect. Instead of routing through a data center, they route through real consumer internet connections. This is often a home IP whose owner installed a free app that authorized proxy use in its terms (and sometimes via malware). There’s no telltale protocol to flag because the traffic looks like normal residential activity. Because the whole point is to borrow a real person’s IP, not all of that traffic is malicious, which is why a simple “is this a proxy?” flag isn’t enough.
This is why blanket-blocking every VPN or proxy creates false positives and misses the traffic that matters. For a deeper look at how this detection plays out and where IP signals add the most value across lead, signup, and prioritization workflows, see Announcing Real Contact API 2.0.
How IP Geolocation Works #
Geolocation is how an IP gets mapped to a physical location, and it’s the foundation of the ip_distance_to_address signal. It’s built up in layers: registry records from IANA and the RIRs (which often reflect a corporate headquarters rather than the actual user region), ISP and network-infrastructure mapping, and active network measurements like latency and traceroute that triangulate a location from multiple vantage points.
Two realities follow from how this works:
- Accuracy depends on connection type. Geolocation is highly accurate for fixed-line connections, but typically only city-level for mobile because of the way mobile networks share addresses.
- Anonymization breaks the link to the real user. For a VPN, proxy, or similar connection, the geolocation reflects the server’s location, not the person’s even when those coordinates are very precise. A precise location isn’t the same as a true one.
Both points explain why an IP-to-address distance can legitimately be large, and why Trestle returns a NULL distance when confidence in the IP’s location is too low to be reliable.
What IP Metadata Reveals #
Beyond location, an IP carries metadata that helps characterize the connection:
- Connection Type: Residential, mobile, privacy relay, hosting/data center, VPN, proxy, business/education/government, or satellite.
- ISP: The organization providing internet access.
- Autonomous System (ASN): Roughly analogous to a phone carrier – a group of networks under a common routing policy, each with a unique identifying number. Examples range from consumer ISPs like Comcast and Verizon to cloud providers like AWS and Azure.
The challenge is that this metadata has enormous variety. There are countless ASNs, ISPs, and services that change constantly, which is exactly why Trestle uses a model rather than static rules to turn it into a single signal.
What Are IP Intelligence Checks in Real Contact API? #
IP intelligence checks are two attributes Real Contact API returns inside the ip_address object:
- IP Trust Score: 100 score for how legitimate an interaction appears based on the user’s IP address.
- IP Distance-to-Address: The approximate distance, in miles, between the user’s IP location and the address provided on the lead.
Both are populated only when you include an ip_address parameter in your request. It should be the IP captured at the moment of the web form submission, signup, or other interaction. If no IP is sent, there’s nothing for Real Contact to evaluate, and the ip_address object returns null.
Which Real Contact API Version Includes IP Intelligence Checks? #
IP intelligence is available only in Real Contact API 2.0. If you’re on version 1.0 or 1.1, the ip_address object won’t appear in your response. You’ll need to request an upgrade to 2.0 to access trust_score and ip_distance_to_address.
Upgrading is straightforward and comes at no additional cost. The IP attributes are included at the same per-query price as 1.1. To request the upgrade, reach out to your Trestle account executive or email support@trestleiq.com. For the full version comparison, response-structure changes, and step-by-step upgrade paths, see Real Contact API 1.1 vs. 2.0: What’s Changed and How to Upgrade.
What Does IP Trust Score Tell You? #
The trust_score is a 0–100 value that evaluates how legitimate an interaction appears based on the user’s IP address. Rather than a single yes/no flag, it weighs together the kinds of signals described above:
- Geolocation data tied to the IP.
- Metadata such as connection type, ISP, ASN, domain, and organization.
- Network and behavioral signals. How the IP is shared, and device and usage counts over time.
A higher score points to a stronger likelihood that the interaction came from a genuine source. A lower score signals potential risk, such as anonymizing services, heavy IP sharing, or other suspicious activity patterns.
Trestle built the IP Trust Score as a model trained on real-world outcomes rather than a set of rigid rules. Because IP metadata has such high variety and changes so quickly, a model can navigate the endless combinations of signals far more nimbly than a static rule set and avoids the false positives that come from blanket-blocking a whole category like “VPN.” That lets you set the trust threshold that fits your own risk tolerance.
For Trestle’s recommended score tiers and a side-by-side decision matrix that pairs trust_score with ip_distance_to_address, see Everything to Know About Real Contact API 2.0, which is the companion guide to interpreting these thresholds.
What Does IP Distance-to-Address Tell You? #
The ip_distance_to_address attribute is the approximate distance, in miles, between the user’s IP location and the physical address provided in the request. Think of it as a coherence check on an identity. The phone-to-name might look great and the address might be valid, but a connection originating thousands of miles away is worth a second look. It also lets Trestle bring its existing address validation and phone-to-address expertise to bear on the interaction.
A couple of important nuances follow directly from how geolocation works:
- Distance is a valuable signal, but not a standalone verdict. Legitimate users can appear far from their address because of VPNs, mobile networks, corporate gateways, or simple travel. A large distance is a reason to look closer, not automatic proof of fraud.
- A NULL value isn’t a red flag. Real Contact returns NULL when confidence in the IP’s location accuracy is too low to produce a reliable distance, which is common for mobile and anonymized connections. This does not necessarily mean something is wrong with the lead.
How Should You Read the Two IP Signals Together? #
The two attributes are most useful in combination because each one covers for the other’s blind spot.
A short IP Distance-to-Address on its own doesn’t guarantee the person is actually nearby. It may simply mean a VPN or proxy exit node happens to sit close to the provided address. That’s why distance is best read alongside IP Trust Score. If the trust score flags the connection as a VPN or proxy, a short distance means less than it appears. Likewise, a long distance paired with a high trust score may just be a traveling customer, while the same distance paired with a low trust score is worth a much closer look.
For the full trust_score and ip_distance_to_address decision matrix (including recommended actions for each combination) refer to Everything to Know About Real Contact API 2.0. Treat those thresholds as a starting point and benchmark them against your own conversion and fraud outcomes.
IP Intelligence vs. Contact Verification #
These answer two different questions, and you generally want both.
| Contact verification (phone, email, address) | IP intelligence (trust_score, ip_distance_to_address) | |
| Core question | Is this contact real, valid, and who they say they are? | Does this interaction appear to come from an authentic source? |
| What it evaluates | Phone validity and activity, email validity, address validity, name matches | IP network type, reuse/sharing patterns, geographic alignment |
| What it catches | Disconnected numbers, invalid emails, mismatched names, bad contact data | Anonymized traffic, location mismatches, suspicious IP sharing |
| Durability | Phone/email/address links to a person are relatively durable | An IP-to-person link is temporary and often shared |
| Blind spot it has | A real, verifiable identity submitted fraudulently | Whether the contact details themselves are reachable |
Contact verification confirms the identity is real. IP intelligence helps confirm that the real person was the one behind the submission. Used together, they give you a fuller picture than either can on its own.
How IP Intelligence Appears in the API Response #
When you pass an ip_address to Real Contact API 2.0, the ip_address object appears alongside your phone, email, and address results:
{
"phone": {
"contact_grade": "A",
"is_valid": true,
"activity_score": 95,
"line_type": "Mobile",
"name_match": true
},
"email": {
"contact_grade": "A",
"is_valid": true,
"name_match": true
},
"address": {
"is_valid": true,
"name_match": true
},
"ip_address": {
"trust_score": 92,
"ip_distance_to_address": 12
}
}A few practical notes:
- The ip_address query parameter is the IP captured at the time of the interaction (web form, signup, etc.). For example, ip_address=192.0.0.1.
- If you send a malformed IP, Real Contact returns the warning “Input IP address is invalid. Please provide a valid IPv4 or IPv6 address.”
- Both trust_score and ip_distance_to_address can return null individually depending on available data and geolocation confidence.
For the complete request and response schema, see the Real Contact API documentation.
Frequently Asked Questions #
Does IP intelligence cost extra?
No. The IP attributes are included in Real Contact API 2.0 at the same per-query price as 1.1, along with the refined contact grading. See the version comparison for details.
What happens if I don’t send an IP address?
The rest of your verification (phone, email, address, name matches, grading) runs as usual, and the ip_address object returns null. IP intelligence only evaluates an interaction when an IP is provided.
Why is ip_distance_to_address returning NULL?
Real Contact returns NULL when confidence in the IP’s location accuracy is too low to calculate a reliable distance, common for mobile and anonymized connections. It’s a data confidence signal and should not be considered a standalone indicator of a “bad” lead.
Is a VPN or shared IP automatically a bad sign?
No. IP sharing is normal. Mobile networks, corporate gateways, and privacy relays all share addresses among many legitimate users. The Trust Score is designed to weigh the type and behavior of the connection rather than flag sharing on its own.
Can I block leads using trust_score alone?
We don’t recommend it. IP signals are designed to be read together and alongside your contact grades. Real Contact API adds trust signals to lead verification; it isn’t a standalone fraud-blocking system.
I’m on Real Contact 1.1. How do I get IP intelligence checks?
Request an upgrade to 2.0 by contacting your account executive or emailing support@trestleiq.com. There’s no restriction on moving from 1.1 to 2.0, and pricing stays the same.
IP intelligence is available now in Real Contact API 2.0. If you’re already using Real Contact, check the API documentation to see the ip_address object and start sending an IP with your requests.
If you’re new to Trestle, start a free trial or book a meeting to talk through the right thresholds for your use case.
Questions? Reach out to support@trestleiq.com.