Evoko Home integration: introduction and functional background

What is Evoko Home?

Evoko Home is the management platform behind the Evoko Liso room displays — the touchscreens next to a meeting room that show whether the room is free or busy and on which you can book on the spot. i-Reserve connects to Evoko Home to synchronise bookings bidirectionally: bookings from i-Reserve appear on the right display, and bookings someone makes on a display flow back as a booking into i-Reserve. Functionally comparable to the Outlook and Google Calendar integration, but for the on-site room displays.

How the integration works

The integration works in two directions, linked per room:

1. Outbound (i-Reserve → display). An i-Reserve object (product) is linked in the mapping to a specific Evoko room. Once a booking reaches a configured status, i-Reserve pushes the booking to that room (create). On another status the booking is removed from the display again. Updates and check-in (confirm) work the same way.
2. Inbound (display → i-Reserve). If someone books directly on a display, i-Reserve picks that up through a poll: every few minutes i-Reserve requests the current state of all bookings and compares it with what it already knows. A booking present on the display but not with us is created as a booking; a booking that disappeared from the display is cancelled on our side.

Technology: DDP over WebSocket

Evoko Home offers no REST API and no webhooks. Communication runs over DDP (Meteor’s JSON messaging protocol) on a WebSocket connection (wss://). i-Reserve opens an outbound connection to the Evoko Home server, logs in and fires the required commands. No extra runtime or daemon runs; the inbound side is a short-lived poll task, not a permanently open connection.

• Outbound commands: createBooking, updateEvent, deleteEvent, confirmMeeting (check-in).
• Inbound query: allBookings (snapshot of all bookings) and allRooms (all rooms with their roomIds, needed for the mapping).

Authentication

i-Reserve logs in with an integration user (default defaultDevIntegrationUser) and a group token. That token is the “Default API Token” under Global Settings in Evoko Home and acts as the password. The connection is encrypted (wss); a session stays valid for a long time and i-Reserve logs in again per synchronisation.

Room mapping

The heart of the integration is the mapping: each i-Reserve object (product) is linked to an Evoko roomId. i-Reserve fetches that room list live with allRooms (the “Refresh room list” button). Only mapped rooms are synchronised; bookings on unlinked rooms are ignored.

Paid rooms

A booking on a display bypasses i-Reserve’s normal payment flow. For paid rooms it is therefore configurable how inbound bookings are handled (the paid-room policy): sync outbound only, reject inbound, or allow. The safest choice is the default, so no unwanted free booking appears on a paid room. Also give inbound bookings a non-charging status.

Limitations / things to watch

• Poll latency. A display booking becomes visible on our side after at most one poll interval (configurable, typically 1–2 minutes). On the display itself the booking shows immediately of course.
• 7-day window. Evoko’s bookings collection usually syncs 7 days ahead; the inbound horizon is therefore also ~7 days.
• Quarter hours. Evoko only accepts end times on :00/:15/:30/:45; i-Reserve rounds outward towards Evoko.
• PIN. If PIN authentication is enabled on the rooms, change commands require a PIN (otherwise PinIsRequired).
• Certificate. Port 3002 ships a self-signed Evoko certificate by default; TLS verification is then off (advice: install a valid public certificate).