Acknowledge or resolve an alert
Forward-only: open -> acknowledged -> resolved, or open -> resolved directly. A backward or no-op transition (e.g. re-resolving an already-resolved alert) returns 409.
/alerts/{alert_id}AuthorizationBearer token (JWT) · headerrequiredJWT issued by the external IdP via the OAuth 2.0 authorization-code flow (Kinde in
production; a simulator in test). The client obtains it and sends it as a Bearer token on
every authenticated call. Sarvex's services verify it — issuer, audience, signature
(IdP JWKS), expiry — and read identity and tenant from its claims. Sarvex does not issue
or revoke these tokens. merchant_id/store_id are read from the verified claims (and the
merchant→store mapping), never from the URL. The operator scope is required for
/operator/*. Operators acting on a specific merchant pass the X-Operate-As header,
which is recorded in the audit log.
alert_idstringrequiredapplication/jsonstatusstringrequiredacknowledgedresolvedUpdated alert.
alert_idstringstore_idstringcheck_typestringseveritystringhealthydegradedcriticalstatusstringopenacknowledgedresolveddetailstringopened_atstring<date-time>acknowledged_atstring<date-time> | nullacknowledged_bystringresolved_atstring<date-time> | nullauto_resolvedbooleanResource not found within the caller's tenant.
errorobjectrequiredShow propertiesHide properties
codestringrequiredmessagestringrequireddetailsobject | nullThe alert is not in a state that allows this transition.
errorobjectrequiredShow propertiesHide properties
codestringrequiredmessagestringrequireddetailsobject | null