Community
Q&A
Jira
Questions
Intermittent HTTP 400 Bad Request from Jira REST API (/rest/api/3/issue/)

Intermittent HTTP 400 Bad Request from Jira REST API (/rest/api/3/issue/)

Hi everyone,

I'm currently working on an integration with the Jira REST API and encountered intermittent 400 BAD_REQUEST responses when trying to create issues using the following endpoint:

https://***.atlassian.net/rest/api/3/issue/
The response returned is an HTML error page: HTTP Status 400 – Bad Request

<!doctype html><html lang="en"><head><title>HTTP Status 400 – Bad Request</title><style type="text/css">body {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b {color:white;background-color:#525D76;} h1 {font-size:22px;} h2 {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a {color:black;} .line {height:1px;background-color:#525D76;border:none;}</style></head><body><h1>HTTP Status 400 – Bad Request</h1></body></html>

This issue is intermittent: the integration works normally for some time, then starts returning `400 Bad Request` responses, and later recovers automatically without any configuration or code changes.

Some additional context:

The call is performed from an external integration system.
Jira logs show that the request reaches Jira and Jira immediately returns HTTP 400.
No additional internal Jira traces/errors are generated after that.
The request size is around 19 KB.

Has anyone experienced a similar intermittent issue when calling Jira APIs from external systems?

Any insights, recommendations, or debugging suggestions would be greatly appreciated.

Thanks in advance.

1 answer

0 votes

The HTML body on a 400 is the most useful clue. Jira's REST API returns JSON when it rejects a request at the application layer, with response headers including x-arequestid and x-ausername. HTML means your request isn't reaching Jira itself; it's being rejected upstream at the edge layer.

Next time it happens, grab x-arequestid and x-ausername from the failing response. The first is what Atlassian Support uses for tracing. The second reads anonymous if your auth state was lost (Jira sometimes returns 400 instead of 401 when that happens).

Things I'd try before opening a ticket:

Reproduce with summary and description stripped of any user-supplied text. If it stops failing, a WAF content rule is firing on the payload.
Check whether the failures correlate with bursts. Cloud rate limits are per-user and per-IP, and parallel workers or retry storms produce exactly this intermittent pattern.
If you're authenticating with a session cookie, switch to Basic auth with email + API token. Cookie sessions expire and the failure mode is intermittent.

If it keeps happening with HTML responses, open a ticket with a captured x-arequestid. Customers can't see the edge logs, only Atlassian can.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Thank you for your response.

I would like to provide some additional information that may be relevant.

The Jira team shared the following trace for one of the failed requests:

http_backend_host: ***.atlassian.net http_host: ***.atlassian.net http_user_agent: Apache-HttpClient/5.4.3 (Java/21.0.11) http_version: HTTP/1.1 request_method: POST request_principal: ari:cloud:identity::user/***:2fd4f6d7-7cc1-48f7-b6c3-9e7a66258023 request_size: 18943 request_time: 0.002 request_timestamp_msec: 1779690292.674 response_duration: 0.002 sampled: 1 src_ip: 10.255.0.18 status: 400 time: 2026-05-25T06:24:53.491090179Z uri_path: /rest/api/3/issue/

They indicated that there is only a single trace recorded on the Jira side and no additional internal traces after the 400 response.

We also performed additional tests using a REST client (e.g. Bruno). Interestingly, when sending multiple requests within a short period of time, the first few requests succeed, but after 2–3 successful calls, one of the subsequent calls may fail with the same HTTP 400 Bad Request response.

Have you seen similar behavior related to:

* rate limiting,
* request throttling,
* temporary request filtering,
* or connection/session handling?

Could such mechanisms return an HTML 400 response before the request reaches the Jira application layer?

Any guidance would be appreciated.

Thank you.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi @Germán Morales _ Hiera ,
I have some additional information from the Jira logs that may help with the investigation.

One of the failing requests contains the following fields:

http_host: **.atlassian.net
http_user_agent: Apache-HttpClient/5.4.3 (Java/21.0.11)
http_version: HTTP/1.1
http_x_forwarded_for: 18.193.50.255, 10.16.111.127, 10.16.199.129, 10.26.53.87
request_id: ba2c12f7-cf6d-4911-8e41-8c1e3679f59b
request_method: POST
request_principal: ari:cloud:identity::user/**
request_size: 17832
request_time: 0.002
request_timestamp_msec: 1780399017.992
response_duration: 0.002
sampled: 0
status: 400
too_many_connections_reached:
trace_id: bebdffcb65714bec4f86d9675940bd08
uri_path: /rest/api/3/issue/16320812/transitions

What caught my attention is the presence of the field:

`too_many_connections_reached`

Could anyone help explain the meaning of this field?

The issue is intermittent and we have observed periods where multiple requests succeed, followed by failures returning HTML 400 responses.

Any insight into the meaning of `too_many_connections_reached` would be greatly appreciated.

Thank you.

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Hi @ibtissem cherni, too_many_connections_reached isn't a publicly documented field, so I can't give you its official definition; only Atlassian can confirm what it means against your trace. But the name, plus your Bruno test where a few rapid calls succeed and then one fails, points at Atlassian's concurrency limiting rather than the hourly points budget. Cloud enforces a ceiling on simultaneous in flight requests per tenant (not configurable, and the threshold is dynamic) and a separate per second burst limit applied per endpoint, so concurrent or bursty calls get rejected even when the same volume sent one at a time goes through.

The catch worth raising with Support: those limits are documented to return 429, not 400. The HTML 400 you're seeing is non standard for rate limiting, and that mismatch is exactly what to ask them to explain using request_id ba2c12f7-cf6d-4911-8e41-8c1e3679f59b and trace_id bebdffcb65714bec4f86d9675940bd08. The HTML body (not JSON) and the 0.002s response_duration both confirm the rejection happens at the edge before it reaches Jira, which fits that flag.

On your side, since you're on Apache HttpClient 5.4.3, the things most likely to stop it:

Cap the connection pool low (maxConnPerRoute and maxConnTotal around 5 to 10) so you never fan out enough parallel connections to hit the ceiling.
Make sure every response entity is fully consumed and closed (EntityUtils.consume, or try with resources). An unreleased response holds the connection open, they accumulate under load, and they free only when they time out, which matches the automatic recovery you described.
Serialise or throttle the create and transition calls and add exponential backoff with jitter on any 4xx, instead of sending them in parallel.

Background on the burst versus points limits and the backoff strategy is here: Rate limiting (Jira Cloud platform)

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

A pop-up survey could appear while you're here --curious what it's for? Click here to learn more!

Forums

Q&A

Community resources

Support

Top groups

Community resources

Support

Learn

Community resources

Support

Events

Community resources

Support

Intermittent HTTP 400 Bad Request from Jira REST API (/rest/api/3/issue/)

1 answer

Suggest an answer

Was this helpful?

Thanks!

DEPLOYMENT TYPE

TAGS

Community showcase

Atlassian Community Events