@Chris_Knoll I was told you might be able to help me with an issue I’m having with trying to use the ATLAS API to perform a concept search from a script. I’m able to reach concept set endpoint to create a new concept set, but I wanted to search for a concept and /vocabulary/search/[query]/ was the only endpoint that seemed similar. However, I’m getting 401 errors. Is this an authorization issue with our ATLAS instance or could it be due to using the endpoint incorrectly? Any help would be greatly appreciated.
You do have an atlas instance set up? If so you can monitor the web requests from browser to server to understand the requests.
I was looking for the diff between 401 and 403, and i think the 401 indicates you’re not sending an authorization token in the HTTP header. You can look at your own HTTP headers in Chrome dev console as you make the requests to server, and you should see a header for Authorization. Contains a value like Bearer.... But that you were able to create a concept set, it’s interesting that the other endpiont rejects you.
I have been using the browser to monitor the requests and am using the Bearer token like you mentioned. And I’m able to use the search function in the browser so I don’t think it’s a permission issue. Also I was experimenting with the search endpoint trying to model the request after what I saw in the network inspection (base_url/search?query=term) and got a 403 error. But yeah I’m not sure how else to debug it but let me know if you have any thoughts. Thanks!
I got the endpoint to work in a new session and instead of using the WebApi documentation copying the endpoint from the Network tab (something like /vocabulary/{dataset}/search?query={term}) but I think something may be going on with the auth token changing even if I’m in the same ATLAS session. So think I should be ok for now thanks!
So, 403 is different than the 401. 401 means it’s missing auth token. 403 means you have permission denied.
But, looking through the cocebase, i’m not sure the ‘default vocabulary’ search route has permissions set up, so, I would direct the search to the specific source.
Can you check the console again in Atlas: you should see the requested URL of the search something like /vocabulary/{source_key}/search, and this is a POST that sends the search paramaters. You should look at the payload in Chrome for a working example. The endpoint signature is found here (assuming v2.12 from your above screenshot):
But this is different in 2.14:
So your WebAPI version matters. But your best bet is to look at the URL Atlas is requesting and replicate that request in your own HTTP call, and the headers you submit with it matter (such as auth headers).