FAQ About Webhook Occupancy Integration

The most common webhook occupancy integration failure isn't a bad payload — it's an endpoint that returns a 200 before it has actually written the data. The sender thinks delivery succeeded, drops the message from its queue, and the count silently disappears. If you've built HVAC scheduling or meeting-room release logic on top of that, you're now making decisions on stale numbers without knowing it. So before we get into schemas and signing, understand that a webhook is a promise between two systems about what "received" means. Most of the questions below come back to that promise.

What exactly gets pushed, and how often?

A well-designed occupancy webhook sends compact event payloads: a zone or sensor identifier, a timestamp (in UTC, ideally ISO 8601), the current or delta count, and an event type. You'll typically choose between event-driven pushes (fire when someone enters or exits a zone) and interval-based pushes (aggregate every 1, 5, or 15 minutes). For live dashboards and door control, event-driven wins. For analytics warehouses, interval aggregation reduces noise and write load. Vemco's counting is aggregate by design — no personal identification, staff excluded from figures — so the payload carries counts and zone context, never anything that identifies an individual. That matters for your data-protection review before the first byte leaves the building.

How accurate are the numbers I'm receiving?

The webhook only carries whatever the sensor measured, so accuracy is set upstream. Vemco's contractual minimum is 96%, with 98–99% typical when lighting, store or floor layout, and visitor behaviour cooperate. Don't quote a flat 99% to your stakeholders — a wide entrance with backlighting or crowd surges will pull real-world figures toward the lower end. A practical habit: log the raw webhook counts alongside a periodic manual spot-count during commissioning, so you can show where your specific site actually lands within that band.

How do I secure the endpoint?

Treat every inbound webhook as untrusted until proven otherwise. Three layers cover most cases:

• HMAC signature verification — the sender signs the payload with a shared secret; you recompute and compare before processing. This blocks spoofed requests.
• TLS everywhere — HTTPS only, and reject anything on plain HTTP.
• IP allow-listing — where the sender publishes stable ranges, restrict at the firewall as a second gate.

Vemco runs on hosted or private cloud and integrates with existing IT systems, which means your security team can decide where data lands and how the endpoint sits relative to your network perimeter. Because the data is aggregate and non-identifying, the GDPR footprint stays lighter than most building telemetry — but you should still document the flow. (Confirm current certification and SSO details directly with Vemco rather than assuming them.)

What happens when my endpoint is down?

This is where teams get burned. If your receiver goes offline for maintenance and the sender has no retry policy, you lose that window permanently. Ask two questions during procurement: does the sender retry on failure, and with what backoff? A sensible pattern is exponential retry over several attempts, then a dead-letter queue you can replay. On your side, make the endpoint respond fast — acknowledge receipt, then process asynchronously. If you do heavy database work inside the request handler and it times out, the sender sees a failure and retries, and now you're processing the same event twice.

How do I stop double-counting on retries?

Idempotency. Every event should carry a unique ID. Store processed IDs (a short-lived cache or a dedup table works) and discard duplicates before they touch your counts. A practitioner detail rarely mentioned in vendor docs: retried webhooks can arrive out of order, so a later event may land before an earlier one. If your occupancy logic assumes strict sequence, an out-of-order delta will corrupt the running total. Order by the event timestamp, not arrival time, and reconcile against interval snapshots.

Webhook, polling, or MQTT — which do I pick?

Webhooks push to you, so you avoid the wasted requests of polling an API every few seconds for data that hasn't changed. That's the right choice when you need near-real-time reaction — releasing an unused meeting room, dimming lighting in an empty zone, or triggering a cleaning task at a capacity threshold. Polling still has a place for batch reporting where a five-minute delay is fine and you want full control over request timing. MQTT suits high-frequency device meshes inside a building. Many integrations use a mix: webhooks for events that drive automation, a pull API for backfilling gaps after downtime.

How do I test before going live?

Stand up a staging endpoint and have the sender fire sample payloads at it. Verify signature checking rejects tampered requests, confirm your handler survives malformed JSON without crashing, and simulate a downtime window to watch retries and replay behave. Then run a live pilot in one zone for a week and compare webhook-driven counts against the sensor's own dashboard. Discrepancies almost always trace back to timezone handling, dropped retries, or an over-eager load balancer closing idle connections.

Will this scale across many sites?

A single café is one thing; a portfolio across dozens of buildings is another. Vemco has operated since 2005 with more than 2,000 customers across 95+ countries, so multi-site rollout patterns are well understood. The scaling questions are yours to answer: can your endpoint absorb concurrent bursts at peak, are events tagged clearly by site and zone, and can you throttle or queue without dropping data? Design for the busiest hour of your busiest location, not the average.

Talk to someone who has built these

If you're scoping a webhook occupancy integration and want payload schemas, retry expectations, and security details confirmed against your specific IT setup, get in touch with the Vemco team. Bring your endpoint architecture and target zones, and you'll leave with a concrete plan for accurate, GDPR-compliant occupancy data flowing into your building systems.