API Data Source - Help Needed

[StefanoF]

I am testing how API works. Read all the docs and some topics here. Then in a new page I prepared the API Data Source for the connection to a test environment of Amadeus (Travel GDS).

The endpoint is https://test.api.amadeus.com/v2/shopping/hotel-offers

One mandatory parameter is CityCode = PAR (for Paris)

The header authorization has to be Bearer + Token. In the Amadeus test environment the token can be generated online and expires after 30 minutes. In the bottom line I will post a newly generated token.

When I try to define the API Schema all the data are in the right place, as you can see:

But the when I fetch the schema I get an error [object Object]:

Before posting this case I have tried to use the same API in PostMan and it works fine.

I don’t know what kind of error I am making in Wappler. Appreciate any help.

If you want to give a try yourself, this is the Bearer token that should last until 11:40 am today.

6eXXOyAyGlfgcNxGj64syxHoGlEA

In case you want to help me but the token is expired, please let me know and I will send a new one.

[s.alpaslan]

your result is an OBJECT . so not an array …
if you need to use it with repeater it must be array

[StefanoF]

I have not created any element in the page. I just wanted to see if I was able to get some data and then I was going to figure out how to display them. Can you please be more specific about what I should do ? Sorry but I am a beginner (no coder). Thanks

[s.alpaslan]

object result not fail … you can use it with wappler binding … so your syntax will be (only example)
{{serverconnect1.api1.data.abc[0].xyz}}

[StefanoF]

Thank you @s.alpaslan, but unfortunately I am not skilled enough to understand your advice. Maybe you or @Teodor can guide me step by step … I hope

[s.alpaslan]

please read documentations .

Wappler Official Documentation

Here you can find the Wappler’s official documentation. Make sure you review it all first to understand all the powerful features of Wappler and its general usage. Please Note: The original Docs Area found here is arranged in category format which might be easier to follow as each category has chronologically ordered tutorials within. Table of Contents (TOC) The below is formatted in "story format" where each concept or tutorial follows the previous concepts already learnt from the article be…

and dont worry all @wappler_ambassadors can help everytime

[Hyperbytes]

Try taking the single quotes from the parameters in the server action, server action strings should not need to be quoted.

[StefanoF]

Removed quotes from parameters, but the situation does not change. Too bad that I don’t understand this thing about object results … For what I can see in Postman the date are properly retrieved. This is an example

{
“data”: [
{
“type”: “hotel-offers”,
“hotel”: {
“type”: “hotel”,
“hotelId”: “XKPARC12”,
“chainCode”: “XK”,
“dupeId”: “501132260”,
“name”: “HOLIDAY INN PARIS-NOTRE DAME”,
“cityCode”: “PAR”,
“latitude”: 48.85268,
“longitude”: 2.34227,
“hotelDistance”: {
“distance”: 0.3,
“distanceUnit”: “KM”
},
“address”: {
“lines”: [
“4 RUE DANTON”
],
“postalCode”: “75006”,
“cityName”: “PARIS”,
“countryCode”: “FR”
},
“contact”: {
“phone”: “33-1-81690060”,

I have been trying to learn Wappler full time for 2 weeks now and I have read all the available documentation but I did not find this specific topic. Hope to get some help. I am also available to work with a free lancer that teaches me how to do this and other stuff.

[psweb]

I do not know what you have already tried however just looking at it, i would firstly try not including the word "Bearer " in front of the code, then fiddle around with different ways.

Try citycode with and without apostrophes surrounding the word, try PAR with and without apostrophes too, and do the same for Authorization, testing each time to see if your result comes out.

I must tell you though looking at the variances in your own screenshots, it could be something very simple.
In your Wappler Screenshot vs your PostMan screenshot here are some differences
Wappler Query Parameter citycode, PostMan cityCode, the second C is a capital letter
Wappler Header parameter ‘Bearer U3Agg…’, PostMan U3Agg… the word Bearer and the space has not been used at all.

[StefanoF]

Hi @psweb, thank you for your reply. As a matter of fact I have tried any possible combination of quotes / no quotes / bearer / no bearer etc. In Postman is much easier since you have just to select, under the authorization tab, the Bearer Token type and past the token.

I was hoping that someone could take the time to reproduce himself this API. Since it is a test there is no need to keep data confidential. I have already provided the endpoint and I can give an updated token. I have only created a new account in https://developers.amadeus.com/ and used the free self service option.

Endpoint with one mandatory parameter: https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=PAR

newly created token (last 30 minutes) sVucFsM02DgFkZMtf0BXS4M5Xoxk

[TomD]

I think @psweb may have identified the problem. If you use ‘citycode’ in Postman, the request fails; it works with ‘cityCode’. Wappler changes the parameter to lowercase - so it might be a Wappler issue.

(I don’t have much experience with APIs but I think this issue has cropped up before)

[StefanoF]

Here we go I have changed to lowercase the citycode parameter in Postman and this is it

Maybe this not the only problem, but at least we are one step ahead. Thank you @TomD

Now the question is: how can we pass the correct parameter name in Wappler ?

[Hyperbytes]

I think I see the problem.

By default Wappler changes the case of parameters to lower case automatically

So for example cityCode is changed to citycode

I think this is causing an error and an invalid response is being returned

[psweb]

Think i have it solved, can you give me a new token please

[StefanoF]

Here we go

0IUyvkeg0zi3PaxxvSKGGAxbHnb7

[psweb]

Ok, got it to work, not an ideal situation, because yes there does seem to be a Wappler bug here sadly

@patrick, @Teodor, @George.
So one of the issues is that in the Schema Query parameters the Name of the Key needs to be cityCode and not citycode and sadly Wappler is auto converting that camelcase to all lowercase. I even tried to change it in the code and it still fails.

To get around the problem set your endpoint with the query parameter yourself, which is obviously not ideal if you ever want to use a different country it will be a pain till they fix this. https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=PAR
So dont use a query parameter at all, just use the header, with name authorization and Value Bearer xxxxxxxxxx

Here is a screenshot of the result

[Hyperbytes]

I can confirm that if I use these details in a server connect action which does NOT change the case of the parameter is works correctly and the schema is returned, this issue is the automatic case change in the app connect API action

[psweb]

And just a last point, for something like this with sensitive keys etc, you should be using the Server Connect side rather than the ClientSide

[StefanoF]

Thank you all. I have tried both solutions, client side with the parameter in URL as well as server side API action, and it works fine !

If I can ask another advice, the use case for my future app will be this:

1. a user looks for an hotel in a city within a date range
2. then selects a specific hotel to see details and price (that will be another API call)
3. and eventually confirm that he/she wants that hotel to be booked (outside the app)

My idea was to make only client side API calls and then save to DB the data (or a reference) related to the hotel that user wants to book (step 3).

In your opinion when a server side API call should be used versus a client side API call ? What are the main differences between the two options ?

PS: I don’t know if the automatic case change in the API action is a bug or a specific feature for some reason, but I hope that it will be fixed maybe giving the option to input case sensitive words.

[Hyperbytes]

Personally I use server side in preference all the time where possible however as a general rule I may use client side if only a single result is needed and the api key is not secret (such as google API which is linked to a specific domain)

Where the key(s) is/are secret, i need to store the details in a database table or if multiple results are returned i tend to use server side.

The case issue has been discussed before and is by design rather than being a specific bug. very few APIs use other than lower case parameters so it was done to stop case errors but this is a problem for the few that do use upper case characters