I am stuck here. Could anyone help me?
Here is the link to access to my workspace: https://api.postman.com/collections/24865649-bf4c9558-f4f9-41d0-b43b-4a5433462321?access_key=PMAT-01GM2SW26FWGN1DX2BXMXDAXRP
This seems to be catching a few people out, so I’ll try and explain what is happening.
This is the test that is failing.
pm.expect(encodeURI(authObj.apikey.value).indexOf('%7B%7B')).to.be.above(-1)
authObj relates to the authentication.
The indexOf() method returns the position of the first occurrence of a value in a string.
The indexOf() method returns -1 if the value is not found.
The indexOf() method is case sensitive
%7B in an URL is converted to {
This is what the encodeURI is doing.
There should only be one apikey in the response and the value should be set to {{email_key}}
So the test is basically testing to see if the authObj.apikey.value contains {{
If it can’t find it, then the test will fail (as the indexof() method will return -1).
The apikey value is actually logged to the console during the test.
let addresses = requestArr.filter(value => value.request.url.raw ? value.request.url.raw : value.request.url).map(value => value.request.url.raw ? value.request.url.raw : value.request.url);
var addressVars = addresses.filter(p => encodeURI(p).indexOf('%7B%7B')>-1);
console.log(addressVars);
It should be the first value in the console logs.
The screenshots I’ve seen where its failing are showing more than one element in the logs.
This will break the test as the response is now an array.
authObj.apikey.value will fail
authObj.apikey[0].value would work
This is related to the authentication which is meant to be set at the collection level.
Everywhere else (all folders and requests) the authentication should be set to inherit auth from parent.
Thank you very much for the detailed reply, but I have all of my folders and requests set to inherit and I have the “Galaxy Apis 101” set exactly as you showed in screenshot. Is there something else im missing here? All of my folders and requests match the pics im sharing in this post.
I can just about see in the last screen shot that you have two [2] apikeys in the console log.
This is what is causing the test to fail.
How about the check progress folder and the Collection status request?
@michaelderekjones I will attach more screenshots here. I see what you say is making it fail, but I cant find the issue. Thanks for the help and please let me know what you think about screenshots.
It’s going to be one of the requests\folders.
If you link the collection URL, I can have a look. (The one in the collection status that includes your access key PMAT=).
@michaelderekjones Thank you again for helping me with this! Im not 100% sure what to share so that you can check it out, so I will share a couple of links here below. Let me know what you think. Im very eager to understand what the issue is here and to learn from it.
Screenshots of requests folders below
I think this is one for Postman to review and is a bug in the test\documentation.
I imported your collection and reviewed it side by side with my working submission.
They are the same, and the authentication appears to be set correct on the collection with everywhere else set to inherit.
The only difference I could find is that the “Collection Status” request was using a different URL.
When I initially did this course, there were different instructions on how to share the collection.
With Postman 10, the Via API method changed and you have to include the token in the URL.
Prior to this you made the collection public and shared via a different API.
For some reason the new method is producing slightly different JSON and is breaking the test.
I took your collection, imported it, then moved it to a public workspace, and then used the old URL for the Collection Status and it passes.
I can’t get it to pass using the API detailed in the updated documentation.
This works.
https://www.getpostman.com/collections/22518626-ec91a63d-8940-4973-a645-2172dd0641ba
You can see that the auth is set ok.
"auth": {
"type": "apikey",
"apikey": {
"value": "{{email_key}}",
"key": "csm_key"
}
},
This doesn’t.
You can see that its the same collection.
However, the JSON is returning the following instead (which is what is causing the test to fail as it has two keys in the response, turning it into an array).
` "auth": {
"type": "apikey",
"apikey": [
{
"key": "value",
"value": "{{email_key}}",
"type": "string"
},
{
"key": "key",
"value": "csm_key",
"type": "string"
}
]
}`
I don’t know why you would get different JSON from the two different APIs.
This looks like a bug that should be raised with Postman.
@danny-dainton Is there an issue with this collection status API?
The old way using a public collection seems to be ok, but the new method using the Via API + access key as per the new instructions is producing different code in the collection and breaking this test.
You can see my previous post which shows the same collection using the two different methods, and you can see that for the Via API method, the auth code is different and is returning more than one key.
Has anyone been able to submit this recently?
Hey everyone,
Looks like we forgot to update that part of the training, apologies, this is updated now. 
If you’re worried about pulling the changes and overwriting changes you may have done already, feel free to submit your collection directly through this form as this will check against the updated tests already:
Just wanted add feedback to Arlemi’s post. I had the same issue with submitting for my Postman API 101 badge. If you use the link Arlemi provided, you’ll receive your badge even though this specific error is present in your collection.
I finally have my 101 badge after trying to submit it tonight with Arlemi’s Airtable link, yay!
1 Like