[Question][Jira Connection] JiraCloud connection uses api/2 as endpoint

[ajoecker1]

Question

I try to set up a JIRA Cloud connection for our cloud instance. So I use https://xxx.atlassian.net/rest/ as the endpoint and give the credentials.

When I test the connection, it fails with the following message
Get "https://xxx.atlassian.net/rest/api/2/serverInfo": tls: failed to verify certificate: x509: certificate signed by unknown authority

For all our other JIRA api connections (outside of DevLake), the URL we are using is https://xxx.atlassian.net/rest/api/3/ so we are using another version than devlake and I assume the error comes from using 2 instead of 3.

Can I configure this somehow ? Because giving the full URL _https://xxx.atlassian.net/rest/api/3/ is also not working, as it simply adds the /api/2 at the end.

Screenshots

If applicable, add screenshots to help explain.

Additional context

Add any other context here.

[dosubot]

DevLake automatically selects the correct Jira API version for Cloud (using /api/3) in versions v1.0.3-beta5 and later—there’s no user-facing setting to manually change the API version, and providing the full /api/3 endpoint won’t override this logic. If you’re seeing DevLake use /api/2, you likely need to upgrade to at least v1.0.3-beta6 to get proper Jira Cloud support and endpoint selection (source).

The TLS error x509: certificate signed by unknown authority is unrelated to the API version. It means the environment where DevLake is running doesn’t trust the SSL certificate from Jira—usually because of missing or outdated CA certificates, or SSL interception by a proxy/firewall (source). To fix this:

1. Make sure your container or host has up-to-date CA certificates (install/update the ca-certificates package).
2. From inside the container or host, run curl https://sartorius.atlassian.net to check if you get the same certificate error.
3. If your network uses a proxy or SSL inspection, add the proxy’s CA certificate to the trust store.
4. Only as a last resort, set the environment variable IN_SECURE_SKIP_VERIFY=true to bypass certificate checks (not recommended for production) (source).

Also, make sure your Jira endpoint in DevLake ends with /rest/ (not /rest/api/3/), so DevLake constructs the correct API URLs and avoids hitting non-API endpoints that can cause redirects or TLS errors (source).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[ajoecker1]

@dosu thanks for the answer. I will try the suggestion you mentioned.

but regarding the advice to use v1.0.3-beta6, I use devlake:v1.0.3-beta9 and it uses the /api/2 ?!

[dosubot]

You're right—DevLake v1.0.3-beta9 can still use the /api/2 endpoint for Jira Cloud due to a bug in how it detects the deployment type. The code compared the deployment type in a case-sensitive way, so Jira Cloud (which returns "Cloud") was sometimes misidentified as a Server, causing DevLake to use the deprecated /api/2 endpoint instead of /api/3. This was fixed after v1.0.3-beta9 in PR #8608, which made the comparison case-insensitive and ensured Jira Cloud always uses /api/3.

To resolve this, upgrade to a version newer than v1.0.3-beta9 that includes this fix. There’s no workaround or config option in v1.0.3-beta9 to force the API version—it’s handled internally by DevLake’s logic.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}