Arming

An alarm moves on two independent axes. Almost every surprise in this API comes from treating them as one, so they are worth separating before anything else.

Axis	Values	Changed by
Which mode it is in	Home, Away, Night, or Disarmed	arm and disarm, and nothing else
Triggered or not	an incident is open, or it is not	trigger opens one; clear, a configured disarm, or the 24-hour auto-close ends it

The two never interact. A trigger does not disarm your alarm, and clearing an incident does not either. An alarm that was armed Away when it fired is still armed Away while the incident runs, and still armed Away once it is cleared - it will alert again on the next trigger without being re-armed. Clearing says this event has been dealt with; it says nothing about whether the premises are armed.

This is how a physical panel behaves: silencing an alarm is not disarming it.

Disarmed Is a Mode

Every alarm has four built-in modes - Home, Away, Night, and Disarmed - plus any custom modes you add. Disarmed differs from the rest in two ways:

• It has its own endpoint. You do not arm to it - there is no arm/disarmed - you call disarm.
• It binds no escalation policy, so there is no trigger/disarmed either.

What it does carry is its own settings, the way each armed mode does - most usefully, whether disarming clears an incident that is already open.

A Trigger Always Fires

Sending a trigger alerts your contacts whether the alarm is armed or not. Arming does not gate it.

That is deliberate, and it is the opposite of how a physical panel behaves - because OpenAlarm is not your panel. It sits downstream of whatever you already run. Home Assistant, Alarmo or your camera has already decided whether this is worth alerting about; by the time the webhook arrives, that judgement is made. Checking arming state again would mean re-deciding from our copy of it, and our copy is only as fresh as the last arm call we received. Miss one and we would sit believing your house is disarmed while it is armed - and silently drop the very next real break-in.

So arming is not a gate. It answers a different question: which policy a bare trigger runs.

Only Trigger When Armed

If you would rather OpenAlarm did check, each alarm has an optional Only trigger when armed setting, in the console under the alarm’s settings. It is off by default.

Turn it on and a trigger arriving while that alarm is in Disarmed is recorded in your activity log and alerts nobody. Only Disarmed itself gates even then - an alarm part-way through arming, or already counting down an entry delay, still fires, because dropping that trigger would drop a real break-in.

Leave it off unless you have a reason. It is a second gate on state we mirror rather than own, and the failure it introduces is silence. Turn it on when you want a belt-and-braces check and you trust your arm and disarm calls to always arrive.

Sources that cannot arm need nothing at all. A UniFi Protect camera fires one fixed webhook URL and can never call arm - and with this setting off, which it is by default, that just works. Its alarm sits in Disarmed forever, so its bare trigger runs the Away policy.

Which Mode Fires

Call	Fires
trigger	the currently armed mode, or Away if the alarm is Disarmed or the armed mode no longer exists
trigger/{modeId}	the mode you named, always

Naming a mode never falls back. If that mode has been deleted the trigger does not fire some other policy in its place - you asked for a specific response, and firing a different one is worse than firing none.

A stateless source that wants different modes creates one webhook per mode, each pointing at its own trigger/{modeId}.

Disarming returns the alarm to Disarmed and clears the armed mode with it, so a later bare arm returns to Away rather than resurrecting the mode you last used.

The False Alarm Delay

Each mode can hold for a short window before anything is sent (optional, and set per mode). It is not an entry delay - your panel already owns that. It is the grace period between OpenAlarm receiving the trigger and OpenAlarm telling anybody.

• A disarm inside the delay cancels the trigger outright. No incident opens, and no alert is ever sent. This happens whether or not the alarm is set to clear incidents on disarm, because there is no incident yet to clear.
• The trigger is still recorded either way. A cancelled false alarm still appears in your activity log; suppressing the alert is the point, suppressing the record would not be.
• When the window passes, the incident opens and the mode’s policy runs.

Panic Buttons Are Never Armed

A panic button has no arming state and no modes, so none of this applies. Firing one opens an incident immediately - there is nothing to arm first, and no window to wait out, because a press is deliberate.

It has no disarm either, which is why clear is the only way a machine caller can end a panic incident.

If Nobody Was Alerted

Working down from most to least likely:

1. An incident was already open. Further triggers fold into it rather than alerting again - clear it and the next trigger alerts.
2. A disarm arrived inside the false alarm delay and cancelled the trigger.
3. The alarm is in test mode. Check data.environment on the response; see the API reference for what a test does and does not send.
4. Only trigger when armed is on and the alarm was in Disarmed. The trigger was recorded and gated. It is off by default, so this applies only if you turned it on.

A 404 means something different - your key is fine and the trigger named in the path is not one you can fire. See Authentication.