v2.9.0

A feature release adding the Signalgrid notification provider from Uptime Kuma 2.5.4. Notification provider options are client-side additive data and are not version gated, so this is non-breaking: on a server older than 2.5.4 the provider type is simply rejected server-side, and every other supported release is unaffected.

Features

• Signalgrid notification provider (server 2.5.4+): adds NotificationType.SIGNALGRID with signalgridClientKey and signalgridChannel (both required). Closes #65.

  Previously missing because the upstream coverage scanner keyed notification providers on a type variable found in signalgrid.js's send logic (a CRIT/INFO severity flag) instead of the provider name; the scanner now keys on name only, which surfaced this pre-existing gap.

2.8.0

A feature release adding 6 notification providers from Uptime Kuma 2.5.1.
Notification provider options are client-side additive data and are not version
gated, so this is non-breaking on every final release in the supported 1.21.3
through Uptime Kuma 2.5.0 range.

Features

• 6 new notification providers from Uptime Kuma 2.5.1: BearSMS, ClickUp,
  Milky, OpenWA, Pinglet, TurboSMTP. Closes
  #60.

  (The auto-opened issue titled these as "2.5.0" additions; the upstream
  coverage scan reads the server's master branch and stamps it with the
  current package.json version. Confirmed against Uptime Kuma's own tags —
  all six providers first shipped in the 2.5.1 release.)

v2.7.0

A feature release adding the PM2 monitor type and 34 notification providers from Uptime Kuma 2.5.0. Non-breaking on every final release in the supported 1.21.3 through Uptime Kuma 2.5.0 range.

Features

• PM2 monitor type (server 2.5.0+): checks if a PM2 process is online. Reuses the existing system_service_name field. Closes #55.
• 34 new notification providers from Uptime Kuma 2.5.0: Bale, Bitrix24, CallMeBot, Cellsynt, 46elks, Fluxer, Google Sheets, Grafana OnCall, GTX Messaging, HaloPSA, Heii On-Call, Jira Service Management, Keep, Notifery, OneChat, Onesender, Pumble, PushPlus, Resend, SendGrid, SevenIO, SIGNL4, SMS.ir, SMSPartner, SMSPlanet, SpugPush, Teltonika, Threema, WAHA, Web Push, Whapi, 360messenger (WhatsApp), WPush, YZJ. Closes #55.

Bugfixes

• Fixed false-positive certificate monitor type in the upstream coverage detection script (was matching a SQL string inside globalping.js).

Install / Upgrade

pip install --upgrade uptime-kuma-api2

v2.6.0

A feature release adding new monitor types, notification providers, and custom SSL certificate support. Non-breaking on every final release in the supported 1.21.3 through Uptime Kuma 2.5.0 range.

Features

• NTP monitor type (server 2.5.0+): queries NTP servers via UDP, checks stratum/offset/dispersion against configurable thresholds.
• OracleDB monitor type (server 2.3.0+): Oracle database connectivity monitor.
• AuthMethod.BEARER enum value: the server added bearer token auth in 2.4.0; the bearer_token field was already gated but the enum value was missing.
• 9 new notification providers from Uptime Kuma 2.3.0-2.5.0: Plivo (SMS + Voice Call), Ooredoo (Maldives) SMS, WxPusher, Flowtriq, EgoSMS (Uganda), VK Teams, Telnyx, VK, MAX messenger.
• SMTP smtpAdditionalHeaders field: custom email headers as a JSON string.
• ssl_verify accepts a CA bundle path (str or os.PathLike) for custom certificate verification, in addition to True/False. Contributed by @Firq-ow.

Packaging

• python-engineio>=4.0.1 is now an explicit dependency floor, ensuring the custom CA mechanism is available.

Install / upgrade

pip install --upgrade uptime-kuma-api2

Release 2.5.0

A feature release, and non-breaking on every final release in the supported
1.21.3 through Uptime Kuma 2.5.0 range: a call that succeeds against 2.4.0 still
succeeds and still returns the same value. (Our 2.5.0 and Uptime Kuma's 2.5.0 are
unrelated numbers that happen to coincide; every version below refers to the
Uptime Kuma server unless it says otherwise.)
One thread runs through all three entries: a v2-only surface's floor is the
release that introduced it, never the major version. The library had been
treating 2.0 as the boundary for things Uptime Kuma actually shipped in 2.1.0,
and it was wrong in three separate places -- one monitor type, two status-page
fields, and the three status-page analytics keys. All three are corrected here,
each floor established from Uptime Kuma's own source and tags rather than
inferred, and the third was additionally observed on a running 2.0.2 server.
The shape of the mistake is worth recording because it is not obvious from
inside a >= 2.0 check: a 2.0.x server is a 2.x server, so a gate that reads
"2.x or newer" looks correct and silently sends fields no 2.0.x release
implements -- or, in the analytics case, withholds the one it does. Nothing
errors. The monitor sat PENDING forever, or the status page saved successfully
having dropped the caller's value.
The feature is the withhold-and-warn rule reaching a second surface. Status-page
fields a server cannot accept are now announced instead of vanishing, the same
way monitor fields have been since 2.4.0.

Features

• Status-page v2-only fields are now withheld and warned. The
  withhold-and-warn rule established in 2.4.0 for monitor fields now extends to
  save_status_page. Two status-page fields introduced in Uptime Kuma 2.1.0
  (showOnlyLastHeartbeat, rssTitle) are withheld from the payload and reported
  via a single UnsupportedFieldWarning per call when the connected server is
  below version 2.1. The rule is computed from kwargs before the
  get_status_page round trip, so a value the server itself returned is never
  treated as a caller request and an escalated warning costs no fetch.

  The analytics trio (analyticsType, analyticsId, analyticsScriptUrl) is
  not gated: the server requires analyticsType present and rejects its
  absence (verified against 2.4.0). See issue #41 for the version boundary of
  the analytics fields.

  Maintenance and settings were inventoried against upstream and have no v2-only
  surface: every field they accept exists at both 1.23.2 and 2.5.0.

  Non-breaking: every call that succeeds today still succeeds and returns the
  same value, with one warning added for newly-gated fields on a pre-2.1 server.
  Addresses pbarone/uptime-kuma-api2#33.

Bugfixes

• googleAnalyticsId is no longer silently dropped on Uptime Kuma 2.0.x. The status-page analytics boundary was 2.0, but all three analytics keys (analyticsType, analyticsId, analyticsScriptUrl) first ship in 2.1.0 — and a 2.0.x server still reads googleAnalyticsId. So on 2.0.0, 2.0.1 and 2.0.2 save_status_page sent four keys the server has no columns for and withheld the one it does read: a caller's googleAnalyticsId was lost on every save, silently, with the save reporting success. The boundary is now 2.1, so below it googleAnalyticsId is sent and the trio is not, and from 2.1 onward the reverse — the two are never both present. showOnlyLastHeartbeat and rssTitle moved with them: their floor is already 2.1 in the field registry, so the builder was one minor version looser than the registry it is supposed to agree with. Provenance is upstream source at tags rather than inference: server/socket-handlers/status-page-socket-handler.js and server/model/status_page.js carry google_analytics_tag_id at 2.0.0 and 2.0.2 with no analytics_* columns, while at 2.1.0 the analytics_* columns exist and google_analytics_tag_id is gone. This is the third instance of one root cause — the same 2.0-versus-2.1 error fixed for monitor types above and for the two status-page fields in the feature entry — and the pattern is now explicit: a v2-only surface's floor is the release that introduced it, never the major version. password was checked in the same block and deliberately left alone: upstream comments its assignment out at 1.23.2, 2.0.0 and 2.1.0 alike, so it is inert at every supported version and its 2.0 boundary says nothing about the analytics one. Behaviour on 1.x and on 2.1+ is unchanged. Reported in pbarone/uptime-kuma-api2#41.
• SYSTEM_SERVICE is no longer accepted on Uptime Kuma 2.0.x, and the rejection message no longer names the wrong version. The four v2-only monitor types were gated behind a single 2.0 floor, but system-service first ships in 2.1.0 — so on 2.0.0, 2.0.1 and 2.0.2 the type passed the gate, add_monitor answered {'msg': 'Added Successfully.', 'monitorID': n}, and the monitor then sat PENDING indefinitely reporting Unknown Monitor Type. That is the same failure the 2.3.1 type gate exists to prevent, one minor version up, and the silent kind: nothing in the return value signalled it and the message a caller might have searched for never appeared. Each type now carries its own floor and the message names it, so a caller on 2.0.2 is told they need 2.1 or newer rather than the self-contradicting 2.0 or newer. Provenance is upstream source and tags rather than inference: system-service was introduced by louislam/uptime-kuma#6488 (merge 6a700cb, milestone 2.1.0), is absent from src/pages/EditMonitor.vue at tags 2.0.0, 2.0.2 and 2.1.0-beta.0, and first appears at 2.1.0-beta.1. RABBITMQ, SNMP and SMTP are 2.0.0 types, keep their 2.0 floor and keep their existing message verbatim. This fix depends on the pre-release comparison shipped in 2.4.0 and would have been wrong without it: under PEP 440 2.1.0-beta.1 sorts below 2.1.0, so a naive >= 2.1 gate would have rejected the very release that introduced the type it gates. Because _parsed_version() now compares on the release segment, 2.1.0-beta.1 is gated as 2.1.0 and is correctly accepted — asserted directly rather than assumed. The private type constant changed shape from a frozenset to a type-to-floor mapping, deliberately mirroring the field registry added in 2.4.0 so the version comparison reads the same way in both places; the two are kept separate because a field and a type are different kinds of thing. A bare string type ("system-service") is floored identically to the enum member, since MonitorType is a str Enum and inherits str.__hash__ — the frozenset relied on the same property and there is a test pinning it. No public method, parameter, class or export was added, and MonitorType itself is untouched. Reported in pbarone/uptime-kuma-api2#28.

v2.4.0 - one rule for v2-only monitor fields

A feature release, and non-breaking on every final release in the supported Uptime Kuma 1.21.3 through 2.5.0 range: a call that succeeds against 2.3.1 still succeeds and still returns the same value.

One rule where there were two

Version-gated monitor fields on a server too old to accept them were handled two different ways — conditions raised, while 25 other fields vanished with no signal of any kind — and a caller could not tell from the outside which half a given field fell into.

They are now withheld and announced uniformly, with one UnsupportedFieldWarning per call naming every withheld field, the version each requires, and the version the server reports. conditions is kept as the single named exception under a written test rather than as an unexplained asymmetry:

A field that changes the monitor's up/down verdict raises. A field that changes how the check runs is withheld with a warning.

A test asserts exactly one field is in the raising category, so a second exception has to fail a test rather than win an argument — the next gated field inherits a criterion instead of a fresh judgement call.

The category is exported deliberately, because filterability is the point:

import warnings
from uptime_kuma_api import UnsupportedFieldWarning

warnings.simplefilter("error", UnsupportedFieldWarning)   # raise instead, opt-in
warnings.simplefilter("ignore", UnsupportedFieldWarning)  # or silence it

That makes strict behaviour available without the library imposing it on anyone. It is a warning rather than an exception, so except UptimeKumaException does not catch it.

edit_monitor also gains the rule. It previously merged the caller's kwargs over the getMonitor response and sent the lot, so edit_monitor(id_, bearer_token="x") against a 1.x server put a column the schema has no room for on the wire and the server rejected the whole update. That field is now withheld and the edit succeeds.

This closes the last of the three follow-ups 2.3.0 opened.

Pre-release servers were misclassified by every gate

_parsed_version() compared the reported version directly, and under PEP 440 a pre-release sorts below its own release. Uptime Kuma ships betas and reports the tag verbatim, so a 2.0.0-beta.* server was treated as 1.x by every gate in the library, and a 1.23.0-beta.1 server as pre-1.23.

The most visible symptom was the 2.3.1 monitor-type gate: on a 2.0.0-beta.4 server, add_monitor(type=MonitorType.SNMP) raised "requires Uptime Kuma 2.0 or newer, but the server reports version 2.0.0-beta.4" — a message that contradicts itself. The library was also inconsistent in the wrong direction: an unparseable nightly was treated as newest while a parseable beta was treated as oldest, so the less informative string got the better outcome.

The comparison now runs on the release segment. Separately, a missing version reported as None escaped as a TypeError that the unparseable-version sentinel was supposed to absorb; it is now caught.

Note this is a deliberate behaviour change on pre-release servers — they now receive fields they previously did not. That is the fix working, and it is why "non-breaking" above is scoped to final releases.

Every version floor was verified, not assumed

Before any of the field work was implemented, all 25 fields reachable on a pre-2.0 server were sent to a real 1.23.2 server one at a time, bypassing the library's own gate. Every one was rejected with SQLITE_ERROR: table monitor has no column named <column>, so no field was mis-gated.

That also closes the "unverified" premise the 2.3.0 policy rested on: there was never a possibly-working path to protect.

Also in this release

Packaging and test-infrastructure work that removes two standing classes of mistake rather than one instance of each:

• The sdist can no longer carry credentials, and a release is gated on that mechanically (scripts/check_sdist.py) instead of on remembering to check. The setup.py publish shortcut that could bypass every gate is gone.
• The unit-suite file list that lived in seven places is now derived from the code, so adding a test file needs no CI edit — and a bare pytest is now the safe invocation, with the destructive suite an explicit -m integration opt-in.

Public API

One new name: UnsupportedFieldWarning. Nothing else was added, changed or removed.

---

Full detail, including the reasoning behind each decision, is in CHANGELOG.md.

pip install uptime-kuma-api2==2.4.0

v2.3.1 - v2-only monitor type gate, requests dependency, docs and API reference fixes

A patch release: one v1.x correctness fix, one packaging correction, and three documentation gaps closed. No public method, parameter, class or export was added, and behaviour on Uptime Kuma 2.x is unchanged throughout.

This release also carries the project's first outside contribution, from @JasonColapietro.

Bugfixes

The four v2-only monitor types are now rejected on pre-2.0 servers instead of being sent (#12). RABBITMQ, SNMP, SMTP and SYSTEM_SERVICE exist only on Uptime Kuma 2.x, but nothing compared the requested type against the server version. add_monitor / edit_monitor with one of them against a server older than 2.0 now raises before any payload is built:

UptimeKumaException: monitor type 'snmp' requires Uptime Kuma 2.0 or newer,
but the server reports version 1.23.17

The failure this replaces was worse than "the server rejects it", in both directions. A 1.x server does not validate type when a monitor is added — Monitor.validate() checks interval bounds and nothing else, and the type is first consulted at beat time. Verified against a disposable 1.23.17 instance: sending one of these types failed with an opaque SQLITE_ERROR: table monitor has no column named rabbitmq_nodes, naming a database column the caller never typed, and only because the library also sent that column. With those companion columns absent, the same server accepts the type and creates a monitor that sits PENDING indefinitely reporting Unknown Monitor Type — identically to an invented type string. So the old loud failure was a byproduct of the payload rather than a guarantee.

Provenance is upstream source and tags, not inference: rabbitmq (2.0.0), snmp (2.0.0), smtp (2.0.0), system-service (2.1.0); git tag --contains returns no 1.x tag for any of the four.

Note that the gate applies a single 2.0 floor, which leaves SYSTEM_SERVICE under-gated on 2.0.x — it first appears in 2.1.0. That is deliberate and explained in CHANGELOG.md.

Packaging

requests is now declared as a runtime dependency (#10). api.py imports it at module scope for the get_status_page HTTP fetch, but it was declared in neither install_requires nor requirements.txt and resolved only as a side effect of python-socketio's [client] extra. The declared floor is >=2.21.0, matching what that extra already guaranteed, so no install that resolved before stops resolving.

Documentation

• Three exported symbols reached the API reference for the first time (#8): Event, notification_provider_options and notification_provider_conditions. __init__.py exported 15 names against 12 autodoc directives, and autodoc emits no warning for an export it never sees, so a clean docs build looked identical whether they were covered or not. Event also gained a class docstring — it was the only enum in the package with none — so all 20 event names and their wire values now render.
• The two Event members added in 2.3.0 are now named (#7): Event.UPDATE_MONITOR_INTO_LIST and Event.DELETE_MONITOR_FROM_LIST. The 2.3.0 notes described that fix using only the wire event names.
• The supported server range is recorded (#7): Uptime Kuma 1.21.3 through 2.5.0 from a single install. run_tests.sh exercises the gate boundaries across it and this tree was live-verified against 1.23.2 and 2.5.0.

Tests

• The container readiness poll in run_tests.sh is bounded (#15, credit @JasonColapietro, #20). The wait for a freshly started container had no attempt cap and no deadline, so a container that never became ready left the script spinning forever and running. It now has a 60-second deadline overridable via READINESS_TIMEOUT, caps each probe with curl --max-time 1, and on timeout reports the version and elapsed time, stops the container and exits non-zero. Development tooling only, not in the published distribution.
• 13 regression tests added for the monitor type gate, in tests/test_monitor_params_v2.py. Unit suite is now 226 tests / 1185 subtests.

Verification

Full 3.8–3.13 matrix green on the tagged commit. The monitor type gate was live-verified against a disposable Uptime Kuma 1.23.17 container, and its regression tests confirmed to fail against the unfixed code (14 failures, all UptimeKumaException not raised).

The artifacts attached here were downloaded from PyPI and digest-verified against PyPI's own metadata, so they are provably the published bits rather than a local rebuild:

File	sha256	Size
uptime_kuma_api2-2.3.1-py3-none-any.whl	4f20624f9b8c689c0e72c3455601a53fdef6430e269cef962b41f7f07a5d0383	58,989 B
uptime_kuma_api2-2.3.1.tar.gz	cd633952d7eea2385bedc0634acda69ad816d2207a723ce8665388c5d3f99794	119,866 B

pip install uptime-kuma-api2==2.3.1

Full detail, including the reasoning behind each decision, is in CHANGELOG.md.

v2.3.0 - v1.x add_monitor regression fix, 2.x monitor cache, 5 upstream fixes

Seven confirmed library defects. Five are inherited from the original tracker; two were found by this project's own live verification. Verified against a live Uptime Kuma 2.5.0 instance and a disposable 1.23.2 container. No new public API surface: every change is corrective or additive. Install: pip install uptime-kuma-api2==2.3.0

Bugfixes — found here

• add_monitor() failed on every Uptime Kuma 1.x server. The 2.x-only conditions field was assigned in the unconditional common payload rather than inside the existing >= 2.0 block, so its [] default was emitted on every call and the server rejected the insert with SQLITE_ERROR: table monitor has no column named conditions. No caller opt-in of any kind was required, which made the library's most-used method unusable on v1. This is a released regression, present in v2.1.0, v2.2.0 and v2.2.1 (introduced by 70138bf feat: add Uptime Kuma v2 support), in code the original library never had. v2 payloads are byte-identical to before. Seven adjacent v2-only fields that were likewise emitted outside the gate are now gated in place: jsonPathOperator, snmp_v3_username, ping_count, ping_numeric, ping_per_request_timeout, mqttWebsocketPath and mqttCheckType.
• get_monitors() returned session-stale data on Uptime Kuma 2.x, and delete_monitor raised monitor does not exist for a monitor created moments earlier in the same session. 2.x stopped broadcasting the full monitor list after a mutation and emits two deltas instead — updateMonitorIntoList and deleteMonitorFromList — for which the library registered no handler, so the cache never moved after login. Handlers for both deltas now keep the cache coherent, and delete_monitor / delete_monitor_tag force a full-list refresh before their existence guard evaluates. Present in the original library identically.

Bugfixes — inherited from upstream

• All seven delete_* methods now accept a string id. The existence guard compared the caller's string against the server's integer ids, so delete_monitor("371") raised monitor does not exist for a monitor that demonstrably existed (lucasheld/uptime-kuma-api#91; credit: @ausebiblibre, PR #92).
• get_status_page now honours ssl_verify. The constructor passed it only to socketio.Client and never stored it, so the requests.get that fetches the public status page JSON always verified the certificate (#65; credit: @pr0kium, PR #81).
• add_monitor_tag / delete_monitor_tag no longer raise TypeError: 'NoneType' object does not support item assignment when used before a monitor list event has arrived — which failed after the tag had already been changed on the server (#68).
• Non-PEP440 server versions no longer crash every version gate. A server reporting e.g. 2.0.0-dev-nightly-20240101 made packaging.version.parse raise InvalidVersion at each gate site. Parsing now runs through one private accessor that returns a max sentinel for an unparseable string; valid versions parse exactly as before (#74).
• Socket.io timeouts now raise the library's own Timeout. _call let socketio.exceptions.TimeoutError escape, so callers catching Timeout or UptimeKumaException did not catch a timed-out call (#44).

Notes

Explicitly asking for conditions on a pre-2.0 server raises; the seven adjacent v2-only fields are dropped silently. The split is deliberate and a caller cannot derive it from first principles, so it is stated here. A non-empty conditions list against a server older than 2.0 now raises UptimeKumaException: conditions requires Uptime Kuma 2.0 or newer, but the server reports version <observed> before any server call is made — identically whether the value came from a keyword argument or from MonitorBuilder.conditions(). conditions raises because it defines the monitor's up/down semantics: silently discarding it produces a monitor that reports success against criteria the caller never set. The other seven change how a check runs, not its verdict, so they are omitted silently, as the >= 2.0 block they join has always done for ipFamily, cacheBust, subtype and the rest. An explicit conditions=[] is treated as "no conditions requested" and simply omitted on v1 rather than rejected.

Documentation

• Add the missing MonitorType import to the README and class docstring context manager examples, which raised NameError as written (#78; credit: @Mirochill PR #95, @glerb #67).
• Fix the add_monitor return key in the class docstring example (monitorId -> monitorID); the README copy was corrected in 2.2.1 (credit: @VadymKhvoinytskyi, PR #80).
• Document that the "API key" created in the Uptime Kuma web UI cannot authenticate this socket.io API — it only grants access to the Prometheus /metrics endpoint (credit: @nneul PR #60; answers #73).

Metadata

Both corrections are behaviour-neutral: no method signature, accepted value or emitted payload changed.

• Declare the SMTP option smtpSecure as type="bool" rather than type="str", matching upstream SMTP.vue (credit: @BergCyrill, PR #69).
• Declare the notificationIDList default as [] rather than {} (credit: @obfusk, PR #57).

Tests

114 new tests (25 for the conditions gate, 35 for the monitor list cache, 7 for delete_* id coercion, 47 across the existing v2 files). Every bug condition test was confirmed to fail against the pre-fix code. 213 unit tests total, green on Python 3.8-3.13. tests/test_status_page_incidents.py now actually runs in CI, and tests/live_test_conditions_v1.py was added for manual v1 verification against a disposable 1.23.x container.
Full changelog: https://github.com/pbarone/uptime-kuma-api2/blob/main/CHANGELOG.md
Compare: v2.2.1...v2.3.0

v2.2.1 - Status page v2 fixes, Read the Docs, standalone repo

Status page v2 fixes, Read the Docs documentation, and the move to a standalone repository. All fixes verified against a live Uptime Kuma 2.4.0 instance. Install: pip install uptime-kuma-api2==2.2.1

Bugfixes

• get_status_page dropped incidents on Uptime Kuma 2.1.0+. The server renamed the singular incident object to a plural incidents array (louislam/uptime-kuma#6469). 2.0.0 stopped the KeyError with .get() but still read only the singular key, so on 2.1.0+ it returned incident: None and silently discarded the incidents. Both keys are now always returned: incidents the full list, incident the first entry for backward compatibility.
• save_status_page failed on any v2 page without analytics (Invalid analytics type). The v2 server requires analyticsType to be present and accepts null but not an absent key. This also broke post_incident and unpin_incident.
• add_status_page left the status page list cache stale, so delete_status_page could not see a page created in the same session.

Documentation

• Published on Read the Docs.
• MonitorBuilder added to the API reference.
• README rewritten as an independent continuation of the original library, with credit and retained MIT copyright.
• Fixed the add_monitor example return value (monitorId -> monitorID).

Packaging

• Repository detached from the fork network and renamed uptime-kuma-api-v2 -> uptime-kuma-api2 to match the PyPI distribution (old URL redirects).

Tests

13 new tests (10 incidents regression, confirmed to fail against pre-fix code; 3 analytics-key presence). 99 unit tests total, green on Python 3.8-3.13.

Full changelog: https://github.com/pbarone/uptime-kuma-api2/blob/main/CHANGELOG.md

v2.2.0 - Packaging and docs alignment, Python 3.8+

Packaging, documentation, and supported-Python cleanup. No functional changes to the library - no API surface, monitor, notification, or status page behaviour is affected.

Install: pip install uptime-kuma-api2==2.2.0

Breaking

Python 3.7 is no longer supported. python_requires is now >=3.8, <4. Python 3.7 has been end-of-life since June 2023 and was never covered by CI (which tests 3.8-3.13), so the previous floor was an untested claim. Installs on 3.7 resolve to 2.1.0 or earlier.

Fixed

• SyntaxWarning: invalid escape sequence '\*' was emitted on every import under Python 3.12+, from the set_settings docstring
• Documentation builds were broken on Python 3.12+: the Sphinx 5.3.0 pin cannot run there because imghdr was removed from the stdlib. Bumped to 7.4.7.
• .readthedocs.yaml was missing the build: section that RTD v2 requires, so Read the Docs builds would have failed
• Sphinx now builds with zero warnings

Documentation

• README, Sphinx docs, and install instructions now consistently use the published distribution name uptime-kuma-api2. The import package remains uptime_kuma_api, so existing code is unaffected.
• Clarified that PyPI uptime-kuma-api (upstream) and uptime-kuma-api-v2 (an unrelated maintainer) are not this fork
• Corrected the documented test command. Only the six v2 test files run without a live server; the inherited integration tests require an instance at 127.0.0.1:3001 and delete all data on it, which is now warned about explicitly.
• Replaced the Read the Docs link that pointed at the upstream project (and documents none of this fork's v2 features) with local Sphinx build instructions

Packaging

• Added project_urls (Source, Changelog, Issues) for the PyPI sidebar
• Added Python 3.12 and 3.13 classifiers to match the CI matrix
• Added build/ to .gitignore

Full changelog: https://github.com/pbarone/uptime-kuma-api-v2/blob/main/CHANGELOG.md
Compare: v2.1.0...v2.2.0