Marketing Cloud Engagement offers two methods of sending messages that are triggered when a customer performs an action. The first method is to send triggered messages by using triggered send operations in SOAP API or the messageDefinitionSends resource in REST API. The second method is to use the more modern transactional messaging API, which offers several performance and feature benefits. It’s important to understand the differences between these methods so that you can choose the best option for your use case.
Classic triggered sends only support email messages. However, you can use the transactional messaging API to send email, SMS, and push notifications.
This table summarizes the API-related differences between transactional messaging API and classic triggered sends.
| Feature | Classic Triggered Sends | Transactional Messaging API |
|---|---|---|
| True RESTful operation of API resources | No | Yes |
| Consistent syntax across channels (email, SMS, and push) | No | Yes |
| Consistent resource URL structure across channels | No | Yes |
Unique messageKey required for all requests | No | Yes |
| Method of controlling object access | Client.ID property within the request body | Authentication token context |
With classic triggered sends, you can monitor message-related notifications on the Tracking tab in Email Studio. For each triggered send, you can see aggregate information about sends, deliveries, opens, clicks, and unsubscribes.
With the transactional messaging API, you can retrieve transactional messaging data in real-time using the Event Notification Service (ENS). You can also use ENS to retrieve notifications when failures occur at the service layer or the outbound message management layer. Finally, you can use ENS data to create dashboards that are updated in real-time.
The Transactional Messaging API processes end-to-end message queues faster than classic triggered sends.
With classic triggered sends, you can specify the prioritization of messages. In the transactional messaging API, all messages are handled with equal priority, so specifying the message priority isn’t necessary.
Finally, you can configure throttling rules for classic triggered sends. With these rules, you can specify granular limits for sending triggered emails, such as a limit of 10,000 messages per hour. The transactional messaging API doesn’t support this feature. Instead, the transactional messaging API adds each message to a queue and delivers it as quickly as possible.
You can use Email Studio to manage classic triggered sends, and Journey Builder to manage messages sent using the transactional messaging API.
With classic triggered sends, you use the EmailSendDefinition resource in SOAP API to manage send definitions. The transactional messaging API uses the messaging/v1/email/definitions endpoint in REST API to manage send definitions.
When you modify a send definition for a classic triggered send, you must publish the changes for them to go live. You can publish changes in Email Studio or via the API. The transactional messaging API automatically applies changes to a send definition.
Finally, send definitions for classic triggered sends can specify a data extension for logging send events. With the transactional messaging API, you use ENS to monitor events including message sends. Because ENS emits send event data in real-time, you can quickly and programmatically respond to message send failures.
j
