Published by Crhistian Ramirez
April 8th, 2022
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.
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.
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.
Note: A user must be active in order to receive a message. This means that user Active=true
but also that buyer Active=true
for the buyer organization they belong to or supplier Active=true
for the supplier organization they belong to
Message Type | Description |
NewUserInvitation | Notify the buyer user when an admin user creates them or when they self register |
ForgottenPassword | Notify the user when they initiate a password reset request |
OrderSubmitted | Notify the buyer user when they submit an order |
OrderSubmittedForApproval | Notify the buyer user when their order has been submitted, but has been placed on hold pending approval |
OrderApproved | Notify the buyer user when the order that was previously on hold, has been approved and released to fulfillment |
OrderDeclined | Notify the buyer user when the order that was previously on hold, has been declined and will not be fulfilled |
OrderSubmittedForYourApproval | Notify approving users that there is a new order pending their approval |
OrderSubmittedForYourApprovalHasBeenApproved | Notify approving users that an order that was previously on hold pending their approval has been approved |
OrderSubmittedForYourApprovalHasBeenDeclined | Notify approving users that an order that was previously on hold pending their approval has been declined |
ShipmentCreated | Notify the buyer user when a shipment was made for their order. Please note triggering this requires a very specific order of operations. First, the shipment must be created with a ShippedDate set to null , then the relevant shipment items should be added to the shipment, and finally the shipment should be patched with a ShippedDate |
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.
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:
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:
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:
To enable this option:
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.
Here are a few other things to keep in mind as you're building your endpoint:
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.{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
.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.ConfigData
in the event payload. 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.
Mandrill Variable | OrderCloud Property |
username | Username |
passwordtoken | passwordtoken |
passwordverification | passwordverificationcode |
passwordrenewalurl | passwordrenewalurl |
Mandrill Variable | OrderCloud Property | ||||||||||||||||||||||||||
firstname | Order.FromUser.FirstName | ||||||||||||||||||||||||||
lastname | Order.FromUser.LastName | ||||||||||||||||||||||||||
orderid | Order.ID | ||||||||||||||||||||||||||
datesubmitted | Order.DateSubmitted | ||||||||||||||||||||||||||
subtotal | Order.Subtotal | ||||||||||||||||||||||||||
tax | Order.TaxCost | ||||||||||||||||||||||||||
shipping | Order.ShippingCost | ||||||||||||||||||||||||||
total | Order.Total | ||||||||||||||||||||||||||
lineitemcount | Order.LineItemCount | ||||||||||||||||||||||||||
products (array) |
| ||||||||||||||||||||||||||
approvals (array) |
| ||||||||||||||||||||||||||
orderxp (array) |
|
Includes all of the variables for order emails and additionally the following:
Mandrill Variable | OrderCloud Property | ||||||||||||
shipmentid | Shipment.ID | ||||||||||||
shipmenttrackingnumber | Shipment.TrackingNumber | ||||||||||||
shipper | Shipment.Shipper | ||||||||||||
dateshipped | Shipment.DateShipped | ||||||||||||
toaddressid | Shipment.ToAddress.ID | ||||||||||||
toaddresscompany | Shipment.ToAddress.Company | ||||||||||||
toaddressfirstname | Shipment.ToAddress.FirstName | ||||||||||||
toaddresslastname | Shipment.ToAddress.LastName | ||||||||||||
toaddressstreet1 | Shipment.ToAddress.Street1 | ||||||||||||
toaddressstreet2 | Shipment.ToAddress.Street2 | ||||||||||||
toaddresscity | Shipment.ToAddress.City | ||||||||||||
toaddressstate | Shipment.ToAddress.State | ||||||||||||
toaddresspostalcode | Shipment.ToAddress.PostalCode | ||||||||||||
toaddresscountry | Shipment.ToAddress.Country | ||||||||||||
toaddressname | Shipment.ToAddress.AddressName | ||||||||||||
shipmentitems(array) |
|
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.
Property | Description |
OcLogIdHeader | Internal log id |
Environment | Maps to one of OrderCloud's environments. Can be either Sandbox, Staging, or Production |
BuyerID | ID of the buyer organization the user belongs to (if user is a buyer) |
UserToken | Token of the recipient user, if ElevatedRoles is defined then the token will include those additional roles as well |
Recipient | The full user object of the recipient user |
CCList | The list of additional emails that will be CC'd for this message |
EventBody | The specific event body for that message type (see below for each message type) |
MessageType | The message type that this event was triggered for. Can be one of: NewUserInvitation, ForgottenPassword, OrderSubmitted, OrderSubmittedForApproval, OrderApproved, OrderDeclined, OrderSubmittedForYourApproval, OrderSubmittedForYourApprovalHasBeenApproved, OrderSubmittedForYourApprovalHasBeenDeclined, ShipmentCreated |
ConfigData | This maps directly to any extended properties defined on the message sender |
Property | Description |
Username | The username of the user submitting the request |
PasswordRenewalUrl | The URL passed in the original request |
PasswordRenewalVerificationCode | The verification code to be passed when resetting by verification code |
PasswordRenewalAccessToken | The token of the user with only the role `PasswordReset` encoded. Used when resetting password by token |
Property | Description |
Order | The order that was submitted |
Approvals | The array of order approvals for the order |
LineItems | The array of line items for the orders |
Products | The array of products for the order |
Property | Description |
Order | The order that was submitted |
Approvals | The array of order approvals for the order |
LineItems | The array of line items for the orders |
Products | The array of products for the order |
Shipment | The shipment for the order |
ShipmentItems | The array of shipment items for the shipment |
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