Plivo provides access to the content of outbound messages for a period of seven days. This content can be found in the Messaging Logs section in the console. You can review a specific timeframe or UUID to retrieve message details. During the seven days, the message text can be located as demonstrated below:
Please note that this capability is only available if you have not redacted your message data. You can find more details about message redaction here.
Yes, with Plivo’s Lookup API you can find the proper local and E.164 phone number formatting, carrier information, and a caller ID names. For details, including usage examples, see Getting started with the Plivo Lookup API below.
See our getting started guide for Plivo phone numbers for API resources on Plivo phone numbers.
Plivo’s Lookup API lets developers query phone number information, including number validation and formatting, carrier information, and portability information associated with a phone number. This guide answers some common questions:
To look up a phone number, your application needs to make an HTTP GET request to Plivo’s Lookup API resource with the phone number you wish to look up. Here's a simple cURL script example:
curl -i --user auth_id_ID:auth_token \
https://api.plivo.com/v1/LookupNumber/{number}?info=serviceproviderIf you were to look up the phone number (204) 999-9999, for example, the Lookup API would return a response like:
{
"api_id": "ac073f08-xxxx-xxxx-xxxx-c19435b84cd7",
"country": {
"name": "Canada",
"code_iso2": "CA",
"code_iso3": "CAN"
},
"number_format": {
"e164": "+12049999999",
"national": "(204) 999-9999",
"international": "+1 204-999-9999",
"rfc3966": "tel:+1-204-999-9999"
},
"service_provider": {
"mobile_country_code": "XXX",
"mobile_network_code": "XXX",
"name": "Carrier Name",
"type": "Number_type",
"ported": "false"
}
}
In some cases, we do not have or can’t share information about portability status. In those cases, the Lookup API completes successfully with a response that contains "ported": "unknown".
If the value of ported in “unknown,” the carrier name value returned is unreliable, since we don't know whether the carrier continues to service this number.
The Lookup API will return an HTTP 404 status with a response that contains "code": 20404 when a phone number is determined invalid. See the section below on how Plivo determines phone number validity.
Lookup utilizes a variety of authoritative sources to return the most accurate response for a given Lookup type.
|
Lookup Type |
Data Sources |
Update Frequency |
|
Number validation and formatting |
International numbering plan data |
Real-time |
|
Carrier |
Mobile number portability and numbering plan data from each country’s phone number regulator (where available) |
Varies by country — |
|
Portability |
We don’t offer portability data |
NA |
|
Portability (international) |
Provided at additional cost |
Varies by country |
Phone number validity is based on international phone numbering plan data administered by the ITU. Though the ITU should in theory have all global numbering plans on file, in practice, not every country files its numbering plans with the ITU. Additionally, some government authorities may let telecom companies be responsible for administrating numbering plans. As a result of this lack of centralization, maintaining an accurate global numbering plan is a patchwork process. Plivo works with carrier partners to maintain accurate global numbering plan data, but discrepancies can arise as numbering plans change and downstream providers must propagate these changes.
Lookup will return an HTTP 404 status code if a phone number resource is invalid.
In the response for a Carrier Lookup, the type property specifies whether the phone is a landline, mobile, or VoIP phone.
VoIP phone numbers are easier to obtain, so they're sometimes used for fraudulent purposes. Customers often use Lookup to screen these numbers in their applications.
While the Lookup API is supported internationally, there are limitations to some request types:
Phone number validation and formatting: Number validation and formatting lookups are supported in all countries worldwide.
Carrier Lookup: This is supported worldwide with the following caveats:
The VoIP type will be returned only for carriers in the US. It is not supported outside of the US.
The mobile and landline types can be returned for all countries worldwide.
We return values in the mobile_country_code and mobile_network_code fields for 90+ countries where mobile number portability is supported. While MCC and MNC have wide international adoption, there are cases where mobile carriers are not associated with an MCC or MNC. When you perform a Carrier search via the Lookup API, Plivo returns this information if it’s available.
We do not offer portability data in the US and Canada.
The Lookup API handles only one phone number per request. For more information and recommendations, see Sending multiple requests to the Plivo Lookup API.
Lookup does not cache any response values.
You can request information for any number — mobile, landline, VoIP, premium, or special.
Every successful request is charged at $0.0040 per request. If your request is rejected or the callback returns with a 404 status, you will not be billed.
Autoreplace uses transliteration to get corresponding GSM-7 ASCII characters for given Unicode characters. The following ranges of characters in the Unicode character set are supported in the auto-replace feature.
Sometimes a Unicode character such as a smart quote, an em dash (—), or Unicode white space slips into your carefully crafted 125-character message, and your message gets segmented and priced at two messages instead of one.
When Unicode characters are used in an SMS message, they must be encoded using the UCS-2 character set. UCS-2 characters take 16 bits to encode instead of the seven bits used by the GSM character set used for most common letters and symbols, so when a message includes any Unicode character, it's segmented at 70 characters instead of 160 characters per message segment.
Plivo's intelligent message encoding feature detects easy-to-miss Unicode characters and replaces them with similar GSM-encoded characters to ensure that your message gets segmented at 160 characters and saves you from sending two messages.
Messages that include emoji or language-based characters such as kanji are not transliterated with automatic encoding. Here's the list of Unicode character sets replaced by automatic encoding.
No, you can only set your Plivo number as the source number for messages going to the US and Canada due to telecom regulations. You can, however, make an outbound voice call using Plivo’s APIs with a non-Plivo caller ID.
Dynamic sender IDs (i.e. non-Plivo numbers) may be used as the source number for messages directed to international destinations. We cannot guarantee that the source number displayed to the message recipient will match the number that was originally used.
Authorizing Plivo to view your SMS content helps our customer success teams debug content-related delivery issues for your account.
Messages can be marked as spam by network carriers for many reasons. Content policy violations are among the most common reasons why a carrier will flag your message. Plivo’s customer success team can help avoid having messages marked as spam by:
You can withdraw your consent at any time by visiting your Plivo console and reviewing your SMS settings.
Note: Outbound and inbound SMS messages for which log redaction has been requested are not visible to customer success teams regardless of this preference.
Outbound messages will be labeled as "failed" with Plivo error code 900 and will not be forwarded to downstream carriers. For the next two minutes after we generate this error code, all send message API requests will fail with the error "Insufficient Credit." This is to let you take action before queuing more messages.
All messages that are already queued in Plivo's system will continue to be marked "failed" with error code 900 as and when they are dequeued for processing until you add the necessary credits to the account.
Plivo is a pay-as-you-go API platform. Plivo relies on its carrier network to deliver messages successfully. In some cases, messages may be sent by Plivo but not received by users. Plivo charges for messages that are successfully sent from the Plivo platform.
Yes. Inbound messages are free for long codes but are chargeable on toll-free and short code numbers, even without the message_url or message_method configured, when the inbound message state is set as received.
Yes, you can send bulk SMS messages using a single Messaging API request. The request is similar to sending a single outbound SMS message, but you specify multiple dst (destination) numbers in E.164 format, separating the numbers with the "<" character — for example, "14156667777<14157778888<14158889999".
See our SMS getting started guide and Bulk Messaging reference guide for details.
For this example, let’s assume your web server is located at http://example.com. The following snippet will set up a route on your web server. Now, when we send an HTTP request to http://example.com/receive_sms, this route will be triggered.
If you don’t have a number, go to Phone Numbers > Buy Numbers to purchase a Plivo phone number.
Send an SMS to your Plivo number using a regular mobile phone. Plivo will send a request with message attributes to your Message URL.
An inbound message has two distinct stages: received and delivered or undelivered.
Plivo receives an inbound message from a carrier. The user is charged for this message. If the message_url or message_method is not configured in the user's application to the number that receives the message, the message remains marked as "received."
Once Plivo receives a message, it sends a callback with message attributes to the message_url. Based on the response received, the message is categorized as either delivered or undelivered.
When you send a long message that contains more than one SMS unit, the message is split into multiple units. Message concatenation assembles the multiple units back into a single message at the receiving end.
Plivo’s Messaging API automatically breaks long SMS text messages into multiple SMS messages and adds a concatenation header to each message so that all can be stitched together (concatenated) on the recipient’s mobile device. See our documentation for complete details.
Note: While Plivo’s APIs support concatenation, some carriers and handsets don't.
SMS text messages that are longer than the SMS character limit are concatenated and billed separately as individual text messages.
This screenshot shows a message that was divided into four units, with each unit costing USD 0.00250. The total cost to send this message was USD 0.01000.
Delivery reports (DLR) for long messages are processed the same way as single-unit messages. Only one message delivery report and one DLR is generated for long messages.
Plivo’s APIs support sending SMS in all text-based languages, including English, French, Spanish, Chinese, Arabic, and more.
Messages that contain only GSM03.38 seven-bit characters have a maximum limit of 1,600 characters. Messages that are longer than 160 characters will be split into multiple messages, with each message consisting of a maximum of 153 characters.
Messages containing one or more UCS-2 16-bit Unicode characters have a maximum limit of 737 characters. Messages longer than 70 characters will be split into multiple messages, with each message consisting of a maximum of 67 characters. The list of Unicode characters can be found here: https://unicode-table.com/en/#control-character
Multi-unit messages are automatically stitched back together and delivered as a single message in countries where mobile networks support long message concatenation.