[GH-ISSUE #986] New type of API key: read-only, but returns check and channel UUIDs

kerem commented

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

Owner

Originally created by @ThomasKwan-shopline on GitHub (Apr 9, 2024).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/986

Hi, I am using kristofferahl/healthchecksio with terraform to create healthcheck by terraform. I want engineer can self-plan with read-only api key (giving full permission api key is danger), but the read only api key just give limited information. Can healthchecks have a new feature that provide a read-only api key that have a same schema with full permission api key?

Remark

From the response of “List existing checks”, here are the different between both response

“pause_url”, “ping_url”, “resume_url” and “channels” is missing in read-only api key but appear in read-write api key
“unique_key” is missing in read-write api key but appear in read-only api key

Originally created by @ThomasKwan-shopline on GitHub (Apr 9, 2024). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/986 Hi, I am using [kristofferahl/healthchecksio](https://registry.terraform.io/providers/kristofferahl/healthchecksio/latest/docs) with terraform to create healthcheck by terraform. I want engineer can self-plan with read-only api key (giving full permission api key is danger), but the read only api key just give limited information. Can healthchecks have a new feature that provide a read-only api key that have a same schema with full permission api key? ### Remark From the response of “List existing checks”, here are the different between both response - “pause_url”, “ping_url”, “resume_url” and “channels” is missing in read-only api key but appear in read-write api key - “unique_key” is missing in read-write api key but appear in read-only api key

kerem

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

closed this issue
added the
feature
label

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Apr 10, 2024):

Hello Thomas, can you describe a little more what issue you are hitting with the read-only/full API key schema differences?

The idea with the read-only keys is to not return any data that would allow altering the state of the checks. It is meant to be used in low-trust and no-trust environments, for example, for building status dashboards for unauthenticated users. The read-only responses must not contain check UUIDs, because with the knowledge of the UUID anybody could construct the full ping URL and mess with your monitoring.

@cuu508 commented on GitHub (Apr 10, 2024): Hello Thomas, can you describe a little more what issue you are hitting with the read-only/full API key schema differences? The idea with the read-only keys is to not return any data that would allow altering the state of the checks. It is meant to be used in low-trust and no-trust environments, for example, for building status dashboards for unauthenticated users. The read-only responses must not contain check UUIDs, because with the knowledge of the UUID anybody could construct the full ping URL and mess with your monitoring.

kerem commented

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

Author

Owner

@ThomasKwan-shopline commented on GitHub (Apr 11, 2024):

Sure,

As I mention before, we are using terraform with kristofferahl/healthchecksio for healthchecks.io iac which is suggest by healthchecks.io

In our use case, my company will run some custom pipeline for plan and apply terraform. Now only approved engineer can trigger those pipeline since it involve productoin env read-write api key and we dont want other engineer can use this key. However, it make approved engineer always need support other engineer to run the terraform plan.

To solve this problem, we hope to allow other engineer use the read-only api key for terraform plan, because they cannot modify any healthchecks.io resource by using read-only api key. By studying the terraform provider and healthchecks.io doc, I found it is impossible. because It missing two information, uuid and channels.

So we hope to have a new type of api key, that is read-only but have the same schema with read-write api key, so we can just easily to apply the new type api key to terraform and the problem solve.

some poc by using this terraform provider

Before test
Create a healthcheck by using terraform

Run terraform plan with read-write api key

TF_VAR_healthchecksio_api_key="<read-wirte api key>" TF_LOG="" terraform plan
healthchecksio_check.testing_healthcheck: Refreshing state... [id=<healthcheck id>]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Run terraform plan with read-only api key

TF_VAR_healthchecksio_api_key="<read-only api key>" terraform plan
healthchecksio_check.testing_healthcheck: Refreshing state... [id=<healthcheck id>]

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan:

  # healthchecksio_check.testing_healthcheck has been deleted
  - resource "healthchecksio_check" "testing_healthcheck" {
      - id        = "<healthcheck id>" -> null
        name      = "testing-check"
        # (6 unchanged attributes hidden)
    }


Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following
plan may include actions to undo or respond to these changes.

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following
symbols:
  + create

Terraform will perform the following actions:

  # healthchecksio_check.testing_healthcheck will be created
  + resource "healthchecksio_check" "testing_healthcheck" {
      + grace     = 3600
      + id        = (known after apply)
      + name      = "testing-check"
      + pause_url = (known after apply)
      + ping_url  = (known after apply)
      + schedule  = "0 0 1 * *"
      + timezone  = "UTC"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  ~ testing_healthcheck_id = "<healthcheck id>" -> (known after apply)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform
apply" now.
---

@ThomasKwan-shopline commented on GitHub (Apr 11, 2024): Sure, As I mention before, we are using terraform with [kristofferahl/healthchecksio](https://registry.terraform.io/providers/kristofferahl/healthchecksio/latest/docs) for healthchecks.io iac which is suggest by healthchecks.io In our use case, my company will run some custom pipeline for plan and apply terraform. Now only approved engineer can trigger those pipeline since it involve productoin env read-write api key and we dont want other engineer can use this key. However, it make approved engineer always need support other engineer to run the `terraform plan`. To solve this problem, we hope to allow other engineer use the read-only api key for terraform plan, because they cannot modify any healthchecks.io resource by using read-only api key. By studying the terraform provider and healthchecks.io doc, I found it is impossible. because It missing two information, uuid and channels. So we hope to have a new type of api key, that is read-only but have the same schema with read-write api key, so we can just easily to apply the new type api key to terraform and the problem solve. --- some poc by using this terraform provider **Before test** Create a healthcheck by using terraform **Run terraform plan with read-write api key** ``` TF_VAR_healthchecksio_api_key="<read-wirte api key>" TF_LOG="" terraform plan healthchecksio_check.testing_healthcheck: Refreshing state... [id=<healthcheck id>] No changes. Your infrastructure matches the configuration. Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed. ``` **Run terraform plan with read-only api key** ``` TF_VAR_healthchecksio_api_key="<read-only api key>" terraform plan healthchecksio_check.testing_healthcheck: Refreshing state... [id=<healthcheck id>] Note: Objects have changed outside of Terraform Terraform detected the following changes made outside of Terraform since the last "terraform apply" which may have affected this plan: # healthchecksio_check.testing_healthcheck has been deleted - resource "healthchecksio_check" "testing_healthcheck" { - id = "<healthcheck id>" -> null name = "testing-check" # (6 unchanged attributes hidden) } Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes. ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # healthchecksio_check.testing_healthcheck will be created + resource "healthchecksio_check" "testing_healthcheck" { + grace = 3600 + id = (known after apply) + name = "testing-check" + pause_url = (known after apply) + ping_url = (known after apply) + schedule = "0 0 1 * *" + timezone = "UTC" } Plan: 1 to add, 0 to change, 0 to destroy. Changes to Outputs: ~ testing_healthcheck_id = "<healthcheck id>" -> (known after apply) ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now. ---

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Apr 22, 2024):

Thanks for the explanation, I think I understand the issue you are facing now. And indeed it looks like a new type of API key would be required here. It's not just a matter of making the schemas of read-write and read-only API responses match. terraform plan needs to know check and channel UUIDs, but the read-only keys are specifically designed to not return them.

I'm currently not planning to work on this. I will reconsider if I see ongoing interest from multiple paying or would-be-paying users.

@cuu508 commented on GitHub (Apr 22, 2024): Thanks for the explanation, I think I understand the issue you are facing now. And indeed it looks like a new type of API key would be required here. It's not just a matter of making the schemas of read-write and read-only API responses match. `terraform plan` needs to know check and channel UUIDs, but the read-only keys are specifically designed to *not* return them. I'm currently not planning to work on this. I will reconsider if I see ongoing interest from multiple paying or would-be-paying users.

kerem commented

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

Author

Owner

@DonRichie commented on GitHub (Aug 3, 2024):

I would like to add another use-case. My goal is to retrieve the ping durations and send them to influxdb via python for a nice visualization.

With the read-only key I can't see the UUIDs and am therefore stuck after calling the checks endpoint (https:///api/v3/checks/).
What surprises me is that I can see a field "unique_key", which is not the UUID. This information isn't available anymore when I switch to the read-write key. In my opinion this should be uniform.

By switchting to the read-write key I can't see a field for the UUID either, but now there is an "update_url" for each check, which contains it and can be used to get to the desired pings endpoint (https:///api/v3/checks//pings/).

@DonRichie commented on GitHub (Aug 3, 2024): I would like to add another use-case. My goal is to retrieve the ping durations and send them to influxdb via python for a nice visualization. With the read-only key I can't see the UUIDs and am therefore stuck after calling the checks endpoint (https://<domain>/api/v3/checks/). What surprises me is that I can see a field "unique_key", which is not the UUID. This information isn't available anymore when I switch to the read-write key. In my opinion this should be uniform. By switchting to the read-write key I can't see a field for the UUID either, but now there is an "update_url" for each check, which contains it and can be used to get to the desired pings endpoint (https://<domain>/api/v3/checks/<uuid>/pings/).

kerem commented

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

Author

Owner

@cuu508 commented on GitHub (Aug 12, 2024):

@DonRichie,

By switchting to the read-write key I can't see a field for the UUID either

A separate UUID field will be available in the next release, see https://github.com/healthchecks/healthchecks/issues/1007

What surprises me is that I can see a field "unique_key", which is not the UUID. This information isn't available anymore when I switch to the read-write key. In my opinion this should be uniform.

unique_key is derived from UUID: github.com/healthchecks/healthchecks@b859a71920/hc/api/models.py (L373)

This is an implementation detail though, and could in theory change in future.

@cuu508 commented on GitHub (Aug 12, 2024): @DonRichie, > By switchting to the read-write key I can't see a field for the UUID either A separate UUID field will be available in the next release, see https://github.com/healthchecks/healthchecks/issues/1007 > What surprises me is that I can see a field "unique_key", which is not the UUID. This information isn't available anymore when I switch to the read-write key. In my opinion this should be uniform. unique_key is derived from UUID: https://github.com/healthchecks/healthchecks/blob/b859a719200ea253a9bdb9e9caac98542a64ed9b/hc/api/models.py#L373 This is an implementation detail though, and could in theory change in future.

Rows
Columns

[GH-ISSUE #986] New type of API key: read-only, but returns check and channel UUIDs #693

Remark