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): ERROR: The request could not be satisfied 403 ERROR The request could not be satisfied. 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. If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. Generated by cloudfront (CloudFront) Request ID: ojUc0h5IjJKN0XMTBuyYnDzKbtiwU-tc7Xk961rZFVi0NGSZ7K1m8g== 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: * Is there any known issue with Jira API calls being blocked by CloudFront? * Are there specific rate-limiting rules or security policies that might be causing this? * Would adding specific request headers (e.g., User-Agent) help bypass this issue? * 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

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

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.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Frequent 403 Errors on Jira API Calls – CloudFront Blocking Requests

avi.paghadar

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",<br>   "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:

Is there any known issue with Jira API calls being blocked by CloudFront?
Are there specific rate-limiting rules or security policies that might be causing this?
Would adding specific request headers (e.g., User-Agent) help bypass this issue?
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

Accepted answers

All comments

Marc -Devoteam-

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

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.

Andy Launer

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)

AWS CA roots Amazon Trust Services Repository
Digicert Roots DigiCert Root Certificates - Download & Test

Please see the following changelog for additional details:

CHANGE-2364 - Jira and Confluence Cloud APIs add Amazon Root CA 1 as a root certificate

I hope that information helps.

Dario Berzano

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_ydnhqe

We are also seeeing this issue.

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

Please advise.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud