URL parameters inside API Raw Request is that possible?

Support
#1

Hello Team,

I am back with another challenge for me at least. Hopefully it has easy solution.

I am using one API endpoint to grab events list with various data inside the array. And now I need to show a single event page with different sets of data per each instance so I have to grab it from a different API endpoint. To pull up corresponding data set per event I need to use Raw parameters for the Request inside second endpoint settings. It looks something like this:

{ "action":"getAppMode", "args": "{\"id\" : \"a9761703-de61-4b10-9641-a9e85a5c6e4f\",\"typeID\":470\n}" }

The challenge I currently have is that instead of id and typeID I need to use URL parameters. And if instead of existing in the array id and typeID I put something like {{dc:url:param key="ID"}} and {{dc:url:param key="typeID"}} I get error 500 in the API Tester. I also tried Twig variants {{ url.param({"key":"ID"}) }} and {{ url.param({"key":"typeID"}) }} instead as it is active at my site.

In other words the following expression doesn’t pass the URL parameters dynamically and the tester check fails:

{ "action":"getAppMode", "args": "{\"id\" : \"{{dc:url:param key="ID"}}\",\"typeID\":{{dc:url:param key=\"typeID\"}}}" }

Is there a way to solve this problem?

#2

Another similar case with the API endpoint Request in Raw format where that could be useful:

{
"type":["events"],
"organizations":["b6208ed0-4227-479e-8572-91b5e185fecc"],
"start":"01.11.2024",
"end":"31.10.2025",
"categories": 8,
"locations":["c5eaec9f-a4df-4028-b234-a4b0468b98f1"]
}

If we could pull up variables like “type”, “organizations”, “start”, “end”, “categories” and “locations” from the Element Parameters of a DIV for instance which is set as Looper Provider / Consumer that would be a very flexible solution to put them in via Param tab and get only the data we need from the External API. If it is not already possible, I might not be aware.

#3

There is currently a bug where Twig won’t work in those args if the Twig block contains quotes, so let’s use standard {{dc:url:param key="ID"}} for now there.

Since the args part of the request was an object. Do you need to use json as the Request? I’m afraid some formatting might prevent Dynamic Content from rendering properly because of the use of Attribute there. Try also using single quotes like {{dc:url:param key='ID'}}.

image

I’ve used parameters to pipe into the External API before. Are you encountering an error there?

1 Like
#4

Thank you for the information. It didn’t work in Raw with double quotes for URL parameters. I will try to use single instead, however. My earlier experiments consistently resulted in API errors or caused disruptions in the received array, yielding only partial data (some nested array’s data gets cut off). It worked well with static values in Raw, but I need to use URL parameters instead. I really hope single quotes will solve the issue.

#5

Here are my suspicious findings after some experiments:

  1. There is an issue with outputting array items when using two endpoints with different parameters but from the same URL.
  2. Styling issue of the data inside API Tester when HTML content is pulled up with some inline styling applied.
  3. There is a problem with retrieving data from nested arrays.

I included a few videos in a secure note to show what I mean, as explaining the issues in detail would be challenging.

#6

That ticket request you were hitting was actually a GET not a post. At least that’s what caused it to work for me. Are you all good now on that page? I created a new global api. It can also help to use “fallback” on the dynamic content so you can view it in the preview easier.

{ 
  "type": [ "eventAppMode" ],
  "id": "{{dc:url:param key='ID' fallback='a9761703-de61-4b10-9641-a9e85a5c6e4f'}}",
  "itemTypes": [ {{dc:url:param key='typeID' fallback='470'}} ]
}
#7

Oh, that is strange as I was informed by the API developer that I need to use POST for that instance. That is surprising. I haven’t checked that yet but I trust your experience so far. I am sure it should fix the issue. I will come back if something goes wrong as always. Thank you, Charlie.It is very helpful to learn the External API feature, which makes a big difference to other products on the market. :handshake:

1 Like
#8

Hi John,

You are most welcome.

#9

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.