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:
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_secret into the predefined environment fields and start with the
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!
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.