What a booking layer should and should not replace in SiteLink

The first conversation we have with most operators interested in StorageFlo.io eventually arrives at the same question: "If I plug your booking widget into my site, am I replacing SiteLink?"

The answer is no. And it should be no.

A booking layer is the renter-facing path from a Google search to a reserved unit. SiteLink (or storEDGE, or Easy Storage Solutions, or Hummingbird) is the system of record for the property, every tenant ledger, every gate event, every late fee, every auction. Replacing that with a booking layer is replacing the wrong half of the stack.

This piece draws the seam carefully so you can tell which work belongs on which side and what to expect when a connector says "live".

What stays in SiteLink

The operational system keeps the data and the workflows that the front desk team uses every day. Specifically:

• Tenant ledgers. Every charge, payment, refund, write-off, auction-recovery line, and credit memo lives in SiteLink. The booking layer does not write to the ledger; it tells SiteLink "this renter reserved this unit at this rate on this date" and SiteLink books it on the system of record.
• Recurring billing. Autopay, late fees, payment retries, expired card retry logic. These run inside SiteLink because they are tied to the existing ledger, the existing merchant of record, and the reporting your team already runs.
• Gate access. Gate codes, access schedules, lockouts, gate event logs. SiteLink integrates with the gate controller; the booking layer does not.
• Rate management. Standard rate, street rate, rate plans, ECRI rules, manager overrides. These stay in SiteLink because the property's pricing system is intentionally a single source of truth. The booking layer reads rates; it does not set them.
• Operational reporting. Daily close-out reports, manager logs, occupancy by unit type, delinquency reports, the auction roster. Built and trusted in SiteLink.
• Day-to-day team workflow. The manager opens SiteLink in the morning and closes it at end of shift. The booking layer is intentionally invisible to that workflow.

What flows through the booking layer

Everything that touches the renter's experience before the reservation becomes a tenant. Specifically:

• Live availability. The booking layer pulls available units and current rates from SiteLink on a short polling interval (60 seconds for active sessions). Renters see what is actually rentable in real time.
• Unit selection. The renter picks the size and, where supported, the specific unit. The booking layer holds the unit for the duration of the session so two renters cannot reserve the same unit at the same time.
• Reservation handoff. When the renter checks out, the booking layer writes the reservation back to SiteLink, tenant info, chosen unit, move-in date, agreed-upon rate. SiteLink confirms the reservation as if a manager had keyed it.
• Pre-move-in payments. Reservation fee, first month's rent paid online, insurance selection. Payment flows through the supported processor and the reservation lands in SiteLink with the payment attached.
• Pre-move-in lease. Optional. If the operator turns on the in-flow lease, the renter signs a templated lease before move-in day. The signed PDF lands against the SiteLink reservation record.

The seam, in one diagram

                       Renter (after-hours, Google search,
                              competitor comparison)
                                       │
                                       ▼
              ┌─────────────────────────────────────────────┐
              │   Booking layer (StorageFlo.io widget)      │
              │   • Live availability (read from SiteLink)  │
              │   • Unit selection + hold                    │
              │   • Reservation form (4 fields)              │
              │   • Payment via supported processor          │
              │   • Optional in-flow lease signing           │
              └─────────────────────────────────────────────┘
                                       │
                                       ▼
                        Reservation write to SiteLink
                                       │
                                       ▼
              ┌─────────────────────────────────────────────┐
              │   SiteLink (system of record)               │
              │   • Tenant ledger, billing, gate, reports   │
              │   • Manager workflow unchanged              │
              └─────────────────────────────────────────────┘

The arrows go in one direction at the seam. The booking layer reads availability and writes reservations. It does not own any tenant record. It does not own any payment ledger entry. It does not own gate access.

What "live connector" actually means

When we say "the SiteLink connector is live", we mean exactly four things are working end-to-end:

1. Availability sync. The booking layer can read the unit list with current statuses and rates within the polling interval.
2. Reservation write. A completed reservation lands in SiteLink as a confirmed reservation with the correct tenant, unit, date, and rate. The booking layer surfaces SiteLink's reservation ID back to the renter.
3. Rate read. Rate changes the manager makes in SiteLink show up in the booking layer within the polling window.
4. Cancellation propagation. If the renter cancels in the booking layer (or the operator cancels in SiteLink), both sides agree on the state within a minute.

A connector that does three of these and fakes the fourth is not live. The line "the connector is live" is the line we hold ourselves to.

What a booking layer should not try to replace

If a vendor pitches you a booking flow that wants to take over billing, gate access, rate management, or operational reporting, they are asking you to replace SiteLink, not augment it. That is a six- to twelve-month migration project with real operational risk, you are betting that a brand-new system will do every operational job your existing FMS does, plus the new renter-facing job, without dropping anything. Most operators we talk to are not interested in that trade and should not be.

A booking layer that respects the seam is a much smaller commitment: two lines of code on your website, a one-time SiteLink credential exchange, and a five-day path from sign-up to first online reservation. Everything operational stays where it has worked for years.

What to ask a booking-layer vendor

Three questions cut through most of the vendor-pitch fog:

1. "Show me the reservation that lands in SiteLink when I complete a booking in your widget. What does the record look like?"
2. "What does your connector do when SiteLink is unreachable for ten minutes?"
3. "If my standard rate changes in SiteLink at 2:00 p.m., when does the booking widget show the new rate?"

If the answers are vague, the connector is not actually live in the sense that matters.

If they are precise, you are talking to someone who has drawn the same seam this article describes.