You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Question][Jira Connection] JiraCloud connection uses api/2 as endpoint #8709
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.
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:
Make sure your container or host has up-to-date CA certificates (install/update the ca-certificates package).
From inside the container or host, run curl https://sartorius.atlassian.net to check if you get the same certificate error.
If your network uses a proxy or SSL inspection, add the proxy’s CA certificate to the trust store.
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).
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.
This issue has been automatically marked as stale because it has been inactive for 60 days. It will be closed in next 7 days if no further activity occurs.
Activity
dosubot commentedon Feb 11, 2026
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 authorityis 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:ca-certificatespackage).curl https://sartorius.atlassian.netto check if you get the same certificate error.IN_SECURE_SKIP_VERIFY=trueto 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.
Docs are dead. Just use Dosu.
ajoecker1 commentedon Feb 11, 2026
@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 commentedon Feb 11, 2026
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.
Docs are dead. Just use Dosu.
github-actions commentedon Apr 13, 2026
This issue has been automatically marked as stale because it has been inactive for 60 days. It will be closed in next 7 days if no further activity occurs.
github-actions commentedon Apr 20, 2026
This issue has been closed because it has been inactive for a long time. You can reopen it if you encounter the similar problem in the future.