HLR lookup API v2 has dropped

It is a very exciting time here at HLR lookup. As the champagne corks thump the ceiling and our development team breathe a collective sigh of contented relief, our next-level API goes live.

To say we are proud of HLR Lookup API v2 is an understatement. Not only is it a testament to the talents of my programming colleagues, it is also a cumulative collaboration combining feedback from our team, customers and the SS7 industry. In fact, it is this communication that not only allows our innovation but drives it. We revel in the challenge of delivering to our customer’s current needs and anticipating their future ones, with improved products and services. All of this, without additional cost to our customers.

HLR Lookup API v2 has spent over a year in development, with production efforts, naturally, hindered by lockdown. Not only did remote working disrupt the camaraderie of the office, now every member of the team was solely responsible for making their own coffee. Still, through the chaos of Covid, the team has delivered.

So what’s new?

In short, HLR Lookup API v2 is a complete overhaul of our flagship HLR Lookup API. It was initially designed with the intention of increasing the speed of HLR lookups. Customers turning to us from competitors consistently site increased speed as the major reason, and alongside our extensive coverage, speed is usually top of our customer’s requirements. As the code needed to be rebuilt from the ground up, we took the opportunity to completely redesign the HLR Lookup API allowing us to bolt-on extra juicy features, as and when the need arises.

I’ll summarise a few of the new features and when we get a chance, we’ll also write up a bit of geeky information about our technology stack and infrastructure at a later date.

From 180k to 1 million an hour per client

When we first built HLR Lookup there was no real market and it was difficult to envisage how popular the site would be. We built the service because we were heavily using HLR Lookups ourselves as a way of routing SMS messages and no one else provided a platform dedicated to it. “Sure, 50 lookups per second is enough for anyone” we thought. Oh how wrong we were.

Today the benchmark is higher. Providing ultra fast HLR Lookups has become a high priority for us, so our new APIv2 continues to be synchronous. Not only is a synchronous connection faster than an asynchronous one, it ensures that you receive your results immediately upon request. In other words, only a synchronous connection can give a truly real-time HLR lookup.

On average across all networks, a HLR lookup with APIv2 is 0.8 seconds faster than version 1 and we’ve allowed for 1m lookups per hour per customer, which is around 278 lookups per second for each customer. This isn’t to say that a single network operator will accept this volume of HLR Lookups from us, but we can work with the network operators to assess what volume they are comfortable with.

Depending on your business use case of course, you may not notice a huge change. The switch to APIv2 has been designed to be as simple as possible, and retain all the ease of use that you are used to experiencing from our original API, so it may not be instantly apparent just how much an incredible amount of time and effort has gone the development of APIv2. Such is the bane of a programmers life I suppose; when everything works perfectly, nobody even notices the expertise involved.

Speaking of expertise, a large (socially distanced) pat on the back must go to programmer Garry, who has shown no mercy to his own finger tips writing the code for APIv2.  Ably assisted by the rest of our development team, notably James and Iain with testing, troubleshooting and the new features.

I was on hand to nod encouragement and blog about it afterwards.

Extra numbering information when HLR lookup is not available.

The primary function of a HLR lookup is to establish whether a particular phone number is currently contactable and which network it has ported to. What about those rare occasions when a result cannot be achieved because the network operator who allocated the number doesn’t provide HLR Lookup information?

We have had customers ask about detecting fake telephone numbers, landlines, universal access numbers, numbers allocated for use in television and, of course, premium rate numbers. I’m happy to say we built these detections into HLR Lookup API v2. If a HLR lookup fails because the telephone number is not a mobile telephone number, from a network which provides HLR information, then we will still provide information on the number including the exact reason why HLR cannot be performed for the number. This is super useful for making decisions to know if a number is completely fake or could be real but is not currently in coverage for HLR lookups.

The scenario could be that you have integrated the HLR Lookup API to a form-fill on your website. When a user enters a telephone number, you can check if the telephone number is real and live. If the number they enter is not a mobile number but is a different type of number (eg. a landline), then we can inform you that the number could be real and that it is allocated to a telephone network and which telephone network it is allocated to.

Now you can make a decision to accept/decline a telephone number and know much more information about it than a standard HLR lookup.

When was the number last ported?

For HLR lookups in some countries, we can now give you the option of learning the date that the telephone number was last ported. For these countries, if the telephone number has been ported to a different network other than the originally assigned network then the getporteddate POST parameter information retrieves the date that the telephone number was last ported.

The main benefit for requesting this info from a HLR Lookup is to improve customer fraud protection by combatting ‘port-out fraud’. Port-out fraud is where a criminal tries to hijack a telephone number by transferring the number to a new telephone network and then using the number to receive one-time passwords for banking, email or other services. By knowing the date a number was last ported you can reduce the risk of fraud on your platform.

If the ported date is something that interests you then this result can be added as an additional output field on the JSON response. There’s an additional charge for the ported date and if the ported date is requested but the country searched is not covered, or the telephone number is not ported, or no date was retrieved there is no additional charge. If a telephone number was ported away from the original network to a different network and then was ported back to the original network it is not possible to retrieve the last ported date.

UK landline lookup

As you may know, we are headquartered in the United Kingdom and have some great network operator connections here. Many customers have asked if we can provide a way to check the live status of a landline telephone number – something which isn’t normally available over an SS7 HLR lookup. After an extensive research and development phase we are now confident to provide UK landline status, integrated via the HLR Lookup API.

The feature allows the ability to learn the status of a UK landline number including the standard HLR lookup responses LIVE and DEAD. Currently, this feature is in its BETA testing phase and is only available in the UK. More information about this feature is available to those who would like it. Simply get in touch using the contact details below.

HLR Lookup testing environment

Integrating the HLR Lookup API is relatively straightforward, however with a lot of new features and customers asking to run checks at 1m lookups per hour, we realised that having a testing environment was going to be an essential part of the integration process.

Having a testing environment means that developers can be confident testing out their code without incurring costs for the company, and means that you can simulate workflow on your end for your applications without worrying about topping up or your code running away in a loop!

The testing environment is a full-size replica of the HLR Lookup infrastructure, but ring-fenced from any network operators. When using the testing environment we don’t send the request out over the SS7 network; instead, we have a dummy responder which simulates real network responses, right down to variable delays and status responses. I’m sure the testing environment will get some hammer…

Ability to provide country ISO code and local numbering

Another handy feature, with particular applications on international website form filling, is the ability to POST a country’s ISO Alpha-3 code. By providing a country of origin, a phone number can be submitted in its local dialling format and our new API will do the rest. This takes the hard work out of remembering to substitute international country code prefixes. It also removes the chance of an error occurring when a local number inadvertently begins with numbers that are the same as a country code.

Get Early Access to APIv2

Although development is complete on our new API, we are still in the process of rolling it out across new and existing customers. If you would like to be among the first to use it and implement it immediately, you can request the API documentation directly by contacting us either email info@hlrlookup.com or raise a ticket through the portal.