Making GET requests with body/payloads

There seems to be an issue with how it's being generated. Could you share some of your code or screenshots?

Certainly!

Here is the code from the custom application:

{
    "url": "/trackDelivery",
    "method": "GET",
    "qs": {},
    "body": {
        "deliveryNote": "{{parameters.deliveryNote}}",
        "courier": "{{parameters.courier}}",
        "deliveryDate": "{{parameters.deliveryDate}}"
    },
    "headers": {
        "Authorization": "Bearer {{connection.accessToken}}"
    },
    "response": {
        "response": "{{body}}",
        "error":{
      "type": "RuntimeError",
      "message": "[{{statusCode}}] nCode:{{body.errorFieldCode}}, Type:{{body.errorTypeCode}}n{{body.errorMessage}}"
    }
    }
}

And here is the code generated by the module in production:

{
    "_engineData": {
        "calledAt": "Not available"
    },
    "response": {
        "status": 415,
        "headers": {
            "server": "nginx",
            "date": "Fri, 22 Apr 2022 06:14:03 GMT",
            "connection": "close",
            "content-length": "0"
        },
        "body": null,
        "_engineData": {
            "calledAt": "Not available"
        }
    },
    "request": {
        "url": "https://api.retelogisticastorage.it/api/externalServices/trackDelivery",
        "qs": {},
        "headers": {
            "user-agent": "callin.io/production",
            "authorization": "***"
        },
        "method": "GET"
    }
}

Is this the correct base URL and path?

https://api.retelogisticastorage.it/api/externalServices/

Yes,

using Insomnia, with the same URL, I am able to get a response from the server.

Is there a block on the callin.io IP address perhaps?

Also, what is the authentication model being used?

The authentication model is OAuth2, and it functions correctly for all other modules of the same application, which my scenarios utilize daily.

Given that other modules from the same app and API set operate without issues, I suspect there isn't a block on the callin.io IP address.

It genuinely seems that for this particular module, no body is being generated.

Have you attempted sending a static body from your application to observe the outcome?

Could you clarify what you mean?

Are you suggesting configuring the app module with static elements? I attempted this, but the outcome was the same.

What headers are you configuring in the Base? Do your total headers align between the request from Insomnia and the callin.io request?

415 Unsupported Media Type

You need to be setting the Content-Type, and possibly Content-Encoding. However, you might also need to utilize the Type parameter within your module, separate from the header information.

Begin by ensuring the request headers match.

I'm on mobile, so I'll validate the request later, but this needs to be output, not response:

    "response": "{{body}}",

It's non-standard to include a body with a GET request, which leads me to believe the API might be a bit unusual to work with.

Please provide the headers you are setting in the Base.

Hi Luke,

Thanks for your assistance. Here’s what I’ve attempted:

1. Added the Content-Type to the module’s headers, mirroring the setup in Insomnia.
2. Switched the response back to a basic format. The one I was using and previously shared is designed to capture server errors for easier debugging. It functions correctly with other modules in the same application, but I tried simplifying it as you suggested.

Unfortunately, nothing has changed.

I’m unclear on where to implement the Type parameter you mentioned. All parameters currently used in the request have a declared type, and they are all set to text. Could you please provide more specific guidance on this?

Below is the modified request as it appears in the custom app module’s configuration page, and how it (doesn't) appear in the raw code from the developer tools for reference.

Custom app’s module:

{
    "url": "/trackDelivery",
    "method": "GET",
    "qs": {},
    "body": {
        "deliveryNote": "{{parameters.deliveryNote}}",
        "courier": "{{parameters.courier}}",
        "deliveryDate": "{{parameters.deliveryDate}}"
    },
    "headers": {
        "Authorization": "Bearer {{connection.accessToken}}",
        "Content-Type":"application/json"
    },
    "content-type":"application/json",
    "response": "{{body}}"
}

Raw code:

{
    "_engineData": {
        "calledAt": "Not available"
    },
    "response": {
        "status": 500,
        "headers": {
            "transfer-encoding": "chunked",
            "content-type": "application/json; charset=utf-8",
            "server": "nginx",
            "date": "Sun, 24 Apr 2022 16:57:02 GMT",
            "connection": "close"
        },
        "body": {
            "errorFieldCode": "999",
            "errorTypeCode": "999",
            "errorMessage": "Generic Error"
        },
        "_engineData": {
            "calledAt": "Not available"
        }
    },
    "request": {
        "url": "https://api.retelogisticastorage.it/api/externalServices/trackDelivery",
        "qs": {},
        "headers": {
            "user-agent": "Make/production",
            "content-type": "application/json",
            "authorization": "***"
        },
        "method": "GET"
    }
}

As you can observe, it seems the module isn't generating a request body. The server's response is a generic error, which is expected if the body is empty or null.

I hope this provides a clearer picture of the issue.

I will check and respond shortly. Could you please include a screenshot of your headers in Insomnia and Chrome Dev Tools for the request in callin.io?

Here's a screenshot of the Headers data from Insomnia (as far as I know, there's no way to get raw headers):

2022-04-25_07-50-182066×1426 281 KB

And here's the data from dev tools:

2022-04-25_07-52-021700×533 54.4 KB

EDIT
Since I also tried with Postman, here is the log from a successful request in Postman:

GET /api/externalServices/trackDelivery HTTP/1.1
Authorization: Bearer ***
Content-Type: application/json
User-Agent: PostmanRuntime/7.29.0
Accept: */*
Postman-Token: eb65d083-ff70-46f6-9e49-77cd6c3f887d
Host: api.retelogisticastorage.it
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 83

{
"deliveryNote": "4076318260",
"courier": "DHL",
"deliveryDate": "2022-04-20"
}

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Content-Encoding: br
Server: nginx
X-Powered-By: PleskLin
Date: Mon, 25 Apr 2022 06:41:07 GMT

{"deliveryNote":"4076318260","trackingDetails":[{"code":"OK","description":"Spedizione Consegnata - Firmata da : ","date":"2022-04-21T14:44:00","notes":"Spedizione Consegnata - Firmata da : ","notFound":false,"internalStatus":2},{"code":"WC","description":"Spedizione in consegna","date":"2022-04-21T10:44:00","notes":"Spedizione in consegna","notFound":false,"internalStatus":1},{"code":"AR","description":"Spedizione arrivata - ROME-ITALY","date":"2022-04-21T10:02:00","notes":"Spedizione arrivata - ROME-ITALY","notFound":false,"internalStatus":14},{"code":"DF","description":"Spedizione in transito - ROME-ITALY","date":"2022-04-21T09:00:00","notes":"Spedizione in transito - ROME-ITALY","notFound":false,"internalStatus":14},{"code":"PL","description":"Spedizione in transito - ROME-ITALY","date":"2022-04-21T06:50:00","notes":"Spedizione in transito - ROME-ITALY","notFound":false,"internalStatus":14},{"code":"AF","description":"Spedizione in transito - ROME-ITALY","date":"2022-04-20T12:57:00","notes":"Spedizione in transito - ROME-ITALY","notFound":false,"internalStatus":14},{"code":"DF","description":"Spedizione in transito - CATANIA-ITALY","date":"2022-04-19T23:14:00","notes":"Spedizione in transito - CATANIA-ITALY","notFound":false,"internalStatus":14},{"code":"PL","description":"Spedizione in transito - CATANIA-ITALY","date":"2022-04-19T20:34:00","notes":"Spedizione in transito - CATANIA-ITALY","notFound":false,"internalStatus":14},{"code":"PU","description":"Spedizione ritirata","date":"2022-04-19T12:36:00","notes":"Spedizione ritirata","notFound":false,"internalStatus":0}]}

So regardless of what you send in the GET request, you're encountering a 500 error within callin.io? And this only happens on this specific GET endpoint, while others function correctly?

I've noticed in the callin.io app development console that the Authorization header is missing the Bearer string preceding the token. While it is present in your callin.io app code, it seems it's not being included in the header. Could you please confirm this?