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.
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 |
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. |
{- "number": 40721987086,
- "dpoints": "originnetwork,network,type,porteddate,subscriberstatus,roaminginfo",
- "kyc_challenges": ""
}
{- "40721987086": {
- "current_network": {
- "lrn": null,
- "mcc": 226,
- "mnc": 10,
- "name": "Orange Romania",
- "spid": 4018740
}, - "is_roaming": false,
- "number": 40721987086,
- "origin_network": {
- "mcc": 226,
- "mnc": 1,
- "name": "Vodafone Romania",
- "spid": 4018720
}, - "ported": true,
- "ported_date": "2016-12-30 15:15:19",
- "ported_date_type": "exact",
- "present": "yes",
- "status": 0,
- "status_message": "Success",
- "type": "mobile",
- "etype": 10,
- "query": {
- "datapoints": "network,originnetwork,porteddate,roaminginfo,subscriberstatus,type"
}
}
}
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 “ | 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 “ | "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 “ | "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 “ | "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 “ | “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 “ | 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’
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.
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. |
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.
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. |
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).
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 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 | ||
String | Value that will be matched against the email on file, generating the matching score in the response. |
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 | ||
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:
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",
}
}
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"
}
}
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"
}
}
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",
}
}
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"
}
}
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" 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"
}
}
We provide the most comprehensive device, network and mobile numbering data available
Contact us > Chat to an expert >