Search Results

System Requirements

Getting Started

Before getting started with Aerialink, your system must be capable of supporting the following elements for the program types appropriate to you. To ensure that you have identified your program type correctly, please review the definitions below:

One-Time Program: Also referred to as a “query” or “transactional” service, end-users text this program to receive the desired response a single time, and will receive no additional contact from that service unless they text in to engage the service again.
Recurring Program: Also known as a “subscription-based” service, end-users who opt into recurring programs will receive messages at regular or event-triggered intervals over a given period of time without additional end-user interaction or prompting required.

The following is a series of brief articles describing what your system will need to support in order to run a compliant program. For more information about compliance, please check out the related pages links, or free-browse our Compliance section.


There are two clear types of keywords at work in your mobile program. Required Keywords, such as HELP and STOP, are required to function in one specific way. Program keywords can be used to create message responses unique to your program. Here are some rules to keep in mind about how program keywords function:

Campaign Keywords

Campaign keywords are chosen by the content provider to trigger desired responses such as opting an end-user in or prompting a portion of the service. Here are some things to keep in mind about Campaign Keywords:

  • Must be be between three and fifty characters long
  • Must consist of letters and numbers only
  • Must begin with a letter
  • Cannot be case-sensitive (Join, JOIN and join elicit the same response)
  • Cannot be duplicated on the same short code
  • Cannot be required keywords such as HELP and STOP

Required Keywords

  • HELP
  • AIDE*
  • INFO*
  • STOP
  • ARRET*
  • END
  • QUIT

* Required for Canadian campaigns.


“HELP” must be advertised as the keyword-driven means to obtain more information and must be supported on all mobile programs.

  • HELP should return a response regardless of whether the end-user is presently or was ever opted into the program.
  • HELP must work in the native language of the program.
  • Non-English programs must not return an error message to the English keyword.
  • AIDE is the French version of HELP and is required as an accepted support keyword for all programs running in Canada.


“STOP” is the keyword required in all advertising and messaging, but its synonymous keywords–END, QUIT, CANCEL, UNSUBSCRIBE and ARRET (the French “STOP” keyword)–must also be live, functional, return the same response as “STOP” in the keyword’s native language and successfully opt the end-user out of the mobile program.

Some other things to consider about the STOP keyword are:

  • STOP should return a response to all users - even those who never opted into the program.
  • STOP must work in the native language of the program.
  • Non-English programs must not return an error message to the English keyword.
  • ARRET is the French version of STOP and is required as an accepted opt-out keyword for all programs running in Canada.
  • Short code programs must ignore subsequent non-keyword text included in STOP requests. (e.g., an MO containing the words “please stop” should see the “stop” and complete the STOP process regardless of the presence of the non-keyword text.)
  • The opt-out process cannot contain a menu. End-users who are opted into multiple programs at the time they send STOP must be opted out of all programs on the code.

The following keywords are “reserved.” While they are not technically required keywords such as “stop,” they are disallowed from use by Aerialink customers in the following applicable groups.

  • LINK

The LINK keyword is reserved across all Aerialink codes both shared and dedicated for Aerialink system use


Subscription Database

The FCC TCPA requires that a mobile end-user give “prior written express consent” before being opted into a mobile service to receive marketing messages. This message transaction creates a time-stamped proof of opt-in, leaving no space for dispute that the customer asked to receive the content being sent to them. According to the same act, every program must allow the customer to opt-out if desired. If a customer opts-out, that transaction is also recorded with a time stamp as proof of opt-out. This simple process is a clean, trusted system for maintaining a compliant subscription database. Your system must maintain this database.

Double Opt-in

An optional double opt-in requires users who opt into a mobile program via a non-SMS-initiated method to verify their mobile number by responding to a confirmation request SMS with “YES” or a PIN number in order to confirm their subscription. While double opt-ins are no longer required they are recommended as a campaign best-practice for any mobile program with non-SMS-initiated opt-ins.

One-Time “Opt-Ins”

One-time programs are not required to formally “opt in” users or maintain a subscription database. However, one-time programs also cannot use the contacts collected in this manner for marketing purposes.


A subscriber must be able to cease participation with any program at any time. Please reference the “Required Keywords” above for the mandatory methods of opt-out you must support.

Message Flow

The most important thing to note when creating or revising your message flow is that in order for it to pass certification, the live messages which your system pushes out must identically match the messages detailed in your registration submission (10DLC, Verified Sender or short code certification). Therefore, you must ensure that your messaging application supports the logic required for compliant message flow, so that when carriers test your mobile program with live devices, they will receive the expected results documented in your program summary.

URL Encoding

Standard URL Encoding practices should be used in constructing the URL call to Aerialink which will ensure any non-ASCII characters are URL-encoded with their proper replacement value.

Data Coding Scheme

We recommend that you leave your DCS value set to 0. In the United States, avoid the use of unicode (UTF) in text messages, as it is not widely or reliably supported by domestic carriers. For more information, please see our articles on Encoding & Character Sets and Data Coding Scheme values.

Retry Mechanism in External Applications

Customers connecting to Aerialink HTTPS REST API require the support of an application retry mechanism. A programmatic retry mechanism helps an application recover and continue functioning correctly after unexpected failures.

Throttling Controls in External Applications

Customers connecting to Aerialink require the support of application throttling for outbound delivery. Throttling allows you to limit the number of messages/submits that can be sent to our network, either to a particular endpoint for REST API or system ID for SMPP, maximizing user outreach without taking unnecessary risks. External application throttling protects our network and upstream networks from being overwhelmed by accepting and delivering messages. Aerialink’s sophisticated gateway queue management solution and the message throttling limit for external applications enable our network to process the messages in an orderly manner. Please check with your Account Director for specific rate limits.