Alerts

An answer can change after it was given — a later gift takes a client over the year's limit, two recipient records turn out to be one person, a new version of the law is published. Himmel never edits the earlier answer. It issues a new one, and tells you here.

GET /v1/alerts lists them, newest first, and filters by type and status:

A re-check is stored whenever any part of an answer moved, down to the year-to-date total it reports. An alert is raised when the state or an outcome moved — the changes someone has to act on.

For software that acted on an answer

An agent that acted on an answer learns here that the answer has changed. A key made for an agent lists the alerts about its own agent's actions alone - an answer given again, an action taken against your rules or handed to a person, one your rules could not answer - never another agent's or your account's own news; your account's own keys list every one. Each check.rechecked alert carries the new answer's check_id and the one it supersedes: poll GET /v1/alerts?type=check.rechecked and look for the check_ids you acted on under payload.supersedes. A checks.rerun alert covers many answers at once, so it links to them instead: follow payload.checks, and each answer listed names the one it replaced in supersedes_check_id. GET /v1/checks/{id} on an old answer shows superseded_by either way. Signed webhooks are not offered yet: polling is the interface.

Acknowledging

POST /v1/alerts/{id}/acknowledge marks an alert as seen. It changes nothing else: an alert has one status, shared by every caller, and is emailed to your admins whatever it is. A person marks one seen on the console's Home the same way, so software of yours that reads open alerts sees it seen too. acknowledged_by names who saw it — from one of your account's own keys a person in your account, signed in yourself — and a key made for an agent marks seen only the alerts it lists, any other being 404 not-found to it, and names nobody (422 invalid-request, not_the_keys).

Each alert is also emailed once to your account's admins - but never to the person whose own act it reports: a version they published, an answer their approval or decision issued again (by_user). Where they are your only admin it is emailed to nobody, and listed here for everyone all the same. The email says what it is about in your words, as the console does: a playbook by its title, a rule by its title, an agent by its role, and a changed answer by its action - what it came to, who asked, under which playbook - with what it was and is now. The listing's emailed_at and emailed_to say when everyone it goes to had been emailed, and how many it reached: a person whose mail server refused their address is not counted, and the others are emailed all the same. The email links the console's page for what it reports - the answer in the check log, a version's confirmation page, the review queue - the one Home links the same alert to. An action handed over goes to the person it is handed to alone, at once - never to your admins, who read it here and on Home. An action taken against your rules goes to the approver its rule names as well, and in one summary a day to each of them, grouped by rule — unless its rule is one your owner has chosen to hear of at once, under the setting emailed_at_once (a list of your policies' rule ids), which is emailed as it happens; payload.emailed says which. An alert belongs to the environment it is about, and in an account with live and test, one raised by test data is listed to test keys and emailed to nobody: trying an integration never reaches your finance team's inbox. The sandbox, which is test only, emails its own.