Country-Specific Restrictions and Features

Under Singapore’s Full SMS Sender ID Registry (SSIR) Regime, all organizations that send SMS messages to Singapore mobile numbers must now register the alphanumeric sender IDs they use with the Singapore Network Information Centre (SGNIC), the national registry responsible for authorizing and regulating sender ID registration. Registration is required for alpha and alphanumeric sender IDs, dedicated short codes, and dedicated virtual long numbers. 

Organizations must register directly with SGNIC. You must first create an account, then reserve sender IDs via the SSIR Portal. Sender IDs are registered on a first-come, first-served basis.

Beginning January 31, 2023, only registered sender IDs will be passed through as is. Unregistered sender IDs will be replaced with “Likely-SCAM.” 

Beginning July 1, messages with registered sender IDs will be passed through and those with unregistered sender IDs will be blocked.

How to create an account

To register your sender IDs you must first create an account on the SSIR portal. 

Only organizations with a local unique entity number (UEN) as issued by relevant government agencies can register with the SSIR. Foreign-based businesses can obtain a UEN by registering with the Accounting and Corporate Regulatory Authority (ACRA). A foreign business can register as a local subsidiary or as a foreign branch office. Foreign-based businesses can register for sender IDs with SSIR via their local subsidiary or foreign branch office as long as the local subsidiary or foreign branch office can present a valid UEN. Non-business organizations (such as charities or religious bodies) can register with agencies that issue UENs to these types of organizations. 

SGNIC will notify you when your account has been approved, after which you can log in to the portal and reserve sender IDs. The Admin account holder in the portal may also create User accounts for your organization.

How to register sender IDs

Before you begin entering your registration information, review the rules for valid sender IDs, then enter your information in the SSIR Portal.

Plivo customers should specify 8x8 International Pte Ltd a.k.a. Wavecell as their Participating Aggregator (PA).

At the same time as you register your sender IDs, please create a Letter of Authorization (LOA) and submit it to Plivo as an attachment to a support ticket. PFA the sample LOA as a template.

Pricing

You can reserve sender IDs at no cost through January 31. SSIR will bill organizations for setup fees and sender IDs beginning February 1; an invoice will be emailed to the organization’s designated billing contact.

When you send an SMS message to a US or Canada destination number, use a US long code number from your Plivo account in the international format. If you use any other number in the source parameter, you'll get the error "this caller ID is not allowed for outbound message."

Long codes are regular 10-digit US and Canada phone numbers that can make and receive voice calls and send and receive SMS messages. Long codes are meant for person-to-person (P2P) communication. Long-codes are not appropriate for application-to-person (A2P) bulk messaging.

Carriers will block SMS messages:

1. When more than 200 SMS messages are sent per day per long code number.
2. When the ratio of incoming to outgoing SMS on a long code number is more than 1:3.
3. For destinations other than US and Canada, when more than 1 SMS is sent every four seconds from a long code number.
4. When the same message is sent to the same user within 5 to 10 seconds of the first message.

 Other factors that can result in SMS blocking: 

•   The use of repetitive URLs and keywords or link shortener URLs in the SMS content.
•   Multiunit messages. 

Note: When sending SMS to US destination numbers, specify your US Plivo long code number in E.164 format. If you don't, you'll get the error message "This caller ID is not allowed for outbound message."

We provide an application-level flag to control whether message content or source numbers from incoming messages to Plivo phone numbers should be redacted from Plivo debug logs and databases.

When message redaction is enabled for an application, we make three kinds of redactions:

1. The content of incoming messages to Plivo phone numbers associated with the application are redacted from all internal Plivo server logs and the debug logs available on the Plivo console.
2. The last three digits of the source number from which the SMS originated are redacted from all internal Plivo server logs and the debug logs available on the Plivo console.
3. The last three digits of the source number from which the SMS originated are redacted from the Message Detail Record (MDR) generated for the message. Fetching MDRs for such messages would then return the redacted source numbers.

Configuring message redaction for Plivo applications

Message redaction is disabled by default. You can enable and disable it through the Plivo console or by using the application XML object.

Turning message redaction on or off from the Plivo console

Visit Messaging > XML Applications and select the application you're interested in. Toggle the Redact Incoming Messages checkbox to enable and disable redaction for incoming messages to phone numbers associated with the application.

Turning message redaction on or off using the Application XML object

Use the log_incoming_messages attribute of the application resource to enable or disable message redaction.

When creating a new application, set the log_incoming_messages attribute to false in the Create Application API request to enable message redaction. The default value for this attribute is true, which means that message redaction is disabled.

You can enable or disable message redaction for any application at any time using the Update Application API.

How does message redaction impact the message URL payload?

Message redaction offer you control over message details that may be logged in Plivo systems for debugging purposes.

If a message_url has been configured, Plivo will attempt to post the nonredacted message content and the nonredacted source number to it.

For enhanced security, we recommend that you configure secure HTTPS endpoints for message URLs.

Plivo can identify invalid and non-SMS-enabled destination numbers. Since we don’t accept for delivery messages sent to invalid destination numbers, we do not charge for them. We can also fix an incorrectly formatted destination numbers to improve delivery rates and provide a better end-user experience. 

Synchronous handling for invalid numbers

Customers can propagate an invalidation error upstream easily, since SMS API requests to invalid and non-SMS-enabled numbers are rejected with a 400 Bad Request API response. Here’s an example of how this works in a one-time password (OTP) use case:

Step 1: A user requests an OTP on an invalid destination number.

Step 2: The customer initiates a Send SMS API request.

Step 3: Plivo returns 400 Bad Request response synchronously.

Step 4: The customer displays an "invalid number" error to the user. 

Format correction for phone numbers

Plivo can intelligently reformat incorrectly formatted phone numbers. Here are two scenarios to illustrate how this works. 

Scenario 1: A user enters the Lithuanian number 370860112345. Plivo automatically reformats the number to the E.164 international format +37060112345 before forwarding the message to downstream carriers. Notice the 8 has been removed in the formatted number. This is because Plivo recognizes that 8 is required only when dialing a Lithuanian number from inside Lithuania.

Scenario 2: A user enters the Mexico number 520455512345678. Plivo automatically reformats the number to E.164 international format +5215512345678. Notice that 045 has been replaced with 1. This is because 045 is only to be used when dialing a domestic cell phone from a landline, and 521 is the prefix for mobile phone numbers in E.164 format.

Enabling Enhanced Destination Number Validation

•   All new Plivo customers have Enhanced Destination Number Validation for SMS enabled by default.
•   Existing customers can enable Enhanced Destination Number Validation for SMS from the SMS Settings page of the Plivo console. We recommend that all of our customers enable this feature.

Note: Because landlines in the US, Canada, and the UK can be enabled for SMS, Plivo will not reject SMS messages to landline numbers in these countries.

A2P and P2P are different processes for messaging. Which approach makes sense for a given use case depends upon the type and volume of traffic that is being sent.

A2P (application to person): An application acts as the sender. The application can send a large volume of messages in a given time frame. Use cases include bulk messaging, broadcasting, and alert systems.

P2P (person to person): A person acts as the sender. People are able to send only a small volume of messages in a given time frame. The traffic profile should resemble human behavior — it should be conversational (two-way) and at a frequency of no more than one message per second per number. 

P2P and A2P messaging in the US and Canada

The US and Canada regulate both P2P and A2P messaging. US and Canada long codes should be used only for two-way P2P messaging. Most carriers and mobile operators have spam filters to identify and potentially filter out A2P traffic that originates from long codes.

A2P messages in the US and Canada should be sent via short codes and toll-free numbers only. Plivo offers both short codes and SMS-enabled toll-free numbers for enterprise communication. Contact us with your specific needs for more information.

International destinations

Plivo works with most major international telecom operators directly or through partner direct connections that are sanctioned for A2P traffic. However, some countries may impose restrictions on message content, volume, and frequency. Reach out to your account executive to learn more about country-specific restrictions that may apply to your SMS traffic.

Many of our clients need to send messages in bulk to customers and prospects. SMS bulk messaging has been the subject to scrutiny in recent times because it can be used to send spam messages. Operators and regulatory bodies are sensitive to the number of messages that can be sent per minute from a given number. Limiting send rates, however, can have negative business impact in the form of reduced customer reach.

Plivo’s messaging platform solves this problem by delivering messages to downstream operators using smart queuing based on the type of source number used and the destination country. We maintain a dedicated queue for each of your source numbers. If you need to send messages using the Plivo SMS API to a specific destination country at a throughput greater than what's available from a single source number, you can increase your overall capacity by distributing your traffic across a pool of Plivo numbers to get the throughput you need while staying within the recommended per-number rate limits.

Do I need to contact you to get this feature enabled on my Plivo account?

No — smart queuing is enabled for Plivo accounts by default.

How do I determine the status of a message? Can I see whether it's queued or has been sent out?

When a message is in the queue, its status is set to "queued." The message is marked as "sent" once it has been passed on to downstream carrier networks. For more information about message statuses, visit our Message Object API reference documentation.

Are these the only rate limits that apply to my SMS traffic?

You can send SMS requests to Plivo at any rate you wish. All messages are put into the primary queue and dequeued based on the account-level messages per second rate configured for your account. Messages are then throttled for final delivery by our smart queue based on the source type and destination country.

Will the smart queue process messages in the order in which they were sent to Plivo?

Yes, messages are never processed out of order.

How are long (multipart) messages handled?

Multipart messages are enqueued, dequeued, and processed as a single entity at all times. The dequeue rate of a message is autoadjusted based on the size of the message to ensure that your traffic remains compliant regardless of the size of the message. For instance, if you send a two-part SMS message from a US source number, the message would be dequeued two seconds after the previous message in that source number’s queue.