- Core functionality with Email, Tracking
SOAP API and Data Extensions
- Most comprehensive API functionality
- New functionality with Mobile, Journey
Builder, and Content Builder
REST API
- Selective support for core functionality including
Email and Data Extensions
SOAP API for Available via the TriggeredSend object using the
transactional message Create method
REST API for transactional Route for sending: /messageDefinitionSends
messaget
- Available via the TriggeredSend object
AMPScript for
using the InvokeCreate function
transactional
- Used for landing pages on the Marketing Cloud
message
Components of a Definition + API Request
triggered send
In the UI under Email Studio > Interactions >
Where is the Triggered Emails
triggered send
definition? or via API (uncommon)
, - Provides common data for sending:
- Form Details
- Email Template
- Subscriber Management
What does the
triggered send
- Differentiates sends for tracking purposes
definition do?
- Allow for pausing/queuing messages (can
pause triggered send, update email and
then resume)
Fields:
- Name
- Key Identifier (CustomerKey = ExternalKey)
- Classification
Creating a Triggered - Email
Send Definition - List for Subscriber Management
- Misc Options
- CC/BCC
- Multipart MIME
- Send Loggins
- Create new definition for unique send types
- Password reset versus Receipt
- Make sure you start your definition
Triggered Send Def best
practices - Publish anytime you make changes
- Pause + Start != Publish
- Always select a list under subscriber management
- Provides better visibility into subscriber status
SOAP/REST API - SOAP API
which supports
username and - Also supports OATH for a short-lived token
password?
, Web Apps make API requests in the context of
an end user. These integrations are issued a
Web App
client ID and client secret because they can
maintain the
confidentiality of a client secret.
Public Apps, such as single-page or mobile
applications, make API requests in the
Public App context of an end user. These integrations are
issued only a client ID because they cannot
maintain the confidentiality of a
client secret.
A server-to-server integration performs tasks
on behalf of the integration, without an end-
user context, user interaction, or user
Server-Server interface.They make API requests in the context
of a service account instead of a user account.
These integrations are issued a client ID and
client secret to use with the Client Credentials
grant type.
In the client credentials flow, your client
application uses this client ID and client secret
to request an access token from the
Access Tokens for
Marketing Cloud authorization server. The
Server- to-Server
access token gives your application access to
Integrations
Marketing Cloud's REST and SOAP services.
(The client credentials grant type doesn't have
refresh
tokens.)
1.Your application requests an access token
by providing the client ID and secret that was
generated for the package you created in
Access Tokens for
Marketing Cloud.
Server- to-Server
2.The Marketing Cloud authorization server
Integrations- how it
returns an access token for your application
works
to extract.
3.Your application uses the access token to
access Marketing Cloud resources and the
REST or SOAP base URLs returned as part