Message Senders

Message Senders is a feature that helps to deliver event-driven notifications to users based on certain key commerce activities. OrderCloud defines the activities, which could be things like order submitted, order shipped, forgot password, etc. and leaves it open to you to decide the presentation and notification format such as email, text, or perhaps something else completely.

Message Senders vs Webhooks

Webhooks are another OrderCloud feature that are event-driven and could conceivably be used to drive notifications, but webhooks are much less suited than message senders for this task. For example consider trying to build a notification to all users who are able to approve a newly submitted order. To accomplish this with webhooks you would need write code to cover the following steps:

1. Build a handler to receive the submit for your approval webhook

2. Take the high level order information and query the API for the rest of the needed order data

3. Query the API for all of the possible approving users (which can be complex)

4. Look up approving users' contact information

5. Send each message

In contrast, an OrderSubmittedForYourApproval message sender will retrieve all of the relevant information for you and send a single web request for each approver message that should be sent. This enables you to write a single, simple handler whose sole responsibility is to format the message and send it via email, text, or whichever other format you desire.

Message Sender Types

The message sender types below outline all of the different commerce activities that can trigger a notification via message senders. If you're not seeing an activity that you would expect, please reach out to us and we will consider adding it.

Configuration Options

Before you can start sending messages you'll need to decide which approach you want to take to to implement message senders. There are three different configuration options ranging from least to most control. Please read the following sections for more detail.

Default Sender

This is our no code option. It sends emails with our own Mandrill account as well as with our own templates. There is nearly no setup to get going but it also means there is no control over the email templates or the data that is sent.

To enable this option:

1. Create a message sender in the portal and select "Default Sender"

2. Give it a name

3. For each template optionally define the "Message Subject". "Message From Email" can not be customized on default senders

4. Assign the message sender to the relevant parties OR use AllowAllBuyers if you don't need explicit assignments

Custom Mandrill Account

This is our low code option that gives you a bit more control - you are able to provide your own custom email templates but the actual sending of the emails is handled by OrderCloud. This option requires that you have your own Mandrill/Mailchimp account.

To enable this option:

1. Create each of your email templates in Mandrill. Refer to this table to determine which variables are available to render in your email template.

2. Create a message sender in the portal and select "Custom Mandrill Account"

3. Give it a name

4. Provide your Mandrill API Key

5. Select which message types you want to enable. For each message type provide your Mandrill Template Name. Check out our default templates to use as a starting point.

6. Assign the message sender to the relevant parties

Custom URL

In this option you provide OrderCloud the URL to your publicly available endpoint that will receive the event payload and is responsible for formatting as well as sending the notification. As you can imagine this grants you the most amount of control but it also requires more work on your end to accomplish. Here are a few reasons you may decide to go down this path:

1. You want to use a different messaging provider than Mandrill

2. You want to send more than just emails such as texts or maybe something else entirely

3. You need your notifications to include data that isn't available in the normal event payload

4. You need to add some additional business-specific decisioning logic when sending an email

To enable this option:

1. Create and host a custom endpoint to receive and process the event payload

2. Create a message sender in the portal and select "Custom URL"

3. Give it a name

4. Provide the URL to your custom endpoint from step 1.

5. Select which message types you want to enable - any message type you select should be handled by your custom endpoint

6. Assign the message sender to the relevant parties

Of course creating the custom endpoint is going to be the most laborious part of implementing this option. To help you out we've created a .NET starter project that demonstrates how to handles these types of events and has examples for sending notifications from Mandrill, Sendgrid, and Twilio. Check out the payload models for each message type.

Here are a few other things to keep in mind as you're building your endpoint:

• We highly recommend validating every incoming request to ensure it is coming from a legitimate source. Similar to validating request for webhooks you can do the same with message senders and should verify that the x-oc-hash header matches the value of raw request body hashed by the SharedKey on the Message Sender. If it doesn't match, then you have an unverified sender of that web request.

• Use the special variable {messagetype} in the custom URL provided to OrderCloud. This lets you define a single message sender configuration that can handle different message types. For example the custom url https://my-message-handler/{messagetype} that has opted in for an OrderSubmitted and ForgottenPassword message type will receive requests to the endpoint https://my-message-handler/ordersubmitted as well as https://my-message-handler/forgottenpassword.

• If your handler needs elevated permissions to complete its work you may consider defining ElevatedRoles this will grant your endpoint a token for the recipient user that additionally has any elevated roles defined. This can help simplify your logic especially if your handler is a one-off serverless function for example.

• Like most other entities in OrderCloud, Message Senders come with extended properties which you can use to store business specific data to drive custom behavior. Please note that xp will come through as ConfigData in the event payload.

• Check out our default templates to use as a starting point.

Custom Email Templates - Mandrill Merge Vars

If you're using our Mandrill/Mailchimp integration and providing your own custom email templates then you can use these tables to determine which variables are available for you to render in your email templates.

Variables for ForgottenPassword and NewUserInvitation

Variables for Order Emails

Variables for OrderReturn

Includes all of the variables for order emails and additionally the following:

Variables for ShipmentCreated

Includes all of the variables for order emails and additionally the following:

Variables for OneTimePassword

Message Sender Event Payload models

If you are building a custom message sender it is necessary to understand what kind of payloads your endpoint handler will receive. The first table lists properties common to all message types. The tables below that one are the event payloads specific to each message type.

Generic Payload (not event specific)

Event Body for ForgottenPassword and NewUserInvitation

Event Body for Order Events

Event Body for OrderReturn Events

EventBody for ShipmentCreated

Event Body for One-Time Passwords

Conclusion

You should now have a good understanding of what message senders are, how they differ from webhooks, and the different implementation options at your disposal

Still have questions?
Ask in our Community Channel

Content Powered By