In this video, you will learn how to deliver offers with the Decisions Hub API. Previously, we set up our placements, rules, tags, personalized offers, fallback offers, collections and decisions. The final step is to deliver these offers to customers. We’re going to do this by sending a delivery request using the Decisions Hub API.

In this video, we’re going to focus on the raw API request and use Postman for the demonstration. If you are the marketer who has configured the offers and decisions in the user interface, this video might not be for you. This is a technical video geared towards developers who integrate the API into whatever system needs to display the offer, such as a mobile app, website, email service provider, call center app, and so on.

For the purpose of this video, I’m going to assume that you are familiar with Postman and the Adobe API authentication. You need to have developer permissions, which can be set in the Adobe Admin Console. You will also need a project set up in the Adobe Developer Console with the experience platform, API. Since we’re doing non-production testing, we’ll use an access token that you can generate with Postman using the Adobe identity management service APIs. You can find more details in the tutorial on how to authenticate and access experience platform APIs. Hopping into Postman, I already have my environment configured. I highly suggest configuring yours before following along. I’ve added my private key and will add one additional variable for my Sandbox name which we’ll use in the API calls.

Now let’s start using the Decisions Hub API. First, we need to get our container ID, which is a key variable for future Decision Hub API calls. To do this, we can use a curl command that is available in the decision management API developer guide. Next, we just need to update the curly braces to double curly braces to read the environment variables correctly in Postman. Notice the Sandbox name header, which is why we updated our environment variables earlier.

When we make this call, we can get an instance ID in the response. We will use it as the container ID in future calls. So it’s a good idea to write this down somewhere. Next, let’s make a delivery request with the Decisions Hub API.

Again, we can use the sample curl command that is available in the decisions management API documentation. Be sure to update the curly braces to double curly braces so the environment variables are read correctly. There are a few things in this sample call that we need to update. First, is the container ID that is in the path of the request. If we make the call with the sample instance ID as it is now, we will get an error message saying that only a production sandbox is supported for this container. Let’s grab the instance ID that we retrieved earlier and replace it in this request. Then, let’s send the request again. Now we get another error message saying that the decision scope was not found. Looking at the body of their request, we can see the information about the error we are receiving. The combination of the placement ID and the offer decision ID is called the decision scope. You can pull the decision scope from the API or from the Adobe Journey Optimizer user interface. First, let’s jump into the interface and navigate to offers under the decision management section in the left navigation. Next, from the offer screen select the decisions tab. Select the decision name to open it, then find the placement you want to use and select copy followed by decision scope to copy it to your clipboard.

Hopping back to Postman, let’s replace the sample scope with the copied one. Before sending the request, remove the extra sample decision scope from here.

There are other customizable parts of the body, such as the customer ID or IDs and name space that you will need decisions for. Before sending the request, let’s also remove the sample merge policy ID that was copied from the example. Additionally, we can add the value dry run true here to enter a testing mode so our impressions won’t count towards any decisioning events, as well as any capping specified in the offers. These other options allow you to control what information the response will contain. More details are available in the guide on delivering offers through the Decisions Hub API.

Now that we have updated our request, let’s try sending it again. This time, we get a 200 response, as well as the fallback offer. So why did we get the fallback offer? Well, we just requested an offer using a random profile from the example. This identity isn’t one that exists in our instance, so it’s not surprising that it didn’t qualify for any of the personalized offers. To check that our personalized offers are working, we need to grab a new profile.

Note that this profile has the gold tier. So in our Decisions Hub API request, we’re expecting the offer that uses the gold tier rule. Let’s update our API body with the name, space, and ID of this profile.

After sending the call, we receive the gold gear offer. This tier gold detail is actually from the offer attributes that we’ve put in our offer. Offer attributes are used specifically to add additional details to the response. You can then take these details out of the response and use them in various ways, always a handy feature for developers. If you’re unsure what personalized offer was delivered, you can take the offer ID and look it up in the interface. Just open any personalized offer and paste the offer ID into the URL to find the offer that was in the API response. Just to recap, make sure you get your container ID before using the Decisions Hub API. Plug in your offer decisioning ID or activity ID, placement ID, customer ID, and identity name space to deliver the personalized offer. After watching this video, you should now be able to deliver offers using the Decisions Hub API and thanks for watching. -