fetch_survey produces "Error: Qualtrics API raised a bad request (400) error" about qualtrics HOT 5 CLOSED

Hello @kerem-a! There are two common issues that cause folks to run into this error.

• The first is not having your base URL set correctly. Notice that when you register your credentials:

The base URL you pass to the qualtRics package should either look like yourdatacenterid.qualtrics.com or like yourorganizationid.yourdatacenterid.qualtrics.com

• The second is Qualtrics proxying your request. Do you see any messages about this? For example, what do you see when you run this at the command line (not in R)?

curl --request GET \
--url https://XXX.qualtrics.com/API/v3/whoami \
--header 'x-api-token: YOURLONGAPITOKENHERE'

You would need to use your URL and your API token. Do you see anything in the results like:

Notice: Request proxied. For faster response times, use this host instead:

• Another thing to try -- can you run this code to see a bit more detail about what is happening?

## put your survey ID here:
fetch_url <- qualtRics::generate_url(query = "fetchsurvey", surveyID = "SV_xxx")
raw_payload <- qualtRics:::create_raw_payload(
    label = TRUE,
    start_date = NULL,
    end_date = NULL,
    limit = NULL,
    time_zone = NULL,
    unanswer_recode = NULL,
    unanswer_recode_multi = NULL,
    include_display_order = TRUE,
    include_questions = NULL,
    breakout_sets = NULL
)

res <- qualtRics:::qualtrics_api_request("POST", url = fetch_url, body = raw_payload)
res$meta
#> $requestId
#> [1] "f52b2929-b24a-4c9d-88a6-e7c9d3ff660d"
#> 
#> $httpStatus
#> [1] "200 - OK"

^{Created on 2022-04-04 by the reprex package (v2.0.1)}

from qualtrics.

Thank you for your fast reply,
After taking a more careful look, I realized that I used the "Organization ID" instead of the Datacenter ID in the base_url value. Replacing this value fixed the issue with fetch_survey.

I'm not sure if it makes sense, but this code:
fetch_url <- qualtRics::generate_url(query = "fetchsurvey", surveyID = "SV_XXX")
still throws an error even after replacing the base_url with the correct one.

<error/rlang_error>
Error in `qualtRics::generate_url()`:
Internal error: invalid URL generation query

Backtrace:
    x
 1. \-qualtRics::generate_url(query = "fetchsurvey", surveyID = "SV_9BUaLjV9ztl7Tjo")
 2.   \-rlang::abort("Internal error: invalid URL generation query")

But I guess you can close the issue anyway.
On a side note, perhaps it's a good idea to add something to this error message, like:
" 'Did you set the URL correctly? Remove the 'https://' and use the Organization ID (not the Datacenter ID).'"

Thank you very much for this handy package!

from qualtrics.

@juliasilge this seems like something that shows up pretty often as a point of user confusion--maybe we could find a more user-friendly approach to configuration?

The screenshot above--a dropdown from one of the API testing modules at api.qualtrics.com--is, I think, all the datacenters that Qualtrics has? And, if you click through them, just below this you see each's associated string prefix that would go in xxxx.qualtrics.com. What if we deprecated the base_url arg in favor of datacenter_id in the credentials function, which then checks whether it receives one of the strings found here?

While I'm at it, something like that could pave the way for an extra string option like "mock", which would then configure to use the mocking server. Thinking that probably makes sense as a direction to go for tests, vs. saved VCR's of normal accounts like we currently do--but, implementing that under our current URL generation scheme would require some super kluge-y changes.

(Throw it on the pile, I know; I've been too buried to do development here for a while now. I haven't forgotten, though!)

from qualtrics.

Oh gosh, being able to test against their mock server would be huge. I think this could be a really good way to go; this is a fantastic idea @jmobrien. 👍

from qualtrics.

👍

Realistically, doing it right entails a bit of a re-build of URL generation, perhaps scrapping much of the generate_url() system I set up. The idea was to give us better modularity & extensibility (and maybe it did a bit), but knowing what I do now I would do it differently today. I think it's already gotten a bit unwieldy, while also mostly locking us out of some important flexibility, especially w/r/t mocking.

from qualtrics.