API functionality

[louislam]

Discussed in https://github.com/louislam/uptime-kuma/discussions/96

^{Originally posted by TheGuyDanish July 12, 2021}
I'd love to see the ability to retrieve, update, remove or add monitors via API calls. Maybe using an API key that's tied to the user. In a way that when spinning up a new docker container or doing an automated workflow like Terraform, the new device could be added to the software automatically.

[Panja0]

API call for putting monitors on pause/unpause for an xx period would be awesome!
We can than include the API call in a script before doing a restart on a server for instance.

[bsord]

Commenting as I too would love to see this functionality.

[jtagcat]

GitHub Etiquette

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

[deefdragon]

Some things, like that which is visible on the status page, are already readily accessible, just undocumented. The creation and deletion of monitors/notifications are some of the things that are not.

Thus this realistically sounds like a 2 part task.

1. Add the ability to use a key for api calls.
2. Document the API being used so that it can be easily interacted with.

[hypervtechnics]

Another endpoint I'd need is to read the the active incident information

[louislam]

Some things, like that which is visible on the status page, are already readily accessible, just undocumented. The creation and deletion of monitors/notifications are some of the things that are not.

Thus this realistically sounds like a 2 part task.

1. Add the ability to use a key for api calls.
2. Document the API being used so that it can be easily interacted with.

No, it should not be used in my opinion.

It is not the same thing, because these are internal APIs which I expected that it should be called from Uptime Kuma only. I could change API without any notices.

[deefdragon]

While I understand that the current calls are expected to be Uptime Kuma only, I really think it should be a single API instead of a public API and an internal API. The biggest reason is that maintaining multiple APIs for the same thing is a real pain. (I have personal experience on this from work. We had internal and external APIs for some products, and about one in 5 feature changes resulted in bugs, as changes were made to one API, but done incorrectly, or not at, all to the other).

Having a unified API has some other benefits as well:

• It Forces good documentation of the API, useful for developers and users.
• API changes would always get multiple pairs of eyes looking over them
• Obviously, each endpoint & the logic therein only has to be implemented once

I do understand the want to be able to iterate quickly, and change endpoints. This is still possible if the endpoints are versioned: alpha, beta, stable, deprecated etc. and would just require having a system around these changes. Something that should be considered anyways.

The biggest downside I can see is that the auth logic gets more complicated to account for the different ways the API is getting accessed. Given most of the work would be needed with separate APIs anyway, its not the worst thing.