Salesforce exposes a rich set of APIs that lets you integrate your org with third-party systems in a great variety of scenarios. All of these APIs are thoroughly documented, but how can you quickly try them on a given org – or better yet, on multiple orgs?
In this post, I’ll introduce you to Postman and show you how to easily explore and test different Salesforce APIs against multiple orgs using an open-source Postman collection (that I’ve already assembled for you). This unofficial collection currently holds close to 200 API call templates for 10 Salesforce APIs (REST, Bulk, UI, Tooling, Metadata, and Composite just to name a few).
Exploring and Testing APIs With Postman
As a Technical Architect, (and like most developers) I often configure and troubleshoot API calls. I configure and compare those calls on multiple environments (sandboxes, production orgs…) then share the results of my findings. In order to do that, I use a couple of tools.
There are several Salesforce and third-party tools that let you explore and call APIs. I’m not going to list them all here but a classic go-to solution for developers is Workbench. Workbench lets you execute Salesforce API calls against all types of orgs directly from your browser. This tool was created by the community and is now operated by Salesforce, but it’s not officially supported and only receives security updates. Workbench is a great tool to explore the Salesforce APIs and run one-shot tests. However, it has several limitations for a broader use: it doesn’t allow you to save your configuration, reuse it on multiple orgs or collaborate.
Since Workbench didn’t cover all of my needs, I started using Postman to troubleshoot API calls. Unlike Workbench, it’s not tied to Salesforce technology but it has several great advantages:
- It gives you full control over HTTP requests. There’s no file upload limit; you can set headers and parameters, and use any content type (binary, text…)
- You can switch between multiple environments. For instance, you can have an environment for production and another one for a sandbox. When switching environments, all variable values are updated to environment-specific values.
- If you use the free version of Postman, you can collaborate on requests by importing/exporting your workspaces. There are also paid plans that couple Postman with source control for live collaboration.
Postman helps me quickly design and reuse API requests across projects. As the number of reusable requests grew, I decided to create an open-source Salesforce APIs collection.
Introducing the Salesforce API Collection
Salesforce APIs for Postman is a collection of requests for Salesforce APIs. The collection includes hundreds of request templates grouped into folders (one per API), a template environment with variables and header presets.
Building from API request templates instead of going into each API’s documentation saves you a lot of time and greatly reduces the risk of errors. However, just like Workbench, the Salesforce APIs Collection doesn’t replace the documentation. You’ll need to use Postman in combination with the API’s documentation.
An advantage of Postman over tools like Workbench is that it allows you to explore a variety of Salesforce authentication flows. The Salesforce APIs Collection lets you try these different flows: you can try the SOAP login flow, OAuth username/password flow, JWT Bearer Token flow, and other flows. That’s particularly interesting when working on integrations.
When working on a project, I usually maintain a Postman environment per org. I start by cloning the template environment and filling in the first five variables for each org: URL, version, username, password, and secret token. This way I can quickly use the SOAP login flow and then build and call APIs using the Salesforce API Collection. Then, later on, I can easily switch to another environment and use the same requests.
Let’s see how easy it is to use the collection with an example.
Sample Use Case: Inserting an Attachment on a Case
Before jumping into the example, make sure to complete the following pre-work:
- Install Postman.
- Import the Salesforce APIs Collection and follow the project readme for instructions.
- Clone the template environment and configure it with your org’s credentials.
- Log into your org using the SOAP Login flow in order to validate your settings.
For the purpose of this sample use case, you’ll be in the shoes of a developer working for Acme Inc., a fictitious company that sells goods and manages its operations using the Salesforce Platform. Acme Inc. provides a mobile application to its customers to allow them to create cases about the products they receive. The application lets customers upload a picture of the packages they receive and attach it to the cases. Your goal is to provide the configuration of the Salesforce REST API call that will be used to upload the image as an attachment to a case.
Now that you know more about the API request, let’s create it in Postman:
- Create an
Acmecollection to regroup your custom requests.
- Select the
REST > SObject Createrequest from the Salesforce APIs Collection and duplicate it.
- Rename the new request to
Create Attachment on Caseand store it in your
- Update the endpoint URL by replacing
- Change the body JSON so that it has a
Bodyparameters (as required in the documentation).
Your boilerplate request is ready! Let’s try it out with some real data:
- Provide a name to the attachment with a
- Grab a case Id and set it as the
- Find a picture. Use a service like this to convert it into Base64 and paste the resulting string as the value of the
- Hit the Send button and voila! Refresh your case record and you should see your image in the attachments.
You can now:
- Share the new endpoint with your team.
- Replay the request at will in your dev or testing environment and help troubleshoot potential issues.
- Generate and share the code to make this call in several programming languages.
Now that you know about Postman and this great API collection, follow the getting started instructions and explore the Salesforce APIs. Can’t find the API request you need in the collection? Feel free to contribute to the repository, it’s Open Source!
About the authors
Sébastien Colladon is a Senior Technical Architect at Salesforce Professional Services in Paris, France. He works closely with customers to help them deploy Salesforce in their IT Systems and boost their business. He is a Certified Technical Architect (CTA), and enjoys learning about technology and working with others as a team. Check his GitHub projects @scolladon.
Philippe Ozil is a Principal Developer Evangelist at Salesforce where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full-stack developer and enjoys working on robotics and VR projects. Follow him on Twitter @PhilippeOzil or check his GitHub projects @pozil.