...

The user-defined action hides some of the details of the Twilio API and presents a simple action that any rule can use to send an SMS. 

Actions and Functions

Unlike many programming languages, KRL rules make a syntactic distinction between operations that merely read state and those that change it. The KRL prelude is expected to not have an effect on state, either internal or external to the ruleset. This is more than stylistic, there are security and programming advantages to this segregation. Specifically, the action (and postlude) are conditional while the prelude declarations are made any time the rule is selected (based on the rule's event expression). Consequently, state changes made in the prelude that affect state are difficult to guard.

KRL itself takes pains to not permit state changing language features in the prelude, but a module developer could create functions that make state changes in the external API. In general, you should avoid this so that your module is easy for developers to use correctly and easily. In KRL rules, actions should generally be used for API requests done with a POST, PUT, or DEL since those requests change state in the API while GET requests should be used in functions. This ensures that operations in your API that affect external state can be guarded by the rule's conditional and any calls made in the prelude or event expression will not change state. Of course, how your module does this will depend a lot on how the API is built. 

A Module for Twilio

The previous section is not as useful as it could be because it requires that the account SID and authorization token be passed in each time. This is where KRL's parameterized modules come in handy. 

...