**EDIT 04/08/2021** – Updated to show implementation inside of new POSTman UI as well as set up utilizing the same environment and syntax used by the Salesforce provided API collection.

API calls are one of the most powerful tools available to an SFMC user. It essentially allows you to make changes, perform actions, retrieve data and more all programmatically via an outside resource.

Below I will give a quick overview on setting up an API integration package and then utilizing it in POSTman. This includes, creating the package, the component and gathering the required information from Salesforce Marketing Cloud down to creating the environment and setting up an authentication call and test calls inside of POSTman.

Creating Your Package:

First you will need to go into the ‘Setup’ section which is under your user name in the top right of the screen. You will need to hover over it and the dropdown should have one of the first options being ‘Setup’.

From there you will want to navigate on the left sidebar to ‘Platform Tools’ and then expand ‘Apps’ and select ‘Installed Packages’.

Click on ‘New’ in the top right. This will open a popup asking for name/description of your new package.

You then want to hit save to create your package.

Creating Your Component:

Next part is the creation of the component inside the package to allow utilization of API integration between your external system and SFMC.

After building the package, this will then open up a screen with your new Package overview.  The part we want to concentrate on is the bottom that involves ‘Components’. You will want to click on ‘Add Component’.

This will open a new popup to select the component type. For the purposes of this article, you will want to select ‘API Integration’. Then Click Next at the bottom.

Next you need to select your integration type. For this article, I am going to choose ‘Server-to-Server’ as this is only going to be used via POSTman or similar services. For more information on Component Types, see official documentation here.

You will then need to assign the scope of your package (see official documents on scope here). For this article, I am going to allow full permissions on my package – basically allowing full access to the whole platform. After testing, you should make sure to go back and assign scope on your component as appropriate for your intended usage.

You then hit save and the new component will be added to your package.

You then will want to grab the following fields for use in your API call:

1. Client Id
2. Client Secret
3. Tenet Specific Endpoint

These will be used inside your POSTman API calls.

**EDIT** I wanted to give a quick thank you to Vishal Kumar C V and Renato Oliveira for bringing up that I did not include the append needed to be added to the SOAP Base URI (/Service.asmx) for the SOAP API to work. See more details inside of this Stack Exchange post.

POSTman Environment Set Up:

Next we will work on setting up an Environment in POSTman to best utilize your new Package in SFMC.

In POSTman you will want to click the ‘New’ button at the top of the side bar to the right of the ‘My Workspace’ label:

This will open the below window where you will want to select the ‘Environment’ option:

This is where you will add in the information you will need to be able to utilize SOAP and REST API calls to SFMC from POSTman

Sample completed Environment below:

You will then be able to select this environment in the dropdown at the top right of your POSTman.

Making Your Authentication Call:

Now that you have your environment set up, you need to aim at retrieving your token so that you can do your REST/SOAP API calls. First things first, verify that your environment is selected in the dropdown in the top right of your POSTman.

Below is a quick overview of the call, that you can use if you have familiarity with POSTman to set up your call:

POST /v2/token 
Host: {{et_subdomain}}.auth.marketingcloudapis.com
Content-Type: application/json

{
"grant_type": "client_credentials",
"client_id": "{{et_clientId}}",
"client_secret": "{{et_clientSecret}}",
"account_id": "{{et_mid}}"
}

For the visual learners, use the below images to help figure out where to put this information:

You will notice in my call, I have included a parameter account_id with a replacement named {{et_mid}}. This can be used to switch between BUs by assigning an MID to your environment and filling it in here. Please note that this can be included with mid being empty or null and it will still function as expected. You will need to properly set access to the Installed Package to access other BUs.

Another quick note to help auto-store your authentication is to utilize a script that can be added in the ‘Tests’ section in your Auth call. See below image and snippet:

var data = JSON.parse(responseBody);

if (data.access_token) {
  tests["Body has accessToken"] = true; 
  pm.environment.set("dne_etAccessToken", data.access_token);
}
else {
  tests["Body has access_token"] = false;
}

By adding this JS in, on each call of this, it will update the dne_etAccessToke variable in your environment with the returned token in your Response. As a note, you can also set up a similar Authorization process in the ‘Authorization’ tab on the call as well, but I tend to use the call and script option more often.

After setting all of this up, you will want to click the ‘Send’ button in the top right, near where you set your environment.

Example Response:

Your Test Call In REST API:

To test and make sure your environment and access token are set up properly, I am going to provide a very simple test API call. This call is basically a discovery call to gather all endpoints under a specific section. For this sample, we will use the ‘contacts’ section.

See below extract and image for setting up this call:

GET /contacts/v1/rest
Host: {{et_subdomain}}.rest.marketingcloudapis.com
Authorization: Bearer {{dne_etAccessToken}}
Content-Type: application/json

You then want to hit send in the top right.  This should then return something like the below in the Response section:

Congratulations! You have successfully completed a REST API call to your SFMC BU.

Your Test Call In SOAP API:

For this sample, I am going to do a quick example Retrieve on a Subscriber via SOAP.  There are certain differences that need to be noted in SOAP that are not in REST.

Here is a down and dirty list:

1. Method will always be POST
2. Requires a header key of ‘SoapAction’ – value will mimic the request type. E.g. RetrieveRequest will be SoapAction = Retrieve
   1. You can put this directly into the Headers section like so: SoapAction: Retrieve
   2. Or you can put it into the Envelope Header (my preference), like so: <s:Header><a:Action s:mustUnderstand="1">Retrieve</a:Action>...
3. Authentication is inside of the envelope header of the call, not in the Headers section like REST.
4. SOAP utilizes XML for the payload, unlike REST which uses JSON
5. The endpoint that SOAP aims at is universal for all calls, the envelope determines content and action
6. SOAP has Methods (declared inside of payload/body) as well as Objects that are to be utilized to determine action and result.
7. SOAP requires explicit declaration of Properties in retrieve calls

Below is an extract of the SOAP call on retrieving a subscriber:

POST /Service.asmx 
Host: {{et_subdomain}}.soap.marketingcloudapis.com
Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <s:Header>
        <a:Action s:mustUnderstand="1">Retrieve</a:Action>
        <a:To s:mustUnderstand="1">https://{{et_subdomain}}.soap.marketingcloudapis.com/Service.asmx</a:To>
        <fueloauth xmlns="http://exacttarget.com">{{dne_etAccessToken}}</fueloauth>
    </s:Header>
    <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        <RetrieveRequestMsg xmlns="http://exacttarget.com/wsdl/partnerAPI">
            <RetrieveRequest>
                <ObjectType>Subscriber</ObjectType>
                <Properties>CreatedDate</Properties>
                <Properties>Client.ID</Properties>
                <Properties>EmailAddress</Properties>
                <Properties>SubscriberKey</Properties>
                <Properties>Status</Properties>
                <Properties>UnsubscribedDate</Properties>
                <Properties>EmailTypePreference</Properties>
                <Filter xsi:type="SimpleFilterPart">
                    <Property>SubscriberKey</Property>
                    <SimpleOperator>equals</SimpleOperator>
                    <Value>123456</Value>
                </Filter>
            </RetrieveRequest>
        </RetrieveRequestMsg>
    </s:Body>
</s:Envelope>

Below are a few Screenshots to help provide further context:

This should then return a SOAP envelope with the requested fields shown above inside of it.  See below image showing a response to the above call:

Congratulations! You have now successfully created, implemented and performed a SOAP API call to SFMC!

Collections And Environments

For future API calls, you can check out this POSTman library for some sample SOAP and REST API calls to get you started. They should offer a sample environment file as well as a collection file that fit within the same set up as I have above. At some point I am kicking around the idea of making my own collection, but have not gotten to that point yet. I will make sure to update if that happens!