Mero Webhook Platform v2 is a unified webhook infrastructure that consolidates real-time notifications, shift lifecycle events, cleaner visit reporting, and scheduled daily reports into a single platform. All webhooks are delivered via Svix with:

All webhook endpoint management is done through the Svix App Portal — a self-service UI where you can:

You can access the app portal by logging into the Mero instance and going to Settings > Webhooks. If this is not available for you, Webhooks may need to be enabled for your plan. Please contact Mero support.

For detailed instructions, see the Svix documentation:

All webhook deliveries include standard Svix signature headers for verification:

Use the Svix verification libraries to validate incoming webhooks.

These fire immediately when the triggering condition occurs.

What it does:

Notifies you when foot traffic at a specific location has exceeded a configured threshold since the last time a cleaner visited that location. This is the primary signal to dispatch a cleaner to a high-traffic area before conditions deteriorate.

When it fires:

In real-time, the moment the occupancy sensor count crosses the threshold. The threshold is configured per-location in Mero. The counter resets each time a cleaner visit is recorded at that location (including transient visits).

Use cases:

Trigger automated work orders, send alerts to supervisors, or feed into a facilities dashboard to prioritize cleaning in busy areas.

Example payload:

What it does:

Notifies you when a consumable dispenser (paper towel, toilet paper, soap, etc.) has been detected as empty by its sensor. This means the supply needs immediate replenishment.

When it fires:

In real-time, as soon as the consumable sensor reports an empty reading. Each sensor monitors a specific dispenser at a specific placement position (e.g., "Left" paper towel dispenser in a restroom).

Use cases:

Trigger restocking alerts, create work orders, or track consumable usage patterns over time.

Example payload:

What it does:

Notifies you when a consumable dispenser has been refilled. The sensor detects that the supply level has returned to full. This is the counterpart to notification.consumable_empty and confirms that restocking has been completed.

When it fires:

In real-time, as soon as the consumable sensor detects a refill. The payload structure is identical to notification.consumable_empty.

Use cases:

Confirm that a restocking work order has been fulfilled, track refill response times, or close out open alerts.

Example payload:

Payload fields are identical to notification.consumable_empty.

What it does:

Notifies you when any sensor in your deployment has stopped communicating. This covers all sensor types: occupancy counters, consumable dispensers (paper towel, toilet paper), and presence sensors. An offline sensor means that location is no longer being monitored until the issue is resolved.

When it fires:

In real-time, when the system's device state monitor detects that a sensor has not reported within its expected heartbeat window. The last_seen_at field tells you when the sensor last communicated.

Use cases:

Trigger maintenance tickets, alert facility managers to connectivity issues, or flag gaps in monitoring coverage.

Example payload:

What it does:

Notifies you when a basestation (the hub device that receives signals from beacons and sensors) has stopped communicating. A basestation going offline typically means that all sensors and beacons connected through it will also stop reporting data.

When it fires:

In real-time, when the system's basestation state monitor detects that the basestation has not reported within its expected heartbeat window.

Use cases:

Trigger urgent maintenance tickets, alert IT teams to network or power issues, identify locations that have lost monitoring coverage.

Example payload:

These events track the lifecycle of cleaning shifts.

What it does:

Notifies you the moment a cleaner physically begins work on a shift. A shift being scheduled does not mean it has started — this event fires only when the first verified cleaner visit is recorded at one of the shift's assigned locations.

When it fires:

In real-time, when the system records the first valid, verified cleaner visit against any of the shift's task locations during the shift's time window. Only fires once per shift.

Use cases:

Confirm that scheduled cleaning has begun, track shift start punctuality, trigger SLA timers, or update a live operations dashboard.

Example payload:

What it does:

Notifies you that a shift's scheduled time window has closed. This is a pure lifecycle signal — it tells you the shift period is over, but does not include visit data, task completion, or performance metrics. Those come later in shift.finalized.

When it fires:

In real-time, when the shift end cron detects that the current time has passed the shift's ended_at time. This fires regardless of whether any cleaning occurred.

Use cases:

Mark the shift as "ended" in your system, start a countdown for the finalized report, or trigger follow-up workflows for shifts where no shift.first_visit was received (meaning the shift may have been missed).

Example payload:

What it does:

Delivers the complete, definitive results of a shift after all data has settled. This includes every cleaner visit recorded during the shift, the completion status of every task in the shift's scope, and the overall shift completion percentage. This is the event to use for performance reporting and SLA tracking.

When it fires:

Approximately 60+ minutes after the shift ends. The system waits for visit data to settle (late-arriving sensor pings), then runs a completion calculation job.

Why the delay?

Beacon data can arrive with some lag. The system gives a buffer period for all visit data to be recorded and processed before calculating final results, ensuring accuracy.

Use cases:

Generate shift performance reports, calculate SLA compliance, compare expected vs. actual cleaning time, feed into billing systems, or sync task completion to external CMMS/IWMS platforms.

Example payload:

What it does:

Delivers a batch of all cleaner visits from the past 60 minutes for a given cleaner. Unlike shift events, this is independent of shifts — it fires for any cleaner who had visits in the window, whether or not they were on a scheduled shift. Each cleaner with activity gets their own separate webhook delivery.

When it fires:

Every 60 minutes on a cron schedule. One webhook is sent per cleaner per organization that had activity in the window.

Use cases:

Build a near-real-time feed of all cleaning activity, power live dashboards that aren't tied to shift schedules, track ad-hoc or unscheduled cleaning work, or sync visit data to external systems on a regular cadence.

Example payload:

These webhooks are dispatched once per day and contain data for the previous day.

Example:

If an organization's delivery_hour is set to 18 and their timezone is America/Toronto, the reports will fire at 6:00 PM ET and contain all shift data from the previous day.

Only report types that are individually enabled (daily_report_enabled, total_time_worked_enabled, cleaning_report_enabled) will be sent.

What it does:

Delivers a comprehensive daily performance report for the previous day. For each shift that ran, it breaks down every assigned location showing: how long the cleaner was expected to spend there, how long they actually spent, the variance between the two, and which cleaners visited.

When it fires:

Once per day at the organization's configured delivery_hour. Reports on all shifts from the previous calendar day.

Use cases:

Daily cleaning compliance reviews, variance analysis, cleaner accountability, and client-facing SLA reports.

Example payload:

What it does:

Delivers a simple summary of how much time each cleaner spent working in each building on the previous day. Aggregated from all valid cleaner visits — grouped by building and cleaner. Unlike the daily report, this is not tied to specific shifts or task schedules.

When it fires:

Once per day at the organization's configured delivery_hour.

Use cases:

Payroll verification, labor cost allocation per building, contractor billing, and workforce utilization analysis.

Example payload:

What it does:

Delivers a scope-of-work completion summary for the previous day, broken down by location category (e.g., "Restrooms", "General", "Kitchen"). For each category, it shows how many locations were assigned vs. how many had all their tasks completed. A location counts as "cleaned" only if all tasks assigned to it were completed.

When it fires:

Once per day at the organization's configured delivery_hour.

Use cases:

Scope-of-work compliance tracking, client reporting by area type, identifying which categories of spaces are consistently under-serviced, and contract SLA reporting.

Example payload:

These endpoints are authenticated with the X-Webhook-Secret header — your organization's webhook secret key.

Bulk lookup endpoint for resolving location IDs to full entity details. Useful for mapping IDs from webhook payloads to location metadata.

Headers:

Example request:

Example response:

All requested IDs must belong to the authenticated organization. Returns 403 if any ID belongs to a different organization, 422 if IDs are missing or invalid.

Send a test webhook with a generated fake payload to validate your endpoint.

Headers:

Body:

Valid event_type values:
​notification.basestation_offline, notification.consumable_empty, notification.consumable_full, notification.sensor_offline, notification.traffic_alert, shift.first_visit, shift.ended, shift.finalized, cleaner.visit_log, report.daily_report, report.time_worked, report.cleaning_report

Response:

All entity references in webhook payloads use UUIDs and follow a consistent {id, name} pattern:

Use the Location Lookup API to resolve location IDs to full entity details including associated sensors, networks, and device information.

Used for locations, floors, buildings, cleaners, and campuses:

Further reading: Svix App Portal documentation