Earlier in this month, Brad wrote a blog post on getting started with transactional emails in Bronto. Today I would like to follow up on that post and discuss the process for setting up transactional messages in your Bronto account.

Once transactional messaging in enabled for your account (after contacting client services), you can begin setting up transactional messages in the application. Let's take a look at the ways this is accomplished.

Passing In Message Content VIA The API

First, you need to create a message in the application. This message may contain field tags %%field%%, special tags %%!field%%, and/or API message tags %%#field%%. This message will act as a sort of template for the transactional email. The message should use a manage preferences link when asking the contact to opt in to marketing communication.

One thing to note, if you are using a message which you have previously sent out interactively via the application, or you wish to make a test delivery of the message prior to using it as a transactional message with the API, the system will assume you want to use the message as a bulk/marketing message and an unsubscribe link will be automatically appended. To remove this link prior to beginning to use the message for transactional deliveries, it is important to re-save the message in the application. Re-saving the message will remove any automatically appended links until the next delivery from inside the application.

API message tags are user defined tags that allow you to insert HTML content into the body of your message (not supported in subject lines) using the API. The content you add via API message tags will be added to your message at send time. These tags are useful if you want to sync content from your system (database, CRM, etc.) with messages you send in the application.

The syntax for creating an API message tag is %%#userdefined%%, where userdefined can be anything you want it to be. Check out

Setting Up An Automated Message Rule

An API type automated message rule will need to be set up next. The setup of this automated message rule is the same as for normal API triggered automated message rules. If you are using Legacy Version 3 of the API, you need to specify an API Handle in the Type Settings. The API Handle will be needed in the API call. For Version 4 of the API, you can reference an Automated Message Rule using the id assigned to the rule. To obtain an id for a given Automate Message Rule, call the readMessageRules function.

The setup of the automated message rule is the same as for normal API triggered email messages, except that the Enable Transactional Deliveries flag on the Advanced page must be checked. This tells the application that messages triggered via this rule may be sent to any contact regardless of status.  

You should make note of the sections called out in the screen shot below when you get to the Message Overview page for the transactional message.

Configure the API Call

Next, an API call must be made to ensure that the contact record exists in the application. The best method for this is to call the readContacts function using the email address as the filter criteria. This will return the contact if they exist in the application. If no data is returned, then the contact does not exist. The contact should then be added using the addContacts (writeContacts in Legacy Version 3) function with a status of transactional. A message can then be sent using the addDeliveries (writeDeliveries in Legacy Version 3) function.

If you have any questions, feel free to leave them in the comments section below.

Rob Slade
Bronto Client Services