[GH-ISSUE #1100] Add check badge URLs to API #763

New issue

Closed

opened 2026-02-25 23:43:30 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 23:43:30 +03:00

Owner

Originally created by @kennethjor on GitHub (Dec 9, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1100

#960 adds badges for individual checks. Thank you for that, it's something I've wanted for a while.

It would be great if the checks (or other) API endpoint returned the URLs for these too.

Originally created by @kennethjor on GitHub (Dec 9, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/1100 #960 adds badges for individual checks. Thank you for that, it's something I've wanted for a while. It would be great if the `checks` (or other) API endpoint returned the URLs for these too.

kerem

2026-02-25 23:43:30 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:43:31 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 11, 2024):

Thanks for the suggestion!

The UUIDs in badge URLs and in the ping URLs are different. This is intentional, we don't want people just with access to a check's badge URL be able to ping the check.

In the database, the UUIDs for badge URLs (Check.badge_key field) are not filled in by default. They are filled in on-demand, when the user selects the check in the "Badges" page.

If we added a new "badge_url" field in the output of the checks API call, it would most of the time be null because the corresponding badge_key is null.

We could have an API call for generating a badge URL for a specific check, perhaps something like:

POST https://healthchecks.io/api/v3/checks/<uuid>/generate_badge_url

This would fill in the check's badge_key field (if it's not filled in already), then put together and return a badge URL. Would something like this be useful?

@cuu508 commented on GitHub (Dec 11, 2024): Thanks for the suggestion! The UUIDs in badge URLs and in the ping URLs are different. This is intentional, we don't want people just with access to a check's badge URL be able to ping the check. In the database, the UUIDs for badge URLs (`Check.badge_key` field) are not filled in by default. They are filled in on-demand, when the user selects the check in the "Badges" page. If we added a new "badge_url" field in the output of the `checks` API call, it would most of the time be null because the corresponding badge_key is null. We could have an API call for generating a badge URL for a specific check, perhaps something like: POST https://healthchecks.io/api/v3/checks/<uuid>/generate_badge_url This would fill in the check's `badge_key` field (if it's not filled in already), then put together and return a badge URL. Would something like this be useful?

kerem commented

2026-02-25 23:43:31 +03:00

Author

Owner

@kennethjor commented on GitHub (Dec 11, 2024):

@cuu508 Personally, if the URL field is only populated after it has been generated, that's fine with me, even if I have to look at it in the UI first.

Is there a reason it's generated on-demand? Why not just always generate it?

@kennethjor commented on GitHub (Dec 11, 2024): @cuu508 Personally, if the URL field is only populated after it has been generated, that's fine with me, even if I have to look at it in the UI first. Is there a reason it's generated on-demand? Why not just always generate it?

kerem commented

2026-02-25 23:43:31 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 27, 2024):

Is there a reason it's generated on-demand? Why not just always generate it?

When I was adding support for per-check badges, it was easier to populate them on-demand, rather than writing a data migration to backfill the existing checks. Plus a slight space saving.

But if we're going to expose badge URLs in API responses, , it would be cleaner and simpler both for the server and the clients to always generate it, rather than have a new API call, and having a sometimes-null field in API responses.

@cuu508 commented on GitHub (Dec 27, 2024): > Is there a reason it's generated on-demand? Why not just always generate it? When I was adding support for per-check badges, it was easier to populate them on-demand, rather than writing a data migration to backfill the existing checks. Plus a slight space saving. But if we're going to expose badge URLs in API responses, , it would be cleaner and simpler both for the server and the clients to always generate it, rather than have a new API call, and having a sometimes-null field in API responses.