Skip to main content
Noise sensors measure sound levels in a space. With Seam, your application can configure supported noise thresholds and react to 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

  1. Connect a Minut sensor and confirm it is online.
  2. Configure the regular and quiet-hours thresholds your application needs.
  3. Subscribe to noise_sensor.noise_threshold_triggered using a webhook.
  4. Verify the signature, check the workspace and durably store the event before acknowledging it.
  5. 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 experimental node: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.
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.
Sandbox checks establish the application and delivery path, not acoustic detection on physical hardware. Test the installed sensor separately. A webhook integration does not establish blanket privacy or legal compliance.

Next Steps