We sincerely apologize to those of you who may have received 100+ emails from Postman about the updates to the workspace/collection. Unfortunately this was out of our control and a āfeatureā of the Postman platform. We will reach out to Postman about a solution to this for future updates.
We love all the feedback weāve received over the last 5 months on how youāve all been using our official Postman workspace and the different ways youāve made changes or improvements. Today, weāve made some improvements to the IdentityNow workspace that require your attention! We will retroactively update the Postman guide on this, but weāll let you know here as well.
As always, let us know your thoughts here!
Changes
Pre-request script now works in the browser
Pre-request script no longer fails the first time a request is ran
Endpoint versions were moved from from a collection variable to each endpoint
You can now fully utilize Postman environments for each IdentityNow environment you have (no more workarounds needed)
Added consistency to variable naming conventions
Added official environment to the IdentityNow Postman workspace
How to Update Your Postman Environment
Youāll notice that some of these changes were ābreaking changesā to your Postman environment. Hereās what you need to do to get your Postman collection back in order:
Pull the Latest Changes
Right-click on your collection, and click Pull Changes to update your collection.
With this update, weāve added an environment to the postman workspace which you can fork in the same manner that you did the collection. This will allow you to get updates to the environment in the future as we continue to add new capabilities to our workspace. In case you decide to keep your own, these fixes/improvements mean youāll need to update your environments. You will need the following environment variables in your Postman environment:
Be sure you do not have baseUrl in your environment variables.
Environment Variable
Required
Description
tenant
*
This is your IdentityNow tenant, typically your companyās name.
clientId
*
This is the client ID for the API client or personal access token.
clientSecret
*
This is the client secret for the API client or personal access token.
domain
This field is optional and is only needed for a select few who may have a domain in their API URL that differs from āidentitynowā.
This is great @derek_putnam!
I had a question on the way the APIs will update when we hit āPull Changesā on the Postman collection. If my APIs have been saved with some data like the JSON body, some query parameters etc., do they have to be reconfigured again after the update, or will the changes not affect that?
Also wanted to understand what happens to an existing JSON body when, say, the newer versions make changes to the JSON body syntax/structure. Iām guessing that would need some manual changing, but I could be wrong.
Thatās a really great question. Iām going to see if I can find a way to test this with Postman today, because Iām not actually sure what would happen there. In the meantime, what I can tell you is that we did not make any changes to any request bodies or query parameters. We only made changes to:
Promising start, but hit a question pretty quick. New variable on the Beta {{accessToken}} is not defined anywhere from what I can tell. Where/How is the {{accesstoken}} supposed to be defined and populated? Thanks!
I just tested this out and the āPull Changesā will not overwrite any post JSON bodies or query parameters.
If there are any conflicting parameters, for example if we updated the offset parameter to 5 from 0 on one of the GET calls. Postman would recognize the difference and ask you if you would like to merge in the new changes.
Iām also working on a collection runner on Postman that we can use to semi-automate deployments with IdentityNow APIs. For now, the API calls have to be made manually (unless an external app is built which leverages the APIs) and that can sometimes be time consuming during large deployments/migrations.
I have a thread added here, and will keep you posted if I could make any progress on that front! But please let me know if you have any ideas, as this has potential to reduce a ton of unintended human errors.
I canāt figure out how to authenticate now that Iām using your latest greatest in Postman. Previously, in Postman, I would open the top level (IdentityNow Beta APIs) and use options on the page that opened to āGet New Access Tokenā; the individual endpoints had āInherit from parentā. And everything worked.
Now with the forked collection that specifies āBearer Tokenā, I have the client/secret on the enviornment still, but on the collection there is not a āGet New Access Tokenā button. When I run the āList Latest Invocation Statusesā endpoint, I get the error
Unfortunately with Event Triggers, logs are only available for 24 hours so I only have until ~9pm EST to get the logs or we will have to complete another load test. So even though this is āDeveloper Daysā I sincerely hope someone has time to point me to guidance. Thanks!
Hello Jordan,
Can I get the link to the most recent postman collection? I am unable to generate an access token despite setting up the environment credentials witht the tenant name & client ID and client secret.
There was an error in evaluating the Pre-request Script:Error: Unexpected token u in JSON at position
It seems like the error youāre encountering in Postman is due to a JSON parsing issue in your pre-request script. The message Unexpected token u in JSON at position typically indicates that the parser expected a valid JSON token but found āundefinedā instead. This usually happens when trying to parse something that isnāt properly formatted as JSON, or when a variable expected to contain JSON data is actually undefined .