ExactTarget Fuel offers a comprehensive set of APIs that enable you to automate your marketing campaigns and seamlessly integrate your marketing, analytics, and other business software. In this session, we'll provide an overview of Fuel's APIs with an emphasis on the latest and greatest additions to the REST API. We'll also highlight several examples of how to use these APIs to address core platform use cases such as automation and integration.
5. Track: Developers
#CNX14
APIs
POST https://www.exacttargetapis.com/address/v1/validateEmail
Authorization: Bearer gd2324hruukedkremtwqhae9
{
"email": "iamaspamtrap@spam.com",
"validators": [
"SyntaxValidator",
"GlobalUnsubValidator",
"ListDetectiveValidator"
]
}
HTTP/1.1 200 OK
{
"email": "iamaspamtrap@spam.com",
"valid": false,
"failedValidation": "ListDetectiveValidator"
}
• SOAP (since 2007)
• Oldest and comprehensive
• Programmatically exposes the
email application
• REST (since 2012)
• Newer & less comprehensive
• Multi-channel support
6. Track: Developers
#CNX14
SDKs
public class PrintAllLists {
public static void main(String[] args)
throws ETSdkException
{
ETClient client = new ETClient();
List<ETList> lists =
client.getAllLists();
for (ETList list : lists) {
System.out.println(list.getName());
}
}
}
• Native support for major
programming languages
and frameworks (Java, .NET,
PHP, Python, and Ruby)
• Greatly simplifies integration
with ExactTarget
• Faster time to market with
lower cost
• Bridges SOAP & REST APIs,
giving you easy access to all
capabilities
7. Track: Developers
#CNX14
SDKs
public class PrintAllLists {
public static void main(String[] args)
throws ETSdkException
{
ETClient client = new ETClient();
List<ETList> lists =
client.getAllLists();
for (ETList list : lists) {
System.out.println(list.getName());
}
}
}
• Native support for major
programming languages
and frameworks (Java, .NET,
PHP, Python, and Ruby)
• Greatly simplifies integration
with ExactTarget
• Faster time to market with
lower cost
• Bridges SOAP & REST APIs,
giving you easy access to all
capabilities
8. Track: Developers
#CNX14
SDKs
public class PrintAllLists {
public static void main(String args[]) {
PartnerAPI service = new PartnerAPI();
soap = service.getSoap();
Client client = ClientProxy.getClient(soap);
Endpoint endpoint = client.getEndpoint();
Map<String, Object> outProperties = new HashMap<String, Object>();
outProperties.put(WSHandlerConstants.ACTION, WSHandlerConstants.USERNAME_TOKEN);
outProperties.put(WSHandlerConstants.USER, username);
PasswordCallbackHandler callback = new PasswordCallbackHandler();
callback.setPassword(password);
outProperties.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
outProperties.put(WSHandlerConstants.PW_CALLBACK_REF, callback);
WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProperties);
endpoint.getOutInterceptors().add(wssOut);
endpoint.getOutInterceptors().add(new SAAJOutInterceptor());
endpoint.getInInterceptors().add(new LoggingInInterceptor());
endpoint.getOutInterceptors().add(new LoggingOutInterceptor());
RetrieveRequest retrieveRequest = new RetrieveRequest();
retrieveRequest.setObjectType("List");
retrieveRequest.getProperties().add("ListName");
RetrieveRequestMsg retrieveRequestMsg = new RetrieveRequestMsg();
retrieveRequestMsg.setRetrieveRequest(retrieveRequest);
RetrieveResponseMsg retrieveResponseMsg = soap.retrieve(retrieveRequestMsg);
for (APIObject apiObject : retrieveResponseMsg.getResults()) {
List l = (List) apiObject;
System.out.println(l.getListName());
}
}
}
• Native support for major
programming languages
and frameworks (Java, .NET,
PHP, Python, and Ruby)
• Greatly simplifies integration
with ExactTarget
• Faster time to market with
lower cost
• Bridges SOAP & REST APIs,
giving you easy access to all
capabilities
11. Track: Developers
#CNX14
Scenario:
Fitbit wants to drive installation of their
Mobile app for new users.
12. Track: Developers
#CNX14
Steps to Get There
1. Get Your Free Developer Account
2. Setup your Dev Environment
3. Import Data
4. Define Your Contact Model
5. Build Your Journey
33. Track: Developers
#CNX14
Thank you!
Recap:
1. Registered an Account
2. Setup your Dev Environment
3. Imported your Data
4. Defined Your Contact Model
5. Built Your Journey
34. Track: Developers
#CNX14
Questions?
Code From Today’s Session
https://github.com/sprshrp/connections14
Dev Portal, SDKs, Reference
http://code.exacttarget.com/developer-edition
AppCenter
https://appcenter.exacttarget.com/appcenter
35. Track: Developers
#CNX14
CUSTOMER JOURNEY
SHOWCASE
MARKETING
THOUGHT LEADERS
EMAIL MARKETING PRODUCT STRATEGY
& ROADMAP
PERSONAL
TRANSFORMATION
& GROWTH
SOCIAL MARKETING MOBILE & WEB
MARKETING
DEVELOPERS HANDS-ON
TRAINING
INDUSTRY
TRENDSETTERS
CREATIVITY &
INNOVATION
SALESFORCE FOR
MARKETERS
ROUNDTABLES
When you’re at Code@, make sure to Download an SDK in the flavor of your choice. You’ll also want to Register for an account on AppCenter.
In this section, we’ll walk through an example that leverages the APIs as well as the SDKs, to accomplish a real world scenario.
This scenario is an abbreviated example of the exercises in the Journey Builder for Apps book. You can pick up a free copy in the dev zone.
This Scenario should sound familiar, it’s the same use case described in yesterday’s keynote. We’re going to outline an example of how FitBit could use Journey Builder to
Drive Installation of their mobile app for new users.
First, we’d like to introduce something new for you, the developers. This week at connections, we’ve launched Developer Edition, which allows any developer to begin developing applications on the platform for FREE. Log in and break stuff, have a good time.
After you’ve Created your Developer and AppCenter accounts, you’re going to want to create your first application. This application will allow you to make API calls.
Make sure to select API Integration for Application Type.
And then Record your ClientID and Secret
You’ll use your clientId and clientSecret to configure the SDK, as well as to make API calls to the platform.
You can download the following examples on github at this URL. I’ll give you a moment to take a photo or punch in the URL.
Next, we’ll model your customer model into the Marketing Cloud Platform. Here, we’re defining a relational table, which we call a Data Extension.
DataExtensionName would be the name of your Customer Model
CustomerKey is an identifier you can use to refer to this table by,
IsSendable means this table will contain email addresses that you’d like to send email to, which are defined in SendableDataExtensionField and SendableSubscriberField, below.
After we configure the metadata of the Data Extension, we’ll define the columns. In this example, we’ll keep it simple: Email Address, Name and a flag to determine if the customer has installed the mobile app. Notice that we’re setting the EmailAddress as the primary key, which is required.
After we’ve defined our data extension, we’ll use the SDK to begin populating it with our Data. In thissimple example, we’re uploading our Customer’s names and email addresses, but this could easily grow to accommodate much more complex data.
Finally, we’ll use the SDK to create the emails we’ll be sending as part of our Drip campaign.
Customer Key is the Primary Key you can refer to the email by,
IsHTMLPaste refers to the type of email you’ve created. In this case, you simply populate the Email Body with the HTML body specified above.
Now that we’ve defined our data model, and imported it into the Marketing Cloud, we can now map our data to the Contact model. This mapping allows us to strongly enforce a 1:1 customer model, guaranteeing that you’re always sending data to customers in the right channel at the right time. Because this is an email-based journey, we’re mapping the Customer’s Contact Key to their email address.
Next, we’ll update the Channel Address Order, specifying that the email address in the Data Extension is also an available channel for communication.
After we’ve Extended the Contact Model, we’re ready to begin building our Customer Journey. We’ll start by Creating a Trigger – an entry-point into a customer Journey.
For this journey, we’re interested in driving mobile app installations. We’ll define our filter to only trigger if the flag on their account indicates that they haven’t installed our App yet. In this case, we’re starting the journey for both the case where we’re not sure , or if they’ve explicitly not installed the app.
After we’ve defined our filter, it’s time to build the Drip campaign on the Journey Builder Canvas. Here, if the Filter conditions are met, we’ll define 2 emails to be sent. The first is the welcome email, welcoming the customer to the platform, and encouraging them to download and install the mobile app. If after 3 days, the customer still hasn’t installed the application, we’ll send a second reminder email.
A key part of this journey is that we don’t want to message the customer if they’ve already installed the application. Journey Builder gives us a great tool to manage this evaluation, called the Decision Split. The decision split can be compared to an if-then statement – it evaluates a condition, and performs an action based upon that result. Here, we’re evaluating whether the user has installed the application.
A key part of this journey is that we don’t want to message the customer if they’ve already installed the application. Journey Builder gives us a great tool to manage this evaluation, called the Decision Split. The decision split can be compared to an if-then statement – it evaluates a condition, and performs an action based upon that result. Here, we’re evaluating whether the user has installed the application.
We’re almost complete. After Activating and saving the Journey, we’re now ready to begin guiding customers through it’s steps. In order to execute this Journey, we’ll need to invoke it via the API. To do so, we’ll need to know our Event Definition Key. We’ll use this key to indicate that a journey is ready to be evaluated, and potentially executed. You can access the Event Definition Key by clicking “Trigger Administration” on the Journey Builder dashboard.
The functionality to execute a Journey hasn’t yet made it to all the SDKs, so we’re going to use the REST API natively. Before we perform the REST API Call to execute our Journey, we’ll need to get an authorization token. If we were using the SDK, this would be handled for us. In this example, we POST our clientID and Secret to the requestToken endpoint, and it will return an accessToken, valid for an hour. Please note that you’ll only need to retrieve this token if it has expired, it’s not necessary to retrieve a fresh token before each call.
Armed with our EventDefinitionKey, and our Auth Token, we can now execute the Journey. We POST a call to the events endpoint, indicating which user we’d like to evaluate the journey for. In this case
We specify both the ContactKey which we mapped earlier, and the email address for the customer. In this case, these happen to be identical. After the call is made, Journey Builder will evalute
The filter we defined, and if the criteria are met, will initiate the customer’s journey. The welcome email will be sent, encouraging the customer to install the mobile app. 3 days later, if the customer
Still hasn’t installed the app, a second attempt will be made.
That’s it, thanks for participating! To recap, Using the SOAP and REST APIs, as well as our SDKs, we helped drive a journey to encourage new Fitbit users to download their mobile application. We…
1-5
It’s not difficult to imagine extending that journey, or building new journeys such as the ones we saw at yesterday’s Keynote.
I know that was a whirlwind. This presentation was built very to complement the Journey Builder for Apps book, which we’re giving away for free at the Dev Zone. Please feel free to drop by and pick up your copy. And with that, let’s open up the floor to questions:
Data Contract:
URI
HTTP Verbs, Response Codes
Request Parameters
Request / Response Body Definitions
Data Contract:
URI
HTTP Verbs, Response Codes
Request Parameters
Request / Response Body Definitions
Goals of the client libraries
Write less code
Make it possible to accomplish advanced use cases (the “20%”)
Expose the same objects and properties…
… but do so in a way that feels “native” to the language or environment being used
Java, PHP, C# libraries officially supported
Expect
Feature Parity Across all Libraries
Auto-generation based on our API Discovery Service
We’re currently developing an API Style Guide, which we will publish on Code@, to ensure Consistency across our RESTFul Interfaces
Will define
* common parameter names (e.g. created and modifiedDate),
custom interactions (e.g. related object hydration, pagination, asynchronous activities)
Goal : developers can predictably interact with the API with less frequent trips to the documentation