One more question before the glorious weekend! Regarding Postman for API’s, is it used mainly for testing endpoints with Get Put Post and Delete? I saw Eric’s previous answer but wanted to confirm that this is the primary reason to use the Postman service. Is there a favorite instructional video that someone can share? I’ve watched several, but some of the features appear to be unnecessary for creating packs.
1 Like
Yes! You technically don’t need it at all to build packs. It’s just helpful to quickly generate an API response that you can then base your code and schemas off of
2 Likes
Ya, as @Scott_Collier-Weir mentioned in his recent webinar, Postman has a HUGE amount of features, many of which aren’t needed to simply test an API. The tool can certainly be a bit overwhelming at times!
2 Likes
Sometimes APIs come with Postman Collections - a bunch of pre-built Postman templates for all their endpoints that make it easier to get up and running in Postman. What API are you working with?
1 Like
I applied to the one below for fun and received the approval. I chose it because it looks easy and provides dictionary related data. Based on my review of Postman videos, it seems like the next step would be to test a GET function and confirm that it returns a 200 status code. I anticipating only using a pack to GET data presently.
Thereafter, what should I do with the information? Is there a reference online for the tricky things to look out for? Eric stated in a previous post that I should use the Postman results to design the schema and responses in the JavaScript code for the pack. His example used a POST not a GET, but I think there’s plenty of GET examples in the sample code.
I was going to search the sample code to see how to add the user ID and token to the code. You had previously referred to the “Settings” section of packs for this task and I was going to start there.
Again, thank you for your time. 
Email Received:
Thanks for applying to use our APIs. Your application has been approved!
Here are your new API credentials:
User ID:**
Token:**
The API documentation pages and the API dashboard login can be found here:
“STANDS4 APIs” etc,
1 Like
So the main point of Postman is to give you a little playground for testing what you send to the API, and what you get back. Everything you can do in Postman you can also do right in your Pack’s code - but in Postman you can see the results right away.
Unfortunately, Postman has TONS of features that you don’t need (it’s also used by people who make APIs, for testing those APIs), and I personally find the UI pretty confusing as a result.
Postman testing is a bit more useful with a complex API. If you find the Postman setup too tricky, you could consider skipping it and just relying on the API’s documentation for what the responses will look like.
1 Like
A few pointers to get you started, based on the Definitions API:
Authentication
- The API takes a
uidandtokenidas query parameters*. You can include query parameters in your URLs with the functionwithQueryParams - You’ll need to use system authentication with custom tokens (which are, unfortunately, a bit tricky)
Requests
- You want the responses in JSON instead of XML (JSON is generally easier to work with in JavaScript), so another query parameter you should set is
format: json - The search term (the
word) is also expected as a query parameter - Based on the example JSON response they show, you’ll access the contents via something like
response.body.results.result.definition
General
Don’t be afraid to hard-code a bunch of things at first, and then make them dynamic piece by piece. For example, you can just start with the fully hard-coded URL from their demo (swapping xml → json, and filling in your uid and tokenid):
https://www.stands4.com/services/v2/defs.php?uid=1001&tokenid=tk324324&word=consistent&format=json
This is NOT the proper way to handle authentication, and it will only search for the word you’ve hand-written in there - but that’s ok for now. Once you get it working, you can start to make each part dynamic, like proper authentication, running all the parameters through coda.withQueryParams, feeding it the word the Coda user entered, etc.
Also, I recommend making liberal use of console.log to see the results of your code. JSON.stringify is also helpful. Let’s say the variable you’re putting the API response in is called response. Right after that, do:
console.log( JSON.stringify( response, null, 2 )
Don’t worry about what all of that means for now, just know it will spit out the contents of response when you run the Pack, for you to inspect.
*If you’re unfamiliar, query parameters are the stuff in URLs after the question mark. Multiple parameters after the first one are then separated by &
4 Likes
Much appreciated Nick! I will move forward with more confidence.
1 Like
Hi @Lynn_vK, I recently found this course offered by Postman, and deemed it quite helpful in building a better understanding on how to structure API requests.
It is called:
- Learn by API
This collection walks you through the first few steps in making requests to API endpoints.
You can access it here on postman:
Postman
Enjoy , Nina
2 Likes
Thank you Nina for the suggestion. Much appreciated!