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.

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.

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