Global Address Object:FAQ

← Global Address Object

What are the minimum hardware and OS requirements for the Global Address On-Premise API?

The Global Address On-Premise API does not have strict minimum requirements; it will run on most systems but just slower. Our recommended system environment is:

• 4-8+ Core Modern Server CPU
• 16GB+ RAM
• 150GB+ Hard Drive Space
• SSD level or faster disc access speed (important)

Global Address is only supported on 64-bit architecture. Currently, we support the following operating systems:

• Windows
• Linux (GCC 4.1 built on CentOS 5)

What type of global address information can I send?

Global Address is designed to take full standard addresses. This means that the address must, in most cases, have a house number, a street (or thoroughfare) and identifiable area data (like postal code and locality). The service will not behave particularly well for partial addresses, point of interest information (like a park or plot of land without a formal address), Directions (e.g. "across the street from ABC Bank") or non-address information (like phone numbers). The reason for this is that address verification relies on having a good address data source behind it in order to confirm its validity, and non-formal address data is not good enough to power our verification solution.

What are the minimum input fields required?

The only field that is really required is the country input. We cannot verify an address without a country. Secondly, almost all addresses must effectively have an AddressLine input. While it is theoretically possible to verify an address with a very unique piece of information like a postal code in certain countries and areas, that is very rare.

How should I send in my address input data?

Your input address can be sent in a number of ways. Our main advice is to try and send the data you have with as little manipulation as possible if you have a full address. The most common ways to send it are:

1. Full address in the AddressLines:

AddressLine1: 22382 Avenida Empresa
AddressLine2: Rancho Santa Margarita CA, 92688
Ctry: US

2. Full address in the AddressLines + Parsed Area:

AddressLine1: 22382 Avenida Empresa
Locality: Rancho Santa Margarita
AdministrativeArea: CA
PostalCode: 92688
Ctry: US

Note: What you want to avoid as much as possible is sending in duplicated information, like this BAD example below:

AddressLine1: 22382 Avenida Empresa
AddressLine2: Rancho Santa Margarita CA, 92688
Locality: Rancho Santa Margarita
AdministrativeArea: CA
PostalCode: 92688
Ctry: US

What encoding does Global Address use?

Global Address uses UTF-8 Unicode encoding. It is very important to make sure your data is in UTF-8 when sending to our service, especially for non-Latin countries. Be on the lookup for question marks (?), squares (▖) or other weird characters like �. They may be an indication of encoding issues and may result in data loss.

Why are there different levels of Address Verification Result Codes?

The address source data that is available to use as part of our Address validation product can differ from country to country. For most developed countries with a major postal agency like the United States, Great Britain, France, etc, we will have delivery point data available. However, there may be countries where that detailed data is not available, or simply does not exist. In those cases, we will use less detailed information. Here is an overview and inside peak of the types of data available:

• Delivery Point Data

Source: 1 Main St Apartment 12, Anytown 12345, USA

Max Verification Level: AV25

• Range Data

Source: 100-200 Main St, Anytown 12345, USA

Max Verification Level: AV24

• Thoroughfare Data

Source: Main St, Anytown 12345, USA

Max Verification Level: AV23

• Locality Data

Source: Anytown 12345, USA

Max Verification Level: AV22

What speed can I expect from Global Address Web Service?

The response time of the Global Address API is highly dependent on a number of factors:

• The country of the input. This is one of the most important factors as each country has its own engine in the background and its own verification paths and algorithms. A well-structured country like the US will be much faster than a less structured one like India. Also, a Latin-based address system will usually be faster than a non-Latin system.
• The quality of the address. A good address will be faster than a bad or partially bad address. Bad addresses will require extra steps, additional fuzzy matching logic, and extra parses before we either find a match or give up.
• The number of threads. You can increase the speed by increasing the number of threads until your system starts running out of resources. The important thing to pay attention to is that each thread has its own instance of the API.

The country in question will have the biggest impact on the speed. You may get anywhere from 100K/hour to over a million. Additionally, you can increase that speed likely 2X-5X by increasing the number of threads.

How does the Global Address engine handle different Scripts?

Global Address has an option called OutputScript that has 3 possible values:

• NoChange: We will detect the script of the input and leave output in that same script.
• Latn: We will change the output to Latin on output.
• Native: We will change the output to the native script of the country (Like Cyrillic for Russia)

Here are some things to make note of when trying to understand this functionality.

1. Global Address essentially supports up to two scripts per country. Latin and if the country uses a language that is not Latin based, we convert to that language if Native is set.
2. Note that Script and Language are not the same. English, Spanish, French are all Latin Script even if their alphabet and diacritics used are slightly different.
3. We can only change scripts for a record if we are able to verify and validate the address.
4. For Latin based languages, if you specify OutputScript=Latn, we will also remove the diacritics (Gjøvik vs Gjovik)