Keyword Processing Rules

These are the current rules for keyword processing on MOs. The purpose of keyword processing is to examine an incoming MO, determine what account it is related to and institute correct processing. Processing may include OptIn/OptOut processing.  OptIn/OptOut processing is based upon the keyword so correct isolation of the keyword is necessary to get that right. Once the keyword is isolated, the correct routing is looked up and the keyword is passed to the application. The remainder of the message after the keyword is passed to the application as parameters.

In the steps below, if any assigned keyword is detected, keyword processing stops and all remaining steps are skipped. Keep this hierarchical structure in mind when reading the rules. Earlier rules override later rules. If you are at rule x, all rule application attempts above x have failed. Case is ignored in all keyword processing. The notation RE= is the match pattern in standard regular expression syntax.

Block Keywords are multi-character in their definition and end in a *. The Global Block Keyword consists of the single character,  *. The * is never entered by the user! It appears only as part if the definition. Block Keywords are really simple regular expressions. Block Keywords may contain letters and numbers but may not contain the characters, +$^/&\[]{}%()?|, and . The character * may appear but only once and it must be the last character. If * does not appear in the keyword definition, it is not a Block Keyword.

Keyword Processing Steps

  1. Look for a +1 at the beginning of the message. If one is found, strip out all information up to and including the first space. This is necessary to get rid of the number prefix that Nextel pre-pends to the message.
    1. Ignoring leading spaces, look for a string of either alphabetic characters or numeric characters (RE= ^\s*([a-z]+)|([0-9]+)). The string ends with any non-alphabetic or when the initial character domain switches from alphabetic to numeric or vice versa. If the keyword is invalid on all counts, it is set to .(period).  An invalid keyword occurs is the first character after any white space is neither alphabetic nor numeric.
  2. Regardless of the keyword found above, a check is performed to determine if the incoming number is a member of a Top Slice Virtual Dedicated Short Code(TSVDSC). If so, any keyword found in the previous step is replaced by the keyword for the TSVDSC that the incoming number is a member of.
  3. At this point, the isolated keyword is looked up in the ShortCodeRouting table. If found, success is declared and processing continues. If it is not found and if the keyword is alphabetic and ends in an s, strip the s and attempt to find a keyword for the singular form. If one is found AND the Allow Plurals option is set, declare the singular form the keyword. Examples:
    1. Message=mickeys abc. Keyword=mickey. Parameter string=s abc. This assumes that keyword mickey has the Allow Plurals option set.
    2. Message=dogs abc. This assumes that keyword dog does not have the Allow Plurals option set. Failure: Keyword processing continues at the next step.
  4. If the isolated keyword is found in the routing tables, success is declared. Examples:
    1. Message=fred abc. Keyword=Fred. Parameter string=abc.
    2. Message=fred2 abc. Keyword=Fred. Parameter string=2 abc.
    3. Message=345 joe. Keyword=345. Parameter string=joe
    4. Message=678x bill. Keyword=678. Parameter string=x bill
  5. Look for one of the help, OptIn or quit reserved words. The reserved words are: yes, help, stop, end, quit, canceland unsubscribe.  If found, these words will alter the processing at a later step but they will not be defined as a keyword even if they are the only thing in the message. NOTE: This action is performed whether or not a valid keyword has been found above!
  6. If success not achieved so far, check if there is a Global Block Keyword defined for this short code. If so, declare success and route.  Examples:
    1. Message=8* bx 4567. Keyword=*. Parameter string=8* bx 4567.
    2. Message=this system rocks. Keyword=*. Parameter string=this system rocks
  7. Look for a Block Keyword. Get a list of all Block Keywords for this short code, strip the * and look for the longest match. For all Block Keyword forms, parsing into parameters and keywords is not possible for the switch. The entire message will be passed to the application as a parameter.  In the examples below, assume that there are 2 Block Keywords on this shortcode, 10* and 101* for applications A and B respectively.
    1. Message=105abc. Keyword=10*. Parameter string=105abc. Route to application A.
    2. Message=1015def. Keyword=101*. Parameter string=1015def. Route to application B.
  8. Look for a sticky response. A sticky response is one in which the keyword is assumed to be the same one as for a recent MT. A sticky response will have a keyword inserted into the message even though the user did not enter it. Sticky processing is by definition an assumption. Sometimes assumptions work and sometimes they don’t. Applications must assume the risks that a faulty assumption will occasionally occur. A sticky response will be assumed if:
    1. There is no recognizable keyword on the MO.
    2. The last MT sent to this user was no more than 30 minutes prior to the MO we are analyzing.
    3. That last MT sent to this user was related to an opted in keyword.
    4. That keyword allows sticky processing.
  9. Look for a Bottom Slice Virtual Dedicated Short Code(BSVDSC). If one is found, set the keyword to the one for that BSVDSC.

Keyword Syntax Summary

Keyword definitions consist of five forms.

  1. *  This is the Global Block Keyword.
  2. Alphabetic Word E.g. dog, cat, joe, mls, etc. Plural words can optionally be converted to the singular form.
  3. Number. 456, 765, 3456, etc.
  4. Block Keyword. E.g. GM*, 10*, r*

An alphabetic keyword may not be one of the reserved words. A Block Keyword may not start out as any reserved word. A keyword MAY NOT consist of both letters and numbers! Applications may not use any of the reserved words as parameters! Note that the * when it appears is NEVER entered by a user! It exists only in the definition!

Alphabetic Word, Number and Block Keywords may all exist together on the same short code. There is no limit to the number of such keywords on a short code. When Block Keywords are involved however, the greater the number, the greater is the exhaustion of the keyword space and the greater the potential for conflict.

Keyword Interactions

When using Block Keywords or sticky keywords, the interactions, which may be very complex, are extremely important to understand! With sticky processing, the parameter strings used by applications may possibly be interpreted as keywords leading to erroneous results. With Block Keywords, parts of one keyword may conflict with another. The best way to discuss adverse interactions is to give examples.




Customer A wants his keywords to be anything that starts with go. You set a Block Keyword as go*. Customer A gets all 479 words in the English language starting with go as well as all non-words like, goToClean, goToDine, goToHouses, etc.

Some time later, Customer B says he wants the keyword go. You have sort of forgotten by now about Customer A. You set a keyword for Customer B of go.

Result. Customer B now gets calls to keyword go. Customer A, who used to get calls to keyword go, no longer does. The reason is that processing of alphabetic keywords is higher on the scale than Block Keywords and the go is stripped out first.  Keywords like goes, goToDine, etc. are still routed to Customer B.


Customer A has block keyword r*. Later customer B asks for Block Keyword re*. The result is that all MOs starting with re now go to Customer B and no longer go to Customer A. The reason is that the match length of re is greater than r.


Customer A has keyword ml with the Allow Plural Form option. Customer A gets MOs for both ml and mls. Customer B later asks for mls. Customer B gets calls to mls and Customer A no longer does. The reason is that exact matching occurs before plural checking.


Customer A wants the keyword stop*. They want to use it as a front for phrases like stopBugs, stopCrime, stopDrugs, stop2Buy etc. They also want to be able to accept stop bugs, stop crime, stop drugs and stop 2 buy. They will get MOs that have no space or no number after the stop in the message but they will not get any calls on MOs that have a space or number after the stop. The reason is that stop is a reserved word and any appearance of the word stop leading a message will be interpreted as an OptOut request.


Customer A wants keyword HouseHelp. If the keyword is entered exactly as HouseHelp, they get the call but House Help will fail, as there is no keyword there for House. This also conflicts with the reserved word help.


Customer A wants to use keywords yes2Sales, yes2Profits. None of these keywords will work because they conflict with the yes reserved word used for OptIn. Reserved word extraction happens earlier in the tree.


Customer A wants the Block Keyword +12*. That cannot have it because it will not work.  The reason is that this keyword conflicts with the pre-pended number on Nextel MOs. It will be stripped off and lost before keyword matching ever begins.


Customer A has sticky processing on their keyword def. The application for Customer A expects a parameter with a value of xyz. Customer B uses keyword xyz. A message of form xyz 123 is received. This MO goes to Customer B, even though Customer A has sticky processing and is the actual intended destination by the user. The only solution to this is to move Customer A and Customer B to different short codes.


Customer A wants sticky responses on his keywords but does not want to use OptIn and is not subject to it. Customer A cannot use sticky responses since they work only with OptIn keywords.


Customer A is subscribed to a service with keyword abc. Customer A is also subscribed to a BSVDSC and wishes to use both simultaneously.  As long as Customer A does not try to send anything to his BSVDSC starting with abc, there is no problem. Customer A can force anything into his BSVDSC by simply pre-pending a . to his send. Since keywords cannot start with a non-alphabetic or non-numeric, pre-pending the message with a . guarantees that all keyword processing ahead of the BSVDSC will fail, ensuring that the BSVDSC will grab it. Any other special character will have the same effect. However, the . is unobtrusive and is easily entered by hitting 1 on the numeric keypad of most phones.


Customer A is subscribed to a TSVDSC. Nothing that Customer A enters can cause the TSVDSC to miss the message. Customer A cannot use any other services on the short code.


Have more questions? Submit a request