Verify

Verify and validate customers globally using their phone number.

Velocity

Discover the network provider for every mobile number globally.

Authenticate

Protect customers, accounts, and transactions within your app.

Live

Discover if a mobile number is assigned to a subscriber.

Score

A real time phone number credibility score.

TeleShield™

Identify if a number has the propensity to be used for fraud.

Banks and Financial Services
E-Commerce
Insurance
Mobile Messaging
Gaming & Gambling
Communication and Service Providers
Identity & Verification Providers
eBooks
News
Developers
Viteza
FAQ
About us
Events
Careers
Contact us
TMT Verify API specs

TMT Verify API specs

Download OpenAPI specification:Download

About TMT

TMT ID is a leading provider of data, intelligence and analytics, helping customers find extra value from the information they hold. Our team of technology and telecommunications specialists has a proven track record empowering companies, brands and agencies around the world to better understand their businesses and their customers. TMT ID has a suite of technology and telecommunications data available, for further information, please visit www.tmtid.com or email info@tmtid.com.

Standard API Call

POST method

header Parameters
X-API-Key
required
string

The API key (obtained from https://viteza.tmtid.com or from Support during customer on-boarding).

X-API-Secret
required
string

The API secret (obtained from https://viteza.tmtid.com or from Support during customer on-boarding).

Content-Type
required
string

application/json

Request Body schema: application/json
number
string

The Phone Number with the country code.

dpoints
string

Enumeration of the requested data points, comma separated.

kyc_challenges
string

Specific to kycmatch data point. See section 3.

Responses

Request samples

Content type
application/json
{
  • "number": 40721987086,
  • "dpoints": "originnetwork,network,type,porteddate,subscriberstatus,roaminginfo",
  • "kyc_challenges": ""
}

Response samples

Content type
application/json
{
  • "40721987086": {
    }
}

Available data

The TMT Verify API is a fully flexible system, that allows customers to request only the parameters that they wish to see returned, on a query-by-query basis. The table below summarizes, for each type of request, the data points that will be returned against a given query Data Points:

Datapoint Description Response values
"type" The type associated with the queried number "Fixed" or "Mobile"
"etype" The service provides the etype (enhanced type) as well. etype information is provided in the “” block. Number from 1 to 33 indicating type.
"network" Indicates the current mobile operator that provides services for the queried number. Verify responds with the “current_network” block of information. MCC, MNC, name, SPID, LRN and OCN of the operator.
"originnetwork" The original mobile operator who issued the number. Verify responds with the “original_network” block of information. MCC, MNC, name, SPID and OCN of the operator.
"porteddate" The most recent date when the number was ported. Verify responds within the “” block. "ported_date" and "ported_date_type" fields.
"porting_history" A list of porting events since TMT ID began logging these events for the country to which the queried number belongs. Verify responds with a “porting_history” block for each porting event. The block contains “ts”, “action”, “tmtnetwork”, “i_type”.
"subscriberstatus" Returns the presence of a number in the current network. Verify provides the “present” field in the “” block. "present" is either "yes", "no", or "n/a".
"roaminginfo" Indicates if a phone number is currently roaming internationally or not. Verify always returns the field “is_roaming” in the “” block. If the number is roaming, Verify also returns the “roaming_mcc” and "roaming_mnc" fields "is_roaming" is either "true" or "false", mcc and mnc also returned if number is roaming internationally.
"deactivation_last" USA only. Indicates the last time a number deactivation event occurred. The service returns the “deactivation_last” block of fields. "deactivation_last" includes “operator”, “action”, and “ts”.
"deactivation_history" USA only. Provides to up to the 10 most recent deactivation events. The service will return a set of fields for each deactivation event. All sets will be provided in the “deactivation_history” block of fields. Each deactivation event returns the following fields (“operator”, “action”, “ts”, “number”, “number2”).
"simswap" The most recent SIM card change event connected to the number. Verify returns the “simswap” block of fields. “last_day”, “risk_indicator”, “simswap_min_threshold”, “simswap_max_threshold” and “date” fields.
"portfraud" Information in relation to any recent porting activity, in the “” block of fields. “present” and “portfraud” fields.
"tmt_score" Overall number credibility score using the TMT ID score algorithm and several data sources. Verify returns the field “tmt_score” in the “” block of fields. Integer score from "0" (low credibility) to "100" (high credibility).
"online_presence" Whether the provided number exists on a range of online platforms. Verify will return the "online_presence" block of fields. Within the "online_presence" block each supported platform is listed with "true", "false" or "N/A" as appropriate.
"age_verification" Indicates if the owner of a given phone number is over or under a certain age threshold. Verify will return the “verified” and “threshold” fields in the “age_verification” block of fields. "verified" either "0", "1", "-1", or "-2", "threshold" presented as an integer only when "verified" = "1".
"kycmatch" Offers the possibility to match the personal information provided for the holder of a given phone number against the data held by the mobile operators and other authoritative sources. Verify provides results in the “kyc_results” block of fields. “kyc_results” contains the fields “first_name_score”, “last_name_score”, “name_score”, “address_score”, “postcode_score”, “dob_score”. Each provided field contains a match score from "0" (no match) to "100" (full match).
"normalize" (part of "kycmatch") The service will normalize the address supplied against an external source or offers the option to input the address as a single continuous string Normalised address with option to see how normalisation has modified input data.

Notes:

  • Where the subscriber number has been ported more than once, only the most recent (i.e.current) Mobile Network will be returned as part of the Ported Network Information. In all cases the Original Network Information will remain unchanged by multiple porting events.

  • The Enhanced Type (etype) value that is returned as part of a type query is based upon the type of number allocated (typically by the regulator) to the block of numbers in which the queried number resides. There are 33 different potential values that could be against a given number, although it should be noted that not all of the number types are used in every country. The available supported types are:

etype Value etype Value etype Value
1 Audio Text 12 Mobile to Mobile 23 Shared Cost
2 Calling Cards 13 National Geographic 24 Short Codes Commercial
3 Electronic Services 14 National Rate 25 Specialized Mobile Radio
4 Freephone 15 Non inter-model CC (Portability =Y) 26 Telegram
5 Geographic 16 Paging 27 Universal Access
6 Intermodal Numbers (FIX<->MOB porting 17 Payphone 28 Videotex
7 Internet Service Provider 18 Personal 29 Virtual Private Network
8 Local Rate 19 Prefix Type Unknown (Portability =N) 30 Voicemail (geographic)
9 Machine to Machine 20 Premium Rate 31 Voicemail (mobile)
10 Mobile 21 Routing Code 32 VoIP Telephony
11 Mobile (CDMA) 22 Satellite 33 Wireless geographic
  • When responding to requests for Roaminginfo, the is_roaming field is always supplied. If the queried number is currently roaming, the additional fields of Roaming Country Name, Roaming Country Code, Roaming Operator MCC etc. will be provided if they are available from the live network query.

  • The porteddate uses data from TMT ID’s own records and is not present in Live network queries. In some markets, historic data is available to TMT ID dating back to the beginning of Number Portability in that country, in other markets this data is maintained from TMT ID’s own records going back to when that market was first on-boarded. Therefore, the combination of Port Date and Port Date Type field are provided to denote the following:

Port Date Type Port Date Notes
Exact DD/MM/YYYY Port date shown is correct as most recent port Before DD/MM/YYYY The number has been ported in the past, but it has not been done since TMT ID onboarded that market. In this case date shown is the date on which TMT ID started to gather data.
Null Null Number has never been ported

This combination of the Port Date Type and Port Date can be used by the Customer to identify any recent porting activity, regardless of whether date is ‘Exact’ or ‘Before’

  • The porting_history field providers a full list of all documented porting events that are contained in TMT ID’s own Number Portability database. For this reason, porting_history is only available for on-net countries and the list of events will only be provided from the date on which that country was first on-boarded by TMT ID (contact your account manager for a comprehensive list of on-boarding dates). A single porting_history query for a given number will return, in reverse chronological order, all known events against that number. For each event the following information is provided:
Field Description
action Either ‘A’ for Add meaning a port of the number to a different Mobile Network Operator or ‘D’ for Delete meaning that the number has returned to the original range holder of that number and is no longer considered as ported.
tmtnetwork The network identification of the destination Mobile Network Operator of the porting event. As with other datapoints the Mobile Network Operator is identified by MCC/MNC.
i_type Number type: ‘m’ – mobile, ‘f’ – fixed, ‘o’ - other
TS Timestamp of when the porting event was recorded in the TMT ID database (YYYY-MM-DDTHH:MM:SS)

Note 1: The Timestamp is the time that the change was recorded in the TMT ID database, not the precise time on which the porting event will have occurred. Most countries provide daily movement updates so the actual porting event will have occurred within a few days of it being recorded in the database.

Note 2: Because the porting_history contains records since the country was on-boarded by TMT ID, numbers that ported before this will not return any records to a porting_history query. Therefore, it would be possible to have a given number with a porteddate of the type ‘BEFORE’ indicating a historical porting event but have a null porting_history.

  • The Port Fraud Risk is only provided where a Live network query is possible, and is expressed in terms of the elapsed time since the last recorded porting event. The below table summarizes the responses:
Risk Index Description
Very High Number ported within last 24 hours
High Number ported within last 25-96 hours
Medium Number ported within last 30 days
Low Number ported outside 30 days, or not at all
-1 No Live query data available for that country, network or number
-2 if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.
  • SIM Swap is only provided where data from the appropriate Mobile Network Operator is available, and is expressed in terms of the elapsed time since the last recorded change of the SIM card (IMSI number) associated with the queried number. Because the data from the Mobile Network Operators can be provided in multiple formats, the simswap response can contain up to 4 elements. SIM Swap Risk is generated from the information supplied by the Mobile Network Operator based upon an algorithm as described in the table below:
Risk Index Description
Very High SIM/Device changed within last 24 hours
High SIM/Device changed within last 25-96 hours
Medium SIM/Device changed within last 30 days
Low SIM/Device changed outside 30 days, or not at all
-1 No data available for that country, network or number
-2 if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.

Some Mobile Network Operators provide the exact timestamp associated with the last SIM card change, where this is available it is provided in the SIM Swap response as SIM Swap Date.

In other cases, where a Mobile Network Operator provides a time for the most recent SIM Swap that is within certain bounds (such as more than 24 hours and less than 72 hours), these min and max thresholds will be provided as SIM Swap MIN and SIM Swap MAX.

  • The Device Swap Risk is only provided where data from the appropriate Mobile Network Operator is available, and is expressed in terms of the elapsed time since the last recorded change of the Device associated with the queried number. The below table summarizes the responses:
Risk Index Description
Very High Device changed within last 24 hours
High Device changed within last 25-96 hours
Medium Device changed within last 30 days
Low Device changed outside 30 days, or not at all
-1 No data available for that country, network or number
-2 if several datapoints, including the Simswap were requested, indicates that the specified phone number belongs to an MNO that is either not configured or unauthorized for Simswap.
  • Deactivation History is only provided for USA numbers. For the supplied number TMT Verify will scan the deactivation list for up to 10 of the most recent events in the database against the supplied number. Each event will contain the name of the Mobile Network Operator who recorded the event, together with the following 2-digit code to show the type of movement:
Code Meaning
DE Number deactivated by operator (no longer belongs to subscriber)
SW Number swapped (transferred) to a different subscriber. Available for T-mobile and Verizon subscribers only.
SU Number suspended. Verizon subscribers only.
RE Number reactivated. Verizon subscribers only.

If the number supplied does not appear in the US Deactivation list then an N/A response will be returned. This does not mean that the number has never been subject to a deactivation, suspension or transfer, but it does mean that it has not happened since the beginning of TMT ID data for US Deactivation (June 2019).

  • The Status is not a customer selectable field and is provided in the response to every query. Two parameters are provided, the Status and the Status Message. The below table summarises the possible status conditions:
Query Result Status Status Message
Success 0 Success
Number not valid according to numbering plan for that country 1 Invalid Number
Country queried is not available to be queried by this service 2 Not Allowed Destination
The query has not been completed due to congestion (typically with upstream providers) 3 Congestion
The query has only been partially completed due to the unavailability of one or more data sources 4 Partial Reply
  • The KYC Match request (name/address/dob match) is a POST request that requires at least one additional parameter sent in the payload/message body. The POST format provides an additional level of security allowing Customer queries to provide multiple parameters (that are necessary for KYC Match) as part of the query.

The KYC Match API has four logical matching blocks – each block having its own challenges (data) that will be used to generate a score. The provided score ranges between 0 and 100, where 0 is equal to no match, and the higher the score, the closer the match. To assist in providing data that is useful a match score is supplied against each supplied parameter (where possible) within the block. This provides additional useful data in the event that name and address information is not correctly specified or contains minor spelling discrepancies etc.

As part of the POST format used for KYC Match, the below table summarises the elements of each block, the requirements from the Customer and how the matching score is devised. Customers may request multiple blocks as part of a single query but must supply the challenge information for each block requested.

Challenge Type Notes
Block 1: Name
first_name String Value that will be matched against the first name on file, generating the matching score in the response.
last_name String Value that will be matched against the last name on file, generating the matching score in the response.
middle_name String If middle name matching is available, the middle name matching score will be returned in the response. If middle name matching is not available, the submitted middle name will be matched with the submitted first_name and an overall first name match score will be returned.
Block 2: DOB
day Numeric Value Day of birth. This parameter will be used with month and year to generate an overall matching score for DOB.
month Numeric Value Month of birth. This parameter will be used with day and year to generate an overall matching score for DOB.
year Numeric Value Year of birth. This parameter will be used with month and day to generate an overall matching score for DOB.
Block 3: Address
The challenge parameters associated with this block will be used to generate individual - parameter level matching scores where data is available. Otherwise, an overall address matching score will be provided.
street_no String Value that will be matched against the street number on file, generating a street number matching score where available, otherwise having a weight in the overall address matching score.
street String Value that will be matched against the street name on file, generating a street name matching score where available, otherwise having a weight in the overall address matching score.
unit_name String house name
Value that will be matched against the house name on file, generating a unit number matching score where available, otherwise having a weight in the overall address matching score.
unit_no String unit number
Value that will be matched against the unit number (building number) on file, generating a unit number matching score where available, otherwise having a weight in the overall address matching score
city String Value that will be matched against the city on file, generating a city name matching score where available, otherwise having a weight in the overall address matching score.
province String province/county/region
Value that will be matched against the province on file, generating a province name matching score where available, otherwise having a weight in the overall address matching score.
postcode String Value that will be matched against the postal code on file, generating a postal code matching score where available, otherwise having a weight in the overall address matching score.
country String Value that will be matched against the country on file, generating a country name matching score where available, otherwise having a weight in the overall address matching score.
Block 4: Email Address
email String Value that will be matched against the email on file, generating the matching score in the response.

KYC Match Response Parameters

The below table summarises how the response format is provided for each KYC Match block. Numeric value between 0 and 100 are provided representing the match score, with code -1 provided if the parameter for the match was not provided either as part of the Customer POST or from the data provided to TMT ID from the appropriate data provider.

Name Type Notes
Block 1: Name
first_name_score Numeric Value
last_name_score Numeric Value
middle_name_score Numeric Value If middle name was provided in the request but middle name matching was not available, the request parameter middle name was used to generate the first_name_score.
name_score Numeric Value If individual matching scores for first_name, last_name, middle_name are not available, an overall matching score will be provided.
Block 2: DOB
dob_score Numeric Value
Block 3: Address
street_no_score Numeric Value
street_score Numeric Value
unit_no_score Numeric Value
city_score Numeric Value
province_score Numeric Value
postcode_score Numeric Value
country_score Numeric Value
address_score Numeric Value If previous individual matching scores are not available, the overall address score will be provided.
Block 4: Email Address
email Numeric Value

Notes on KYC match score:

  • Address Scores are returned individually for all available parameters, within the possible range of -1 to 100. A -1 score signifies that the Mobile Network Operator in question does not have any data in their systems for the supplied number with which to respond. This should be interpreted as a neutral result in any trust calculations undertaken by the customer, in comparison to a '0’ score which signifies that the Mobile Network Operator possesses data but that the supplied challenge data does not match (which is a negative result).

  • Mobile Network Operators offer a range of different response types for name and address matches. Some operators apply logical matching and return a match score of 1-10 or 1-100 whilst others respond with a more binary ‘Y’ or ‘N’. TMT Verify On-boarding respond always with a numerical score. In the event that the Mobile Network Operator provides a score, it is either passed through (0-100) or multiplied by 10 (0-10) and the binary values are converted from ‘Y’ to 100 and ‘N’ to 0.

  • Street and Street number score are from experience very challenging to obtain a match between the customer-supplied data and that of the Mobile Network Operator, particularly in the case of those operators who respond with a binary ‘Y’ or ‘N’. One of the significant benefits of TMT Verify is that it offers a match score against each element of the address individually, so harder to match elements can also be compared with more standardised information such as post/zip code. It is the decision of each customer how the utilise the responses provided to the KYC Match in their own logic and decision making process however many organisations who have tested the service have concluded that they should place a lower weighting on the street and street number than on other attributes such as postcode and date of birth.

  • United States of America street addresses conform to a standard format. This is written as street number and street name (commonly known as address line 1) and apartment or unit number (commonly known as address line 2). In order to get the highest level of matches TMT Verify customers should supply address line 1 information as street in an address match query and supply address line 2 as street_no.

  • Last name and first name. In common with the point above on street name and street number, it is not uncommon for last or family name to obtain a higher percentage of accurate matches than first name. There are multiple reasons for this including increased probability of miss-spelling, multiple first names etc. As before this is particularly an issue where the operator applies a binary ‘Y’ or ‘N’ match. For this reason generally customers place a much higher weighting on family name than on first name.

Specific Datapoint responses

As previously mentioned in section 3, TMT Verify is a fully flexible API where Customers can request specific datapoints as and when required. This section gives some example queries and responses for common use cases:

type

Provides information on the type of a given number. This consists of two response parameters, type which allows the customer to see if the number is fixed or mobile, and enhanced type (etype) that provides more information on the allocated type of the number (e.g. premium rate, VoIP etc.):

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "447771000003", "dpoints": "type"}'

Response:

{
 "447771000003": {
  "number": 447771000003,
  "type" : "mobile",
  "etype": "10",
  "status" : 0,
  "status_message" : "Success",
 },
 "query" : {
  "datapoints" :"type",
 }
}

Porteddate

To help combat the increasing risk of so-called port-out fraud, TMT Verify can supply, for all on-net countries the exact date that the most recent porting event associated with the number happened:

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "40721987086", "dpoints": "porteddate"}'

Response:

{
 "40721987086" : {
  "number" : 40721987086,
  "ported" : true,
  "ported_date" : "2016-12-30 15:15:19",
  "ported_date_type" : "exact",
  "status" : 0,
  "status_message" : "Success"
 },
 "query" : {
  "datapoints" : "porteddate"
 }
}

Porting_history

A more detailed history around the porting events that a given number has undergone, which can be a useful indication of the economic activity and longevity of a number.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{"number": "40739521819", "dpoints": "porting_history,network"}'

Response:

{
 "40739521819" : {
  "number" : 40739521819,
  "current_network" : {
  "lrn" : null,
  "mcc" : "226",
  "mnc" : "01",
  "name" : "Vodafone Romania",
  "spid" : 4018720
 },

 "ported" : false,
 "porting_history" : [
   {
     "action" : "D",
     "tmtnetwork" : 4018720,
     "i_type" : "m",
     "ts" : "2022-01-31T00:00:00"
   },
   {
     "action" : "A",
     "tmtnetwork" : 4018740,
     "i_type" : "m",
     "ts" : "2021-03-18T00:00:00"
   },
  ],
  "status" : 0,
  "status_message" : "Success"
 },
  "query" : {
      "datapoints" : "porting_history,network"
      "trxid" : "SDF8hD3"
     }
 }

Deactivation_history

By performing a query against the USA deactivation data, TMT Verify will look for evidence that the supplied number has any history of deactivation, and if so, will append up to the 10 most recent events to the response.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "12016572115", "dpoints": "deactivation_history"}'

Response:

{
 "12016572115": {
  "number": 12016572115,
  "deactivation_history": [
  {
    "operator": "ATT",
    "action": "DE",
    "ts": "2021-03-10T00:11:29",
    "number": 12016572115
  },
  {
   "operator": "ATT",
   "action": "DE",
   "ts": "2020-01-10T00:10:55",
   "number": 12016572115
  },
  {
   "operator": "ATT",
   "action": "DE",
   "ts": "2019-07-01T00:10:03",
   "number": 12016572115
  }
 ],
 "status" : 0,
 "status_message" : "Success"
},
"query": {
 "datapoints": "deactivation_history",
}

}

Roaminginfo

By performing a real-time network query, TMT Verify will look for evidence that the user is roaming internationally, and if so, will append roaming details to the response. The values are obtained by querying the 3 different network signalling routes.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "40721987086", "dpoints": "roaminginfo"}'

Response:

{
  "40721987086" : {
    "is_roaming" : false,
    "number" : 40721987086,
    "status" : 0,
    "status_message" : "Success"
  },
  "query" : {
    "datapoints" : "roaminginfo"
  }
}

portfraud

portfraud checks TMT ID’s own database, as well as doing a live network signalling check to determine if the queried number has undertaken any recent porting activity. Based upon that risk, portfraud returns a risk value as described in section 3.

Example:

curl -L -X POST 'https://XXXXXXXXXX/v3' -H 'X-Api-Secret: xxxxxxxxxxx' -H 'X-Api-Key: xxxxxxxxxxx' -H 'Content-Type: application/json' --data-raw '{ "number": "40721987086", "dpoints": "portfraud"}'

Response:

{
  "40721987086" : {
    "portfraud" : low,
    "number" : 40721987086,
    "status" : 0,
    "status_message" : "Success"
    },
  "query" : {
    "datapoints" : "portfraud"
  }
}

kycmatch

KYC Match takes as input both the queried number as well as the challenges/data that need to be matched. TMT ID will use our own data to determine which MNO (Mobile Network Operator) to send the match query to. This query will be made to the operator and then the KYC Match Results will be returned for the queried data.

For each attribute an individual match score is returned, ranging from -1 to 100. This takes account of the variability in the scoring method used by different Mobile Network Operators when comparing the challenge data to their records. For example, some operators use a heuristic-type matching algorithm and provide a numeric score based upon the percentage match, whilst others provide a simple ‘MATCH/NO MATCH’ against the challenge. As described above TMT Verify normalise these responses, responding with the percentage score if one is provided or converting the MATCH/NO MATCH to 100/0 respectively.

In all cases, a -1 value is returned to signify that the Mobile Network Operator does not hold information on that number to match against. This allows customers to accurately distinguish a ‘0’ response (which means that the operator holds data but it does not match the challenge) from a less negative ‘-1’ where the operator cannot say one way or the other whether the data is correct.

Example:

POST /v3 HTTP/1.1
Host: XXXXXXXXXX
Accept: application/json
Content-Type: application/json

curl -L -X POST 'https://XXXXXXXXXX/v3' \
-H 'X-Api-Secret: xxxxxxxxxxx' \
-H 'X-Api-Key: xxxxxxxxxxx' \
-H 'Content-Type: application/json' \
--data-raw '{
  "number": "40721987086",
  "dpoints": "kycmatch",
  "kyc_challenges": {
    "name": {
       "first_name": "John",
       "middle_name": "Robert",
       "last_name": "Smith"
    },
    "dob": {
       "day": "2",
       "month": "11",
       "year": "1985"
    },
       "address": {
       "street": "Omnia",
       "street_no": "23",
       "unit_no": "11A",
       "city": "Toronto",
       "state": "Ontario",
       "postcode": "M4B1B3",
       "country": "CA"
    },
      "email": "john_smith@example.com"
  }'

Example Response – Individual Address KYCMatch Scores:

{
"40721987086" : {
    "kyc_results" : {
        "first_name_score": 100,
        "last_name_score": 100,
        "middle_name_score": -1,
        "street_no_score": 100,
        "street_name_score": 80,
        "unit_no_score": -1,
        "city_score": 79,
        "province_score": 0,
        "postcode_score": 100,
        "country_score": 100,
        "dob": 50,
        "email_score": 100,
    },
  "number" : 40721987086,
  "status" : 0,
  "status_message" : "Success"
  },
  "query" : {
   "datapoints" : "kycmatch"
  }
}

Example Response – Overall Address KYCMatch Score:

{
"40721987086" : {
    "kyc_results" : {
    "first_name_score": 100,
    "last_name_score": 100,
    "middle_name_score": -1,
    "address_score": 78,
    "dob": 50,
    "email_score": 100,
    },
  "number" : 40721987086,
  "status" : 0,
  "status_message" : "Success"
  },
  "query" : {
   "datapoints" : "kycmatch"
  }
}

Online Presence

"online_presence" offers information regarding if the queried number is linked to an active account on a range of business and social platforms. The query returns a list of the available platforms for the corresponding country and the status of the number on that platform.

For queries against valid numbers, "online_presence" returns a complete list of all supported platforms with one of the following responses for each:

The service will provide the “online_presence” json block, including information related to each of the following platforms: WhatsApp, Telegram, Amazon, Google, Office365, Instagram, LinkedIn, Skype, Facebook, Viber, Twitter.

Request format:

curl -L -X POST 'https://api.tmtverify.com/v3/' -H 'X-Api-Key: apikey' -H 'X-Api-Secret: apisecret' -H 'Content-Type: application/json' --data '{"number":"13476841xxx","dpoints":"online_presence"}'

Response (valid number):

{
  "40737105xxx": {
    "number": 40737105xxx,
    "online_presence": {
      "whatsapp": 1,
      "telegram": 0,
      "amazon": 1,
      "google": 1,
      "office365": 1,
      "instagram": 1,
      "linkedin": -1,
      "twitter": 1,
      "skype": 0,
      "flipkart": -1,
      "viber": 0,
      "bukalapak": -1
    },
    "status": 0,
    "status_message": "Success"
  },
  "query": {
    "datapoints": "online_presence",
    "trxid": "LHfPR6J"
  }
}

Response (Vendor request failed):

{
  "40737105xxx": {
    "number": 40737105xxx, "online_presence": {},
    "status": 4,
    "status_message": "Partial Reply"
  },
  "query": {
    "datapoints": "online_presence",
    "trxid": "J7v1ofP"
  }
}

Response (Authorization):

{
  "40737105xxx": {
    "number": 40737105xxx,
    "type": "mobile",
    "etype": "10",
    "online_presence": {
      "error": 2,
      "error_description": "Authentication failed"
    },
    "status": 4,
    "status_message": "Partial Reply"
  },
  "query": {
    "datapoints": "online_presence,type",
    "trxid": "J7v1ofP"
  }
}
What Our Customers Are Saying

"Phone number verification plays a critical role in helping to detect and prevent online fraud. TMT ID’s TeleShield product provides easy access to global mobile data, enabling us to enhance the actionable results of our MaxMind minFraud® services."

MaxMind

"BTS (Business Telecommunications Services) is successfully using TMT’s Velocity and Live services to check the status of mobile numbers. This way we make sure we optimize the performance of the service offered to our customers and ensure the quality of terminating traffic to all countries.”

Business Telecommunications Services

"Working with TMT’s TeleShield service has expanded our ability to detect fraud and minimise the risk to our business. TeleShield brings peace of mind and the opportunity to stop fraud before it affects our customers’ bottom line or the service."

Six Degrees Labs

"LATRO relies on TMT’s TeleShield to provide the most up to date and reliable numbering qualification information within our fraud reporting tools, enabling us to protect our customer’s revenues and empowering them to defend themselves against fraudulent numbers."

LATRO

"TMT is a valued partner that enables us to manage our routing costs effectively. They proactively and continuously expand their operator and country coverage while delivering exceptional customer service. We can always count on them to achieve high-quality results and look forward to our continued collaboration."

Global Message Service

"TMT provides us with the most comprehensive numbering intelligence data through their fast and reliable Velocity and Live services. TMT is a trusted partner for us, their products ensure that we continue to optimise the best performance and service to our customers."

Global Voice

"TeleShield from TMT gives 42com the power to detect and target telephony fraud scams internationally, thereby protecting our company from the financial and customer experience impacts of telecommunications fraud."

Alberto Grunstein - CEO

"It has been a pleasure to work with the team at TMT. They have become an essential provider of accurate numbering data information and Number Portability services globally."

Luisa Sanchez - VP of SMS and Messaging Solutions, Identidad Technologies

"Deutsche Telekom Global Carrier uses TMT ID as one of their key suppliers for Mobile Number Portability Data services. Deutsche Telekom Global Carrier uses TMT ID’s Velocity MNP solution. This is an ultra-fast query service that optimises the routing of international voice calls and A2P messaging."

Deutsche Telekom Global Carrier

Ready to get started?

We provide the most comprehensive device, network and mobile numbering data available

Contact us > Chat to an expert >