top of page
Search
  • Writer's pictureAnkit Bajpai

Marketing Cloud API Testing and Postman Automation

A few months ago I was struggling to find an easier way to test the Real time Email and SMS sends through the out of the box Rest end points available from Salesforce Marketing Cloud. I had Journey Builder Sends, Triggered Sends and Transactional sends built and configured for sending Emails and SMS in real-time through a third party application via a REST API calls.


While I was able to find all relevant documentations on the help website to develop these components in SFMC, it was painstakingly difficult to test each API multiple times which belonged to different Business Units each having their own access tokens for Authorizations. Factor in multi country language variations and 50 odd different types of Emails in the mix and you have will end up with hundreds of unique API calls to fire and a headache trying to accomplish this task.


I wondered if there would be an easier way to achieve this avoiding all manual updates to the API payloads (and manual errors of course) and automate this for future usage. I did some research and found out there are number of ways tools like Postman help you achieve all such requirements and there was plenty of documentation and tutorials available to help you setting things up. So much so that it becomes difficult to find exactly what you are looking for amidst all tht information.

What I wanted was to be able to automate these API calls to send emails and SMS on the test email addresses and phone numbers of my choice without having the need to hit those APIs manually to attain access tokens and make payload parameter changes.


Now, I am still new to Postman and there could be much better and optimal ways to achieve this and even easier tools than Postman to use but here are my top picks if you are new like me and like Postman as much as I do.


1. Make use of Collections and Environments: Postman provides you the ability to create collections within the Workspace you create for a Project. They come in handy when you are dealing with different projects (Business Units in my case).

You can specify request headers like Authorization, Pre-request Scripts(Steps you would like to perform prior to your API calls), Post request Scripts (Steps that you would like to perform after the completion of requests) and Variables you would like to make a part of your collection. All these specifications get applied to all your API calls inside your collection.


Postman also allows you to create different environments within a collection. You can use these environments to switch context between instances of your server like Dev, Staging, Prod etc. or simply to create environment specific variables.


In my case I used Environments within a collection to store Global variables like access tokens, Brand, Country, Language etc. and to store Endpoint URLs pertaining to different request types like Journey Builder Entry Event, Transactional API send and Triggered Send.




2. Make Use of JavaScript blocks to automate Pre and Post send actions:

Postman comes with a lot of pre-written scripts to help you achieve tasks like fetching variable values from environment, setting variable values in the environment, make callouts to other third party servers or scripts and pass parameters etc.


In my case I used it to fetch an Auth2.0 tokens before every call, set the auth token in an environment variable and fetch it in the Authorization header of each API call. This eliminated the need for making seperate Auth calls before the main call and manually picking up Auth token and copying it in each of the main API calls before executing them.


I also made use of the test script to identify the result of each of the API calls if it successfully executed or failed. This helped in knowing the status of each request and the passed percentage when I executed bulk calls in one shot.


3. Use Dynamic Variables and Runner Tool for Dynamic Bulk API calls:

Postman allows you to substitute the payload parameters with a dynamic variable that can be defined at run time and will be picked up by the request body from a flat data file that you supply when you execute the call through Postman Collection Runner. This makes the job easy by defining your API calls with only static data in the payload and letting the payload parameters have dynamic values at run time. You can specify the number of iterations for each or all of your requests you have created as a part of your collection in the data file containing dynamic values for each of your calls.

This is how finally my request looked like for the Transactional Sends. I made use of pre-defined environment variables to pull the static values of endpoints, instance etc in the payload and made use of dynamic variable (defined the same way in request as an environment variable) to put the values like definition key, brand, country, language, email address, names etc. from the data file that I would provide in the runner interface. I also now don't have to create 10 different API calls for the Transactional sends that follow the same payload (JSON structure), I can just provide the API key to the type of Email send I am targeting in the data file along with the rest of the field values.


Here is how the runner interface and the data file would look like if I wish to fire the same API 10 times for 24 country language combinations. I can choose to send all of them on one email address o each one of them 4 times on 24 email addresses. Fun right?










Instead of firing 240 unique calls with different variations, and one call for Authorization, I will be running it just once and all 241 calls will be made and their statuses will be recorded.


It took me an hour or so to figure this out and then 15-20 mins to set this up. It has saved me hours and hours I would have ended up spending making these hundreds of unique API calls manually.

With this in place, I could fire 240 unique API calls with the click of a button and record their responses and save extract them for documentation as well.


Again, this might not be the most optimal way but this is everything I needed and works really well for a developer looking to unit test their code like me or some looking for an easier way to perform Pen Tests.






1,738 views0 comments

Recent Posts

See All
  • White Facebook Icon
  • White Twitter Icon
  • White LinkedIn Icon
bottom of page