Issue with API call (download tool)

[CasperSeve]

Hi everyone,

This might be a simple question for some, but I really can't figure this out.

Trying to utilise a download tool to query an API, which I have done with success before with other APIs. However, when I do it with this API, I only get [] back in my DownloadData. I did same query within a test system of the platform, slightly different API URL, but with success in DownloadData.

API documentation

Here is what I get in my DownloadHeaders when I insert my download tool:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Status: 200 OK
Cache-Control: max-age=0, private, must-revalidate
Referrer-Policy: strict-origin-when-cross-origin
X-Robots-Tag: none
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Request-Id: b01bc668-5154-4736-93c4-fbdbe8a328c6
X-Download-Options: noopen
ETag: W/"4f53cda18c2baa0c0354bb5f9a3ecbe5"
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.088935
X-Content-Type-Options: nosniff
Date: Wed, 23 Dec 2020 16:36:17 GMT
Set-Cookie: _mkra_ctxt=dbb96a1da4fb9b2175152ee8ad316ec1--200; path=/; max-age=5; secure; HttpOnly; SameSite=None
Strict-Transport-Security: max-age=16070400
Front-End-Https: on
Content-Encoding: gzip

I have attached some pictures of my workflow and settings below. Just for reference, my authentication is essentially in one of the headers that is used within the DownloadTool (called X-COUPA-API-KEY), I have blurred this for security reasons. The payload setting should be specified in the URL according to the API documentation (as far as I can see and understand).

I did the exact same query in the sandbox system (slightly different URL and another API key), and it returns everything flawlessly.

Can anyone spot if I am doing anything wrong?

Best Regards,

Casper

PS: Happy holidays - stay safe!

[BrandonB]

It looks like for the contracts API they allow two different formats:

https://<instance url>/api/contracts/2
or
https://<instance url>/api/contracts?id=2

Can you try the same call, but instead do a /contracts/27 instead of /contracts?id=27

I am curious if this makes any difference. Also, can you try another API call that uses application/xml for your ACCEPT header to see if returning the xml changes things?

My final thought is maybe the ID 27 doesn't have any contract values? I feel like this likely isn't the case because you are most likely querying it because you know what it should be returning, but it is worth mentioning just in case. It would appear that it is in fact returning a 200 response (which is good), but the download data is an empty array which means there isn't a contract value returned. Hopefully this helps, but happy to brainstorm more if not!

[CasperSeve]

Thanks for replying!

I tried with the elements that you described, but without any luck.

Now comes the funny part. I tried with a different transactional ressource, /api/purchase_orders , and that worked, both with XML and JSON. So there must be something off with the contracts ressource documentation or the API backend permission that is enabled by my organisation. Will have to reach out to the vendor of the system to investigate this further, might have a suspicion that not everything is fully available as it should (even though they told me that everything was 1:1 replica of the sandbox system API).

Thank you once again!

[BrandonB]

Have you also tried other ID’s with the same results? Sometimes vendors will restrict parts of the data based on your licensing with them so that’s a good idea to follow up with their support to confirm it should be returning data. From what I can see it doesn’t look like anything is off other than the empty array being returned. Please keep me updated and Merry Christmas!