Product Updates Updates

Introducing VPN detection

2022-04-16T21:10:45.783Z

We’re excited to announce VPN detection as a new feature. This is available to everybody!

Until now we were detecting abusers, attackers, bogons, cloud providers (datacenters), public proxies, relays, and also tor exit nodes. Starting today, we are adding VPN IP addresses detection to the list. Our VPN dataset contains several millions of IP addresses updated daily.

The new field is named is_vpn and appears under the security object of API responses we return.

As always, we'd love to hear your thoughts on this new feature as well as what you'd like us to build next! Leave us a reaction or feedback below.

New `is_relay` security field

2021-12-21T22:47:54.700Z

We’ve added a new security.is_relay field to responses we return when you look up an IP address (as always, official client libraries have also been updated).

The purpose of this new field is to identify IP addresses that are used by a relay node. Unlike VPNs, relay nodes are location-aware. Instead of bypassing geo-controls, a relay node pools multiple users behind the same IP address.

Using relay nodes is a manner to protect the identity and privacy of users behind individual IPs. Currently, we identify relay IP addresses from Apple Private Relay (APR).

When the new field is_relay returns true as value, then you know the request comes from devices making use of a relay node.

With the end of the year that’s also the time for us to thank you for an amazing 2021. See you in January, and have a wonderful holiday season!

Dedicated EU base URL

2021-12-07T13:45:00Z

Today, we are introducing a dedicated EU base URL:

https://eu.api.ipregistry.co

You can use it in replacement of our default base URL (https://api.ipregistry.co) to ensure your requests and related data are processed in Europe and not transferred outside.

Indeed, when you send a request to endpoints using the new base URL, your request is forwarded to the closest Ipregistry node in Europe via an anycast load balancer. Then, the EU node process your request but associated data is not transferred outside Europe.

All existing endpoints and options described in our docs work the same.

Note that using our new dedicated EU base URL makes sense if you have users or servers in Europe. However, if your users or servers are located for instance in the US, you will experience higher latencies. In that case, you should keep our default base URL.

Introducing Company Data

2021-10-28T11:55:00Z

We’re continuously working on improving our datasets. Innovation is also an important part. Today, we are introducing company data to provide customers with data on the company behind their IP traffic.

API endpoints returning data about an IP address are now including a new field named company. This field shares 3 pieces of information: the company’s name, domain name, and what type of company it is.

Official client libraries have been updated to support the new field. We suggest upgrading to the latest version if you are using one of these libraries.

Interested in accessing this new dataset as CSV for on-promise deployment? [email protected]" rel="noopener nofollow" target="_blank">drop us a line.

Wildcard support with Origin filtering

2021-07-13T12:00:00Z

Using Ipregistry you can filter origins, and control what API key is allowed to call the Ipregistry API from the client-side (i.e. your users’ browser). That’s really convenient to prevent unwanted usage of your API key from other websites.

A recurring use case we heard about is to accept any request that comes from subdomains of a given domain name but block other domains.

Let’s say you are a SaaS provider and you host customer resources on a subdomain of a shared domain. For instance customer1.acme.com, customer2.acme.com, etc., and on these pages you are calling the Ipregistry API. Then, instead of allowing each subdomain individually, you can now express the same need using a wildcard, depicted by the * character.

Before:

After:

The creation of new subdomains will no longer require updating origins on the Ipregistry dashboard.

CCPA and LGPD compliance

2020-10-20T15:17:00.001Z

Ipregistry was already GDPR compliant but starting Today it is also California Consumer Privacy Act (CCPA) and Lei Geral de Proteção de Dados (LGPD) compliant.

Our existing legal pages have been updated for this purpose.

Here are the links to the different documents if needed for review:

If you have any questions, you can send us an email at [email protected]" target="_blank" rel="noopener">[email protected].

Manual IP Address Search

2020-07-01T14:19:00.001Z

We’ve just deployed a new version of the dashboard that supports IP address lookup from within the dashboard. You can use this method for manual lookups instead of our API.

To access the feature, select “Search” in the left menu. Then, you can easily look up information about an IP address by filling up a field and pressing enter.

New API response headers and query option

2020-04-14T06:55:00.001Z

Every API call is now returning 2 new response headers:

Ipregistry-Credits-Consumed: the value associated to this response header contains the number of credits your request consumed.
Ipregistry-Credits-Remaining: returns the number of credits remaining on your account at the time the request was handled.

The old response header Ipregistry-Credits is deprecated and will be removed after Friday 14 August, 2020.

We are also introducing a new query option that transforms all field values that are returned to ASCII characters. By default, values are encoded using UTF-8.

This new option is particularly useful when integrating with legacy code that doesn’t support Unicode. To use the new option simply append &unidecode=true to your query URL as follows:

https://api.ipregistry.co/?key=tryout&unidecode=true

IP lookups are now returning the routing prefix

2020-01-15T05:12:00.001Z

Following recent requests, it was expressed a need to get the routing prefix associated with an IP address. This data is now included under the field connection.route for all API calls that return IP data. The value uses the CIDR notation.

Here is an example for an IPv4 address:

{
"ip" : "54.85.132.205",
"connection" : {
"asn" : 14618,
"domain" : "amazon.com",
"organization" : "Amazon Technologies Inc.",
"route" : "54.84.0.0/15",
"type" : "hosting"
}
}

and another sample with an IPv6 address:

{
"ip" : "2a01:e35:2f22:e3d0::1",
"connection" : {
"asn" : 12322,
"domain" : "free.fr",
"organization" : "Free SAS",
"route" : "2a01:e35:2000::/36",
"type" : "isp"
}
}

Other than this new data, we have improved our correlation algorithms and are proud to announce that IP geolocation accuracy has been improved for more than 30% of the entries we manage.

New field value CDN for connection type

2020-01-02T15:02:00.001Z

Happy New Year! We wish you the best for 2020. Last year was incredible and we are looking forward to continue innovating in the IP and cyber-security domains with you.

It was not possible to start this year without announcing something new! Starting Today, the API is now distinguishing IP addresses used by CDN (Content Delivery Network) from those used by a hosting provider. In other words, the connection.type field can now have values business, education, hosting, isp and cdn.

Following this change, the field security.is_cloud_provider is returning true if the connection usage type is cdn or hosting.

Here is an output excerpt from a Cloudflare IP address:

{
"connection" : {
"asn" : 13335,
"domain" : "cloudflare.com",
"organization" : "CloudFlare Inc.",
"type" : "cdn"
},
"security" : {
"is_cloud_provider" : true
}
}