Native booking system integration: what it really means
And why middleware is not enough
What “integration” can mean
In the self-storage world, “integration” with a booking system is often used loosely. Sometimes it means: the systems share the same login. Sometimes it means: there’s an export function so data can be manually transferred. And sometimes it means a real, bidirectional, event-driven integration where both systems are permanently in sync.
The difference matters enormously in practice.
The middleware trap
Many access control providers offer integrations via middleware — a third system that sits between the booking tool and the access system, transfers data on a schedule, and synchronises both sides.
This sounds practical, but creates several problems:
Latency: Middleware typically polls in cycles — every 5, 15 or 30 minutes. A booking that arrives at 14:01 may not be processed until 14:30. The tenant tries to access at 14:15 and is locked out.
Error propagation: If the middleware fails, both systems diverge. Neither access system nor booking tool notices immediately — until a tenant is locked out or an access remains active after cancellation.
Maintenance overhead: Three systems instead of two. Every API change in the booking tool can break the middleware. Update cycles are independent, compatibility must be actively maintained.
What a native integration looks like
sedisto uses direct integrations via event webhooks. When a booking is created in Kinnovis or Storeganise, the booking system immediately sends a webhook to sedisto. sedisto processes the event, creates the access right, and confirms back — the whole thing in under three seconds.
The same happens with cancellations, changes, payment events. Every relevant action in the booking tool triggers an immediate access update. No polling, no middleware, no waiting.
Bidirectionality: the overlooked aspect
Integration usually focuses on the direction booking → access. But the reverse direction is equally important: access → booking.
When a door is opened, sedisto sends an event back to the booking system. This makes it possible to:
- Track last access (important for empty-space management)
- Verify that tenants actually use their space
- Automatically flag suspicious activity (access outside contracted times)
Kinnovis shows this access data directly in the tenant profile. Operators can see at a glance when someone last accessed their unit — without having to check the access system separately.
What to look for in evaluation
When evaluating an integration, ask these questions:
Webhook or polling? Webhooks are event-driven and near-real-time. Polling is always delayed and creates unnecessary load.
Bidirectional? Does the access system also send events back to the booking tool?
Error handling: What happens if a webhook cannot be delivered? Is it retried? How many times, with what backoff?
Testing environment: Is there a sandbox that simulates the full event flow? Testing in production is not an option.
Documentation: Is the webhook schema documented and versioned? Does the provider communicate breaking changes in advance?
sedisto publishes the OpenAPI specification for all integrations and provides a sandbox with full event simulation. Operators and developers can test the complete integration before going live.
