Skip to main content

API Connection With Salesforce CMS From Postman/workbench For Testing Output – Part 3

By September 7, 2021May 18th, 2022No Comments

API Connection With Salesforce
CMS From Postman/workbench
For Testing Output – Part 3

In the last two blogs we covered what CMS is and how the content can be created and published inside a Salesforce managed website/portal. In this blog we gonna see how to test the content that is going to be exported outside Salesforce.

Apart from using the content created inside Salesforce CMS for Community portals and websites, the content can be exported outside Salesforce using these APIs. However, before using them in the outer world we need to make sure that the data sent is in the right and expected format. For doing that we have two ways to test and correct the output.

  1. Workbench
  2. Postman

Before discussing these options we need to talk about Content delivery APIs.The Content Delivery API enables you to retrieve content from Salesforce CMS and use it to build and deliver custom experiences. You can use the API to help build components in Lightning as well as reuse content from Salesforce CMS in multiple places.

Paths that can be used to access CMS content through Delivery APIs will be in the below format.

Resource Description
/connect/communities/communityId/managed-content/delivery Get published managed content versions for an Experience Cloud site.
/connect/communities/communityId/managed-content/delivery/contents/search Search managed content in an Experience Cloud site.
/connect/cms/delivery/channels Get managed content delivery channels for the context user.
/connect/cms/delivery/channels/channelId/contents/query Get published managed content versions for a channel.
/connect/cms/delivery/channels/channelId/contents/search Search managed content in a channel.
/connect/cms/delivery/channels/channelId/media/mediaGUID/content Get the binary stream of a media node of published content in a channel.
/connect/cms/channels/channelId/searchable-content-types Get or update the searchable status for managed content types in a channel.

Let’s come back to the options for testing API’s output. We first go with the workbench option and test the output for the content we created in the previous blog.

Testing the API output from Workbench

As many of us know using Workbench, I start from the login page of Workbench.

Login with your org credentials and then navigate to Utilities>Rest Explorer. You will be landed on the below page. Copy and paste the path (/connect/cms/delivery/channels) for checking the list of channels in our CMS. We can see a few channels which we created in the previous blog. For example, the Sample Partner Portal.

Now to see the content of a channel we need to use another path (/connect/cms/delivery/channels/channelId/contents/query) . This is used to get the managed content for a given channel.
In our example, I am using the below path with channelId as our Sample Partner Portal, contenttype as news and the Id of the content we created.
In the below image, we can see the attributes of the news type content in our Partner portal channel.

This way we can see and confirm the attributes of a content before passing it to other environments. Since workbench is an integrated and trusted connection within Salesforce we can do it right away without any prerequisites.

In case of Postman, it’s completely like setting a trusted connection with other application outside Salesforce. If we establish a connection with the postman and make the calls from the postman, it’s almost similar to calling the content from other applications. So let’s do testing with Postman.

Testing the API output from Postman

Basics of Postman:

Postman is an application for interacting with HTTP API. It is an interactive and automatic tool for verifying the APIs. It works in the backend and makes sure that each API is working.

Getting Started with Postman:

Install Postman by going to Postman Apps or Google Chrome.

The above screen will be displayed after launching the postman.

Salesforce Connected App

Salesforce provides a Connected App to connect with any other platform/application. A connected app is an application that allows an external application to integrate with Salesforce using APIs and standard protocols.

Let’s start creating the connected app in Salesforce by following the below steps.

1. In Salesforce, navigate to Setup->Apps->App Manager

2. Click on the New Connected App and you will be presented with the following and we have to fill in the details as below.

3. Enable OAuth settings as below and select the scope as below.

By filling in the details, the salesforce will start creating the connected app for us, which might take around 5 -10 minutes. Meanwhile, the newly created connected app page will be shown as below.

Now it’s time to copy and keep the Consumer Key and Consumer Secret in a notepad.

In postman, we need to get authenticated by the salesforce first, after then, once we get the secure token as response, using that we can start communicating with Salesforce.

Let’s come back to the postman and open the window and select the post method and give the parameters as required below.

In my case, I have used my domain followed by services/oauth2/token?.

Note: In place of username, please use your org’s username and for password it should be the combination of your password+security token for your username in your org.

For getting that security token you have to go to the user settings which can be found by clicking on your account as below.

Once after clicking on the settings, you can reset your token, which will be sent to your registered email.

Now, by providing all the details in the post request, we will get our security token in the response.

After posting the above request, we will be supplied with an access token which should be copied and saved in our notepad.

Now, open a new window in Postman and select the get method and in the header section, select the key as Authorization and in the Value enter the “ Bearer + access token (received in the previous post response).

Give the URL as we tried in the workbench and hit the send button.


We could see the same response as before from the postman too.

With this we completed our third blog in our series. Let’s catch up with another topic.