SUPPORT.TWILIO.COM END OF LIFE NOTICE: This site, support.twilio.com, is scheduled to go End of Life on February 27, 2024. All Twilio Support content has been migrated to help.twilio.com, where you can continue to find helpful Support articles, API docs, and Twilio blog content, and escalate your issues to our Support team. We encourage you to update your bookmarks and begin using the new site today for all your Twilio Support needs.

Swedish Short Code Best Practises

The following topics are discussed in this guide. Click a topic to skip directly to this information:

To apply for a Swedish Short Code, please follow the guidelines here.

Swedish Short Code Content Restrictions

See the table below for the type of content that is or is not allowed in Sweden.

Please refer to Twilio’s AUP for additional content restriction details. 

Type of Message Content Allowed  Not Allowed
Adult   (error)
Alerts (tick)  
Gambling / Casinos   (error)
Illegal products or services   (error)
Malware   (error)
Marketing (tick)  
Multilevel trading   (error)
Notifications (tick)  
OTP (tick)  
Political causes / politicians   (error)
Promotions (tick)  
Religious   (error)
Sensitive data (end user)   (error)
Sexual content (explicit)   (error)
Spam / phishing   (error)
Special offers (tick)  
Third-party rights violations (copyrights, registered trademarks)   (error)

Other Swedish Short Code Restrictions

 Type  Explanation
Time No restrictions (error)
Length No restrictions (error)
Content
  • TEST – When a message with the word TEST is sent to the service provider’s account, it shall generate a response from the relevant application. The message shall contain the word ”räksmörgås” in order to test the characters ”å; ä; ö” and thereby verify that the correct character table is installed. 
  • INFO –When a message with the word INFO is sent to the service provider’s account, it shall generate a response containing the account holder’s full company name, telephone number and e-mail address or URL.
  • STOPP – When a message with the word STOPP is sent to the service provider’s account it shall immediately stop all on-going services on the actual account (with regard to the relevant user). When a subscription service is stopped, the user shall receive a confirmation message informing of this. This also applies to non-premium services. STOPP shall in all marketing be spelled in Swedish, but STOP shall also be supported. Instructions for the general STOPP service shall be clearly presented in all marketing of services. 

NB! All the required content above must be managed and handled by the customer. Not complying with the content restrictions may, at any time, result in a short code withdrawal.

Opt-In Requirements

At the request of an Operator or ERB, the Aggregator shall ensure that a Content Provider must be able to present documentation that the recipients of SMS messages have actively consented to receive commercial messages or that the conditions exist for a so-called soft opt-in, ie the recipient is a customer or has been a customer in the past twelve (12) months.

Opt-out Requirements

Each SMS message sent for marketing purposes should clearly indicate how the recipient can easily unsubscribe from future content provider messages. 

Block list - An Aggregator shall, at the request of the Operator or on the recommendation of the ERB, after consultation between these parties, promptly block an individual Sender-id in their own systems. It is not enough for an Aggregator to request from another party that a Sender-id shall be blocked. 

Whitelist - Some Content Providers may be approved to use a Blacklisted Sender-id, therefore, a whitelist should exist where these Sender-id’s are selectively approved per Content Provider. The sender-ID is approved by the Operators. 

Blocking Phrases - Because Content Providers frequently change the Sender-id, an Aggregator should be able to block a phrase and / or a link that usually appears in messages. 

Operators reserve the right to block a Sender-id that has been abused or that is at risk of being abused. 

Opt-outs must be handled by the customer. Opt-in and Opt-out processes must be very well documented on the customer side in Terms and Conditions.

In case of any user complaints to carriers, we need to demonstrate that the Opt-Out process is documented and provide the evidence and also methods on how customers can opt out.

Please refer to Twilio's Acceptable Use Policy for further information.

Have more questions? Submit a request
Powered by Zendesk