Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Frequent 403 Errors on Jira API Calls – CloudFront Blocking Requests

avi_paghadar
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 27, 2025

Dear Atlassian Community,

I am frequently encountering a 403 ERROR when making API calls to Jira for creating issues. The error message suggests that the request is being blocked by CloudFront, and I am unable to determine the exact cause.

Issue Details:

  • API Endpoint:  https://wotnot.atlassion.net/rest/api/2/issue
  • Authentication Method: Basic Auth (email + API token)
    • Request Headers:
      {
        "Accept": "application/json",
        "Content-Type": "application/json",
      "X-ExperimentalApi": "opt-in", "X-Atlassian-Token": "no-check" }
  • Error Message (Full Response):
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
    <HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
    <TITLE>ERROR: The request could not be satisfied</TITLE>
    </HEAD><BODY>
    <H1>403 ERROR</H1>
    <H2>The request could not be satisfied.</H2>
    <HR noshade size="1px">
    Bad request.
    We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
    <BR clear="all">
    If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
    <BR clear="all">
    <HR noshade size="1px">
    <PRE>
    Generated by cloudfront (CloudFront)
    Request ID: ojUc0h5IjJKN0XMTBuyYnDzKbtiwU-tc7Xk961rZFVi0NGSZ7K1m8g==
    </PRE>
    </BODY></HTML>

Troubleshooting Steps Taken:

✔ Verified API token and authentication using /myself API (works fine).
✔ Confirmed that my user has Create Issue and Browse Project permissions.
✔ Checked CloudFront request logs but found no specific reasons for blocking.
✔ Disabled VPN and tried different networks, but the issue persists.
✔ Implemented retry logic in case of temporary blocking, but no success.

Request for Assistance:

  1. Is there any known issue with Jira API calls being blocked by CloudFront?
  2. Are there specific rate-limiting rules or security policies that might be causing this?
  3. Would adding specific request headers (e.g., User-Agent) help bypass this issue?
  4. Any suggestions on how to resolve or further debug this?

Any guidance or suggestions would be greatly appreciated!

Best regards,
Avi Paghadar
avi.paghadar@wotnot.io

2 answers

0 votes
Andy Launer
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 14, 2025

Hey Avi,

I do know that Atlassian is currently in the process of transitioning domains like atlassian.net and atlassian.com from Digicert to AWS over the next several months. This transition may be responsible for the intermittent SSL issue you're seeing when your requests resolve to the 13.* addresses.

We recommend that all clients use a standard trust store, such as those provided by Linux, Mozilla, Apple, BSD, or Windows. These trust stores include both "DigiCert Global Root G2" (our previous root) and "Amazon Root CA 1" (our new root).

Certificates required (Both for the moment)

Please see the following changelog for additional details: 

I hope that information helps. 

0 votes
Marc - Devoteam
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 27, 2025

HI @avi_paghadar 

Welcome to the community.

If you have calls that require the experimental option (stated in the documentation), it's best to use an API tool.

Doing this via the command line usually gives these kind of erorrs.

avi_paghadar
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 28, 2025

Hello @Marc - Devoteam  Thank you for your response. I have reviewed your recommendation regarding the experimental API flag, and I want to clarify that I am already passing the required headers in my request. However, I am still encountering the 403 ERROR with a CloudFront response.

Current Request Details:

  • Authorization: Basic Auth (email + API token)
  • Headers Sent:
    {
      "Authorization": "Basic <base64-encoded-token>",
      "X-ExperimentalApi": "opt-in",
      "Content-Type": "application/json",
      "X-Atlassian-Token": "no-check"
    }
  • API Endpoint: https://wotnot.atlassion.net/rest/api/2/issue 
  • Response:
    403 ERROR: The request could not be satisfied.
    Generated by cloudfront (CloudFront)
    Request ID: ojUc0h5IjJKN0XMTBuyYnDzKbtiwU-tc7Xk961rZFVi0NGSZ7K1m8g==
  • Testing Done:
    ✔ Used Postman – Still getting a 403 response.
    ✔ Tried cURL – Also fails.
    ✔ Verified API token is correct (tested with /myself API, which works fine).
    ✔ Tried different networks (VPN off, mobile hotspot, etc.) – Same issue.

Dario Berzano
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 16, 2025

Dear community, @Andy Launer I represent a rather large organization here.

We are encountering the exact same issue on:

https://<our_organization>.atlassian.net/rest/api/3/user/search

The problem we experience is systematic not intermittent. We have mitigated it by retrying our API calls with exponential backoff, but sometimes we need to retry them up to 40 times with an average success rate after 18 attempts(!!!)

This is an automated reporting process we use internally for compliance reasons and we also monitor its success rate over time. Our script started failing systematically after March 25 and now with the mitigation it works but it is much slower and inefficient. It worked perfectly before that date with zero changes from our side.

Needless to say:

  • the API token we use is valid (and it works after several attempts)
  • the response comes from cloudfront (same as the OP said)
  • it happens with different network configurations (including the Azure cloud network where the production application is running)
  • it can be perfectly reproduced using different clients
  • no, it has got nothing to do with SSL certificates and cannot possibly have anything to do with that (we'd be getting a SSL error from our clients before getting any server response - instead, we can establish a SSL connection just to find out that it returns a 403)

Also - nothing in the API documentation says anything about clients being potentially and randomly kicked out of the system.

It would be great if such behavior is documented, along with a clear path to obtain an exemption to such rules, for instance based on the client's IP address.

Thanks for your help!

ben
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 24, 2025

We are also seeeing this issue. 

 

We have tried all propsed solutions and we are still seeing this issue.

 

Please advise.

Dario Berzano
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 24, 2025

Hey - I have eventually contacted Atlassian support directly - and we were advised to check if our HTTP client was accidentally sending non-empty bodies in GET requests.

The HTTP standard says that you must not provide GET requests with any body (just headers). Some other HTTP methods, such as POST, do support bodies instead.

Some servers are "tolerant" and they ignore GET bodies. CloudFront checks the sanity of HTTP requests before they reach Atlassian servers, and it returns a 403 Forbidden in case the request is invalid (400 Bad Request would have been more insightful honestly).

We did check our HTTP GET calls. Indeed - we were, accidentally, sending a non-empty body, in Python it was something like:

requests.request(method='GET', url='https://...', headers=..., json={})

where json={} was the cause of concern and was resulting in a malformed request.

By removing the offending body from all GET requests, we've eliminated the error entirely.

Like Dimitar Grigorov likes this
Dimitar Grigorov
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 13, 2025

Hello and thanks Dario! We stumbled upon the same issue by using python Jira client to connect. It was sending body in a GET request, removing it fixes the issue.

Sharing a link with the commit fix in case someone stumbles on this as well. 
https://github.com/pycontribs/jira.git@3a630c5f1c771fb27b407860d684da879d14e622

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events