noise_sensor.noise_threshold_triggered events. A sound-level event is not an audio recording or a determination that a guest violated a rule.
What Is a Threshold?
A threshold defines the noise level that triggers a notice during a specified period. For Minut, configure the regular threshold and an optional quiet-hours threshold. Use the property’s time zone for daily boundaries. See threshold configuration for the provider-specific fields. Choose thresholds for the actual property, sensor placement and expected background sound. Review false alarms before using a noise event to prompt staff or guests. One universal decibel range is not suitable for every building.From a threshold to an alert
- Connect a Minut sensor and confirm it is online.
- Configure the regular and quiet-hours thresholds your application needs.
- Subscribe to
noise_sensor.noise_threshold_triggeredusing a webhook. - Verify the signature, check the workspace and durably store the event before acknowledging it.
- Let an application worker decide the next action. Keep event receipt separate from sending a notification.
Receive and store an alert
This example uses the official Seam SDK and Node.js 24’s experimentalnode:sqlite module with a persistent SQLite file. Save it as noise-receiver.mjs, install seam, and set SEAM_WEBHOOK_SECRET and SEAM_WORKSPACE_ID from the workspace where you create the webhook. Set ALERT_DB_PATH to a persistent disk location. Run node noise-receiver.mjs behind an HTTPS reverse proxy that forwards /webhooks/seam to port 3000 without changing the request body.
Complete JavaScript receiver
Complete JavaScript receiver
JavaScript
SeamWebhook.verify returns the event itself. Read event.event_type, not req.body.event. For a matching noise event, a 204 response means it is stored or was already stored. Other event types are acknowledged and ignored. Invalid signatures receive 400; a failed database write receives 500 so delivery can retry.
The (workspace_id, event_id) primary key survives a process restart and prevents a repeated delivery from creating another pending alert. This does not make an external notification exactly-once. Use a worker with an idempotency key and a recorded delivery result. For a deployment with multiple receivers, we recommend one shared durable database so all instances use the same duplicate record.
Read occurred_at when ordering notices. They can arrive out of order. Retain provider metadata as context, but do not depend on an undocumented metadata field being present. Avoid escalating a delayed notice after a later resolved state without checking your application’s current incident state.
Verify the receiving path
In a sandbox workspace, use Simulate Triggering a Noise Threshold, then check both webhook delivery and the stored alert. A simulator event in the event list alone does not prove your webhook received it. Confirm all of these before deploying:- One delivered event creates one pending row; replaying it still leaves one row.
- Restart the receiver and replay it again; the row count stays the same.
- An invalid signature creates no row. A storage failure returns a retryable response.
- Logs distinguish received, rejected, duplicated and pending events. Monitor webhook failures and worker backlog.