Product Updates Updates

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.

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

The United Kingdom left the European Union

2020-01-31T23:00:00.001Z

The United Kingdom left the European Union on 31 January 2020, at midnight. This change is reflected in the Ipregistry API and data sets.

The field in_eu is returning true for the remaining 27 state members: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Italy, Ireland, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Poland, Portugal, Romania, Spain, Slovakia, Slovenia and Sweden.

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
}
}

New currency data 💱

2019-10-30T10:08:00.001Z

The API has been updated to include 2 new fields in the currency section: name_native and plural_native.

The existing fields name and plural are returning, respectively, the currency name and plural name in US locale. The new fields return value in native locale based on detected location and primary language.

Here is an example for an IP address located in Tokyo:

"currency" : {
"code" : "JPY",
"name" : "Japanese Yen",
"name_native" : "日本円",
"plural" : "Japanese yen",
"plural_native" : "円",
...
}

Official client libraries have been updated to reflect the changes.

Dedicated Endpoint for User-Agent Parsing

2019-10-17T16:18:00.001Z

User-agent parsing is a great way to detect your users browser, device & OS in real-time to bring user experience to perfection: suggest native app download, tailor advertising, improve protection against crawlers, and more.

Our origin IP lookup endpoint, usually used on-client side was already returning raw and parsed user-agent data. However, parsing existing values from server-side was not possible. This is now part of the past since we added a dedicated endpoint for parsing up to 256 user-agent values from a single call.

You can read more in our documentation:
https://ipregistry.co/docs/endpoints#user_agent

Error Code for Bad Inputs

2019-08-29T07:15:00.001Z

It has been reported that inputting an invalid request body value for the batch lookup endpoint (using the POST method) was returning an HTTP 500 error. This was not impacting the service but confusing users.

We have introduced a new error code BAD_REQUEST that maps to the corresponding HTTP 400 status code. Any invalid request value returns a response with this new error code.

More Data Points!

2019-08-08T12:00:00.001Z

It was awaited by most of you. We’ve deployed a big update that brings new data points. Thanks to the hard work we made these last weeks to correlate and analyze data, we are proud to announce new data fields!

The API is returning a new carrier field that includes the carrier name, mcc and mnc as values. When non-null, it means the IP address is used for mobile carrier traffic with high probability.

New data includes also a connection.type field. It enables IP usage classification among business, education, hosting and isp. We provide this information with no extra fees! Besides, the connection field contains a new domain subfield that associates the organization name with a top level domain when available.

Last but not least, the security data includes a is_cloud_provider field. You can use it to identify IP addresses used for hosting purposes (e.g. a node on Google Cloud Platform, Amazon EC2, and more) and thus detect potential attacks.

You can read more in our documentation:
https://ipregistry.co/docs/fields#content

As always, your feedback is welcome!

Throttling per Client IP

2019-07-30T09:00:00.001Z

We’ve improved our Rate limit/throttling feature.

Once enabled, the rate limit feature was limiting the total number of requests that can be made per hour for a given API key. It was possible to have a user that consumes 10,000 look ups and another 10.

Starting Today, you have a new option to set an invocation limit per client IP and hour. Let’s say you enabled this feature and set 1,000 as a limit. Any client IP will be limited to 1,000 requests per hour.

You can control the feature from the Ipregistry dashboard:

Click on “API keys” on the left menu.
Select “Edit” for the key you want to alter.
In “Throttling / Rate limiting” section, choose “Set invocation limit per client IP and hour”
Enter your limit value and save.