Postman is a free and powerful tool to help you quickly test APIs. We’ve created a moltin collection so that you can test drive the API within Postman!

The collection comes bundled with a Postman environment, where you can place your credentials.

If you haven’t already, be sure to download the Postman desktop client first. Once it’s finished installing, open it up.

Next, run this button to import the moltin collection:

Run in Postman


If you’re not familiar with managing environment variables then we would urge you to have a read of the Postman docs on managing environment variables.

Click the environment called moltin. Add your own client_id and client_secret into the predefined environment fields and start with the Authentication request.

As bearer tokens only last for 60 minutes, you’ll need to re-authenticate after this time to ensure you don’t get 401 forbidden responses from the API. To do so simply hit the Auth endpoint once more. We have used the test scripting features of Postman to populate the bearer value used in each request — this way you don’t have to copy and paste it into every header.

Now you’re ready to make on-demand API requests to moltin!

Hell yeah.

If you view the list of environment variables you will note a number of those available have no corresponding value set. Again, we have used the features provided by Postman’s test scripting to assist. Many of the POST requests that create entities have some code within the test tab. This code will automatically populate IDs for things, such as a product, to be used in other requests. This definitely helps, but can also be the source of confusion. We have added code around this to only update environment variables IF you explicitly set the environment variable liveUpdate to true. If you don’t, the code will not make any changes to other environment variables.

Postman can run an entire suite of tests, but this will be done in the order the collection is displayed in; so this might not be a useful feature. Should you wish to run Postman collections you have some options.

The first option is to run them ‘manually’. This means you hit the send button for any given request yourself, therefore, dictating the flow of the test suite.

The other option is to ensure Authentication runs first (renaming it to “1 Authentication” for example). After this you can specify which request should be made next by way of using postman.setNextRequest() as detailed in custom workflows for postman.

These concepts may be familiar to many, but we’ve included links for those who simply want a reference point.

Matt Foyle

Written by Matt Foyle - Partnerships @ moltin