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
I think one thing to consider here is whether existing projects will be automatically migrated over.
If its a straight migration and we could keep all the existing badges with a switch to a new API, then you can view qlty as a replacement for CodeClimate.
If existing/legacy projects haven't been migrated over (i.e: I can't just replace my API call to https://api.codeclimate.com/v1/repos?github_slug=codeclimate%2Fcodeclimate with a call to Qlty and get the same results back) then I'd be inclined to just see these as two different services, in which case..
Maybe make new badges for Qlty (if they have a sufficiently stable API and offer a decent rate limit, etc). Consider it on its own merits
Keep the existing CodeClimate badges for as long as they work and retire them if and when the API shuts down
Couple of bits that jump out to me here on rate limits...
The rate limit is 1,000 requests per hour per workspace
I don't really know what "per workspace" means here, but I wonder if this indicates that an API key only lets you see data related to your own account i.e: there's no public data on offer?
Secondly, using data from https://metrics.shields.io/d/aESRBSjmz/services in the last hour (today is a Sunday) we processed 416 requests at the origin for CodeClimate badges. The CodeClimate badges require 2 API calls to get all the data so we probably did 832 requests to CodeClimate's API in the last hour at a non-peak time.
Hello! I'm the CEO of Qlty and happy to help with this.
I am actually wondering if we might be able to simplify and sidestep the API entirely. Right now we render public SVG and PNG badges at predictable URLs. If we exposed the same data powering the badge as JSON (without an API access key, for public repos only), would that provide what you need?
e.g. https://qlty.sh/gh/USERNAME/projects/PROJECTNAME/coverage.json
Reacted by |7eter l-|. l3oling, Christian Emmer, Swastik Pal, Erik Westrup, Pierre-Yves Bigourdan, Kazumi Inada, Master and Max Milton
I don't think that should be an issue on it's own, but I would like to also hear opinion one of our senior devs as I don't think i saw something similar done in the past.
I also have two questions:
Will that path stay open in the long term? We don't want to add a badge with an API that might be short lived.
Will we be able to call it without being blocked by some kind of rate limit? maybe some protection service like cloudflare not take our requests kindly.
Here is an example from ruby-oauth/oauth2:
https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/maintainability.svg https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/maintainability.json
At the moment not exposed
https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/coverage.svg https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/coverage.json
At the moment not exposed
I assume, and correct me if I'm wrong here the JSON would look similar to { label: 'maintainability', message: 'A' } & { label: 'coverage', message: '99%' }
Yes, that is approxiamtely what I am proposing. We would be able to provide a simple spec for a JSON representation of a badge, and it should be as reliable as any JSON API we would provide.
Reacted by Alvis Tang, Pierre-Yves Bigourdan, Kazumi Inada and Master
Thanks. Having a custom endpoint for this sounds good. Particularly if there is a public endpoint that returns data for any public projects and we don't need to implement auth to call it. In general, our guidance says we should use documented public APIs but what we really care about is using APIs that we're allowed to use and that aren't going to change under us.
There's a few other projects where we use a special endpoint just for badges. For example coderabbit, coverity, docs.rs etc.
An alternative would be to scratch the SVG of the public qlty.sh badges. It's not our preferred approach in terms of performance and maintainability, but we already do this in a number of places via BaseSvgScrapingService.
@brynary can we go forward with the JSON API? as it seems to be a preferred method.
I'm thankful for you offering us an endpoint we can use, please let me know if the offer to add this endpoint is still valid.
Reacted by Pierre-Yves Bigourdan, Erik Westrup and Master
As far as I can tell, projects haven't been migrated over. Hitting the new qlty.sh API with public projects that were previously integrated with Code Climate returns 500 "Internal Server Error" responses. The docs have mentions of "If you are already using Code Climate Quality, please contact us for migration assistance", suggesting this requires users to onboard onto a brand new service.
We're essentially in the present case:
If existing/legacy projects haven't been migrated over (i.e: I can't just replace my API call to https://api.codeclimate.com/v1/repos?github_slug=codeclimate%2Fcodeclimate with a call to Qlty and get the same results back) then I'd be inclined to just see these as two different services, in which case..
Maybe make new badges for Qlty (if they have a sufficiently stable API and offer a decent rate limit, etc). Consider it on its own merits
Keep the existing CodeClimate badges for as long as they work and retire them if and when the API shuts down
I'll submit a PR for deprecating Code Climate badges. Anyone can feel free to contribute new qlty.sh badges, either by leveraging BaseSvgScrapingService, or waiting until we get news about the new API @brynary mentioned.
Activity
jNullj commentedon Jul 5, 2025
official announcement for the change
As for the API, it seems to differ from existing code and requires us to contact qlty for authenticate tokens as well.
I sent them a message and will update as things progress.
chris48s commentedon Jul 6, 2025
The existing CodeClimate badges do appear to still be working
I think one thing to consider here is whether existing projects will be automatically migrated over.
If its a straight migration and we could keep all the existing badges with a switch to a new API, then you can view qlty as a replacement for CodeClimate.
If existing/legacy projects haven't been migrated over (i.e: I can't just replace my API call to https://api.codeclimate.com/v1/repos?github_slug=codeclimate%2Fcodeclimate with a call to Qlty and get the same results back) then I'd be inclined to just see these as two different services, in which case..
Couple of bits that jump out to me here on rate limits...
Firstly, https://docs.qlty.sh/api-reference/api-overview/introduction#rate-limiting says
I don't really know what "per workspace" means here, but I wonder if this indicates that an API key only lets you see data related to your own account i.e: there's no public data on offer?
Secondly, using data from https://metrics.shields.io/d/aESRBSjmz/services in the last hour (today is a Sunday) we processed 416 requests at the origin for CodeClimate badges. The CodeClimate badges require 2 API calls to get all the data so we probably did 832 requests to CodeClimate's API in the last hour at a non-peak time.
jNullj commentedon Jul 8, 2025
Just an update. I contacted Qlty they pointed me at the right place to ask for an API key.
I sent a mail with some details and questions.
Will update once we have an answer to one of the questions mentioned here.
brynary commentedon Jul 8, 2025
Hello! I'm the CEO of Qlty and happy to help with this.
I am actually wondering if we might be able to simplify and sidestep the API entirely. Right now we render public SVG and PNG badges at predictable URLs. If we exposed the same data powering the badge as JSON (without an API access key, for public repos only), would that provide what you need?
e.g.
https://qlty.sh/gh/USERNAME/projects/PROJECTNAME/coverage.jsonjNullj commentedon Jul 9, 2025
I don't think that should be an issue on it's own, but I would like to also hear opinion one of our senior devs as I don't think i saw something similar done in the past.
I also have two questions:
Here is an example from
ruby-oauth/oauth2:https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/maintainability.svghttps://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/maintainability.jsonAt the moment not exposed
https://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/coverage.svghttps://qlty.sh/badges/d3370c2c-8791-4202-9759-76f527f76005/coverage.jsonAt the moment not exposed
I assume, and correct me if I'm wrong here the JSON would look similar to
{ label: 'maintainability', message: 'A' }&{ label: 'coverage', message: '99%' }brynary commentedon Jul 10, 2025
Yes, that is approxiamtely what I am proposing. We would be able to provide a simple spec for a JSON representation of a badge, and it should be as reliable as any JSON API we would provide.
chris48s commentedon Jul 12, 2025
Thanks. Having a custom endpoint for this sounds good. Particularly if there is a public endpoint that returns data for any public projects and we don't need to implement auth to call it. In general, our guidance says we should use documented public APIs but what we really care about is using APIs that we're allowed to use and that aren't going to change under us.
There's a few other projects where we use a special endpoint just for badges. For example coderabbit, coverity, docs.rs etc.
PyvesB commentedon Sep 28, 2025
An alternative would be to scratch the SVG of the public qlty.sh badges. It's not our preferred approach in terms of performance and maintainability, but we already do this in a number of places via
BaseSvgScrapingService.jNullj commentedon Sep 28, 2025
@brynary can we go forward with the JSON API? as it seems to be a preferred method.
I'm thankful for you offering us an endpoint we can use, please let me know if the offer to add this endpoint is still valid.
PyvesB commentedon Nov 2, 2025
It looks like the old Code Climate API was sunset a week ago. https://api.codeclimate.com/v1/repos?github_slug=codeclimate%2Fcodeclimate and similar endpoints are now redirecting to the qlty.sh documentation. This means that all existing Code Climate badges have broken.
As far as I can tell, projects haven't been migrated over. Hitting the new qlty.sh API with public projects that were previously integrated with Code Climate returns 500 "Internal Server Error" responses. The docs have mentions of "If you are already using Code Climate Quality, please contact us for migration assistance", suggesting this requires users to onboard onto a brand new service.
We're essentially in the present case:
I'll submit a PR for deprecating Code Climate badges. Anyone can feel free to contribute new qlty.sh badges, either by leveraging
BaseSvgScrapingService, or waiting until we get news about the new API @brynary mentioned.heliocarlitos commentedon Feb 15, 2026
Remove Code Climate badge from README
Remove Code Climate badge from README
Remove Code Climate badge from README
Remove Code Climate badge from README
Remove Code Climate badge from README
Remove Code Climate badge from README
Remove Code Climate badges from README