Cannot get value from $queryParams key if key name contains dot(.)

[webworm00 (Patrick Chia)]

I’m trying to test Meta APIs on Postman mock servers. I tried to create a contextual response using the $queryParams template helpers to an example in my mocked collection as shown here.

It works when my query string key is simple text containing only alphabets. However, if my key has a dot (.) in it, it does not seem to work e.g. “hub.challenge”:

https://xxxx.mock.pstmn.io/hook?hub.challenge=123123123

According to the docs, it seems to be able to use the \ character to escape the dot(.):

However, when I try it out, the response is blank:

I’ve already tried using “hub\.challenge” and “hub.challenge” in the contextual response template but none works. If I change the key to something like “hubchallenge” instead of “hub.challenge”, then it works properly.

Does anyone have any idea or solution to this? Thanks.

[w4dd325]

Hi @webworm00

Try removing the double quotes.

{
    {{$queryParams 'hub\.challenge'}}
}

The quotes pass the text as a string but if you see the examples on the page you linked they are without quotes.

[webworm00 (Patrick Chia)]

Hi, if I remove the double quotes, it simply returns blank:

[w4dd325]

Try removing the back slash. A dot shouldn’t need to be escaped in URL encoding as far as I am aware.

If that doesn’t work I’ll set up a mock and have a play around with it

[webworm00 (Patrick Chia)]

Tried
{{$queryParams ‘hub.challenge’}}
{{$queryParams ‘hub\.challenge’}}
{{$queryParams ‘hub\\.challenge’}}

All of them returns blank

[michaelderekjones (Mike Jones)]

I’ve been playing with this for the last hour to no avail.

The stub itself is working, as I added another element which returns.

Therefore the . in the parameter is being recognised.

I’ve tried all variations of escape characters including URL encoding ($2e, %2e, etc).

In the end, out of desperation, I created a collectionVariable called Param and used that in the Example.

{
    "{{$queryParams {{param}}}}"
}

This does something really strange as it is finding the parameter but its wrapping it in an object, instead of just showing the value.

{
    "{"hub.challenge":"1234567"}"
}

So close, but yet so far.

I guess all I can really say is that I can confirm that having the . is causing a problem.

I’m off to play the Xbox. Have a good weekend.

[michaelderekjones (Mike Jones)]

Amending the example to just include the following.

{{$queryParams {{param}}}}

Now produces a single json object in the response (removing the extraneous quotes)
Still not just the value as you would expect though.

{
    "hub.challenge": "1234567"
}

If you change the value of hub.challenge, it is returning the updated value.

Not sure if that is acceptable.

[michaelderekjones (Mike Jones)]

Scrub that last bit, as I’ve just realised that this is basically ignoring the param.

It needs to be a valid variable, but is basically being ignored.

It’s basically like calling $queryParams without any arguments or with empty quotes.

You’ll get the same results. It returns all of the params in the mock as an object (which may be a work around).

The stub itself works, with the dots in.

It’s just the $queryParams in the mock doesn’t seem to be able to handle the dots when trying to return a specific parameter.

The common solution to using escape characters doesn’t seem to be supported.

Might be a bug that should be raised on the Postman Github.

[w4dd325]

Have raised this as a bug on Postman GitHub:

Cannot get value from $queryParams key if key name contains dot(.)

[telecoms-candidate-6 (Wally Holt)]

I was just trying to do the exact same thing with Facebook webhook setup and ran into the same problem. After a couple hours of fighting with it, I stumbled on to this thread. Very frustrating to get stuck at step 1 of testing out some web hooks. Not sure if I’m more bothered by the fact that Facebook decided to include a ‘.’ in the query params, or that postman couldn’t handle it properly

I didn’t see a way to +1 the issue that was opened on Github, but would gladly do something there if it would get more attention on this one.

[webworm00 (Patrick Chia)]

Personally I moved to using pipedream to test the webhooks since I do not know when or if it will be resolved.