403 error when creating request via API

@Thomas Verschoren 

Yea it's giving me the correct value. I also tried encrypting the whole thing and just pasting it but it's still giving me the error message.

Could you think of anything else? I'm just lost since it's working on Postman

I also tried your code but it gave me the same error.

Hey, 

So I did that. It matches what I used. email/token:api_token.

Are you using this code in Zendesk or an external app?

Is it possible that the authentication is somehow clashing with the current logged in user?

Should the code then be different if using this within zendesk?

Hey @Thomas Verschoren,

I think it's an issue with the logged in user or the session...

I tried logging out of Zendesk and tried the exact code on the browser console and it worked...

Any idea why this is the case?

Thanks

Hey,

I am not making an external app. I'm doing this within our Zendesk Portal using the templates (e.g. new_request_page.hbs). Base on my understanding, ZAFClient is used when building an external app that incorporates Zendesk support? 

My issue is when doing this in Zendesk Portal itself. Also the 404 error only appears when doing a POST request.

Bonaliza, where you able to find a solution for this? I'm having the same issue. 

Same issue here, not sure what to do...

This is likely caused by a clash with how the fetch API handles cookies in the context of the Help Center, when logged in as an agent or admin. You can use the /api/v2/users endpoint to obtain an authenticity (CSRF) token which should fix the issue. Here’s an example of how that could look:
 

fetch("/api/v2/users/me")
.then((data) => {
  return res = data.json();
})
.then((res) => {
  const authToken = res.user.authenticity_token;

  let myHeaders = new Headers();
  myHeaders.append(
    "Authorization",
    "Basic btoa(email/token:API_Token)"
  );
  myHeaders.append("Content-Type", "application/json");
  myHeaders.append("X-CSRF-Token", authToken);

  const raw = JSON.stringify({
      "request": {
        "requester": { "name": "Jane Smith", "email": "jane@example.com" },
        "subject": "TESTING API!",
        "comment": { "body": "My printer is on fire!" },
      },
    });

  const requestOptions = {
    method: "POST",
    headers: myHeaders,
    body: raw,
    redirect: "follow",
  };

  fetch("/api/v2/requests", requestOptions)
    .then(response => response.text())
    .then(result => console.log(result))
    .catch(error => console.log("error", error));
});

 
I hope this helps! Feel free to reach out with any questions.
 
Tipene

@Tipene Hughes 

I used this code, but I still does not solve my issue. 

I am using end user to login in zendesk, using email/token: token to post an API, I still get the error message:"error: {title: "Forbidden", message: "Invalid authenticity token"}".

Here is my code snippet:

Can you help check whether there is something wrong? 

fetch("/api/v2/users/me")
        .then((data) => {
            return res = data.json();
        })
        .then((res) => {
            const authToken = res.user.authenticity_token;
            console.log(authToken);
            let myHeaders = new Headers();
            myHeaders.append(
                    "Authorization",
                    "Basic xxxxxxxxxxxxxxxxxxxx"
            );
            myHeaders.append("Content-Type", "application/json");
            myHeaders.append("X-CSRF-Token", authToken);
            const raw = JSON.stringify({
               "organization": {
                        "name": "ttt"
               }
            });
            const requestOptions = {
                method: "POST",
                headers: myHeaders,
                body: raw,
                redirect: "follow",
            };
            fetch('/api/v2/organizations', requestOptions)
                    .then(response => response.text())
                    .then(result => console.log(result))
                    .catch(error => console.log("error", error));
        });

Can anyone help me? I am not sure what to do now.

@tipene @pan12 I'm getting the same "Invalid authenticity token" error.

I sent a request to Zendesk support 2 days ago, but haven't received a reply yet.

@andrey24

Hi  have you received response from Zendesk support? Can you share it to me? Thanks.

@pan12 still troubleshooting it with Zendesk support. I'll write you once the issue is resolved.

I am having this error 403 when I am trying to log in into my account as AGENT. I go until the second step verification and then it goes to the error 403. How Can I correct it and log in??

@pan12 Your issue seems to be related to the organizations api end point. According to the documentation you need to be an admin to create organizations. If an end user tries this, then they shoudn't have the required permissions to do so.

@tipene Your approach looks nice. I didn't know about the x-csrf-token header. I think the authenticity_token property should be included in the JSON format of the user documentation.

I tried it but it sadly didn't work for me. I checked in the developer console > network what the request looks like. The basic authentication and x-csrf-token match with the data I'm plugging in but I still get a 403 error.

I'm sending the request through a ReactJS app and Axios in our Help Center.

This error indicates that the server has determined that you are not allowed access to the thing you've requested, either on purpose or due to a misconfiguration . It's probably because the site owner has limited access to it and you don't have permission to view it. The vast majority of the time, there's not much you can do to fix things on your (*client) end. There are four common causes for 403 Forbidden error (server side) . Here they are listed from most likely to least likely:

• An empty website directory
• No index page
• Incorrect settings in the .htaccess file
• Permission / Ownership error

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

Hi Ahmed! A 403 is an indication that you don't have access to the resource. Do you have different permissions in the other instance?

Have you enabled agent access to create requests in this new instance? If not, here are the instructions on how to do so. Let me know if that works for you!

@ahmed11

I had this same issue and I had a very lenghty discussion regarding this with the Support team. I solved this issue by making all API requests to the main brand instead of the sub-brand (in my opinion API documentation says otherwise so this behavior is not as expected). Then it will work as it should. I have set up a trigger that fires on ticket creation to set the respective brand for the ticket so that it will be visible for the end user inside of Guide. You can use e.g. the title of the ticket to filter for the right brand if you are setting it programmatically.

@ahmed11

Yes, we are also unsure on how to do the authentication across brands right. We got it working for now on our end, but the comments are still being shown as "User was not logged in when the comment was submitted". Even though we use authentication.

To get it working, we did the following way (which at least works for now). Maybe you have another breakthrough:

1. Visitor is on Help Center of Brand B
2. If the visitor goes to the the custom contact forms a check is performed if the user is logged in (via the window object HelpCenter.user; If the user is not logged in, his role will be anonymous)
3. If the visitor is logged in, display the custom contact forms, which the visitor can select and fill in
4. On submit, the following http requests happen:
5. GET Brand A.zendesk.com/api/v2/users/me (using the visitors email address from HelpCenter.user.email and API token)
6. POST Brand A.zendesk.com/api/v2/requests (using the auhtenticity_token)

When we tried the subdomain Brand B on step 5, we got a 403 error.

In addition, we got the 403 when we did step 5 and 6 with the Brand B subdomain as well (we thought this was the way you're supposed to do it).