401error when using AutoRest connection as external system for Zendesk API

Marco_13112001

Good Afternoon,

I've created an Autonomous Rest connection and I'm able to access the tables, however when moving to the define settings step inside of the add dataset functionality, I'm getting the following error message.

[ApertureDataStudio][AutoREST JDBC Driver][AutoREST]REST Status 401 Unauthorized returned for GET https://xxxxxxxxxxxxxxxxxxxxxxxxx/api/v2/ticket_fields in statement [SELECT "TICKET_FIELDS_COUNT","TICKET_FIELDS_1_POSITION","POSITION","ID","NAME","RAW_NAME","VALUE","DEFAULT_" FROM "CUSTOM_FIELD_OPTIONS"]

Am I missing a step on the REST setup?

Many thanks in anticipation

Marco

Henry Simms

The error suggests that the user being used to make the call (looks like email and password auth for the Zendesk API) doesn't have the right permissions.

Are you able to make the same List Ticket Fields call from cURL, Postman, or similar, using the same credentials?

The list of tables and table schemas you see in the Data Studio UI are saved offline in the .rest config file, so the fact that these are showing doesn't guarantee access. The API is only called (with stored credentials) at the point where the Next: Define Settings button is clicked.

Henry Simms

I've set up an example connection to the Zendesk API from Data Studio, using Zendesk's Basic auth.

I started by using the Autonomous REST Connector, as described in this OData article.

I sampled just the /api/v2/ticket_fields endpoint for the purpose of this example, but typically you would sample all the endpoints you needed. This created the attached .rest file (which I've added the .txt extension to, to allow it to be uploaded). You would need to enter your own Zendesk URL into this file.

In Data Studio I have the External System configured as follows, the REST configuration file pointing to the .rest file I created in the Composer, and "Basic" as the Authentication Method.

This setup then allows me to load data from Zendesk's API:

Zendesk_basic_ticket_fields.rest.txt

Marco_13112001

@Henry Simms Thanks for the response. Yes, I can make the call using Postman without issues. Also, I'm not adding the credentials to the rest config file but adding them on the user connection properties. Should it be added to the rest file instead? or the keys should be named differently?

Marco_13112001

@Henry Simms Thanks for you support. Yes, the process that you described was the same one that I've used originally and even used your rest file but still getting the same 401 error. The way you have connected was exactly what we did for the sandbox however it is not working for the live environment. Is there anything that we could try?

Henry Simms

It's a strange one. The driver is definitely making contact with the Zendesk API - If it can't be reached you just get a "No rows detected" error - So I assume it's a genuine 401 Unauthorized. But why you would get this response from one environment and not another is unclear.

To confirm, you should be passing username and password in the Credentials (not in connection properties).

When you moved your solution from Sandbox to Prod, was it by exporting a dmx or dmxd file that included the External System and Credential? The reason I ask is that when exporting or importing credentials, the password and user permissions are not included, and you would need to edit the Credential to re-add the password.

Marco_13112001

@Henry Simms We still working in the Aperture Dev. The sandbox I've mentioned was the Zendesk one; we've made the connections to it first and them within the Aperture Dev we are trying to connect with Zendesk live, and there is the point of failure. I've been looking at the Zendesk API documentation and they instructed to use a base64-encoding for the credentials when adding it to the rest script, do you have any syntax standards i.e. the user credential should be called username, that I must follow when creating the script in the composer?

Marco_13112001

@Henry Simms Good morning and good news. I've retraced the whole process and found out that we had an case issue on the Aperture password credentials (human error). Many thanks again for your support.