The short answer: condo visitor registration for Airbnb guests in Malaysia works when every booking gets its own gate pass, created by the building's visitor app with the guest's name, phone and car plate, valid only for the days of the stay, and sent to the guest before they reach the barrier. Doing it by hand for every booking does not scale.
Most of what you find when you search for this is written for the building, not for the host. Visitor management vendors describe how a resident invites a visitor and the guest gets a QR code. i-Neighbour's short-stay module, for example, lets a host send QR codes valid between an arrival and a departure time, lets management cap how many guest and vehicle QR codes each host can send per day, and applies a "1 vehicle QR code, 1 parking slot" rule (i-Neighbour). And whether short stays are allowed at all is the building's call under its by-laws (PropertyGuru).
This article is the other side: what an operator running many units across many buildings actually has to do, and how our own system, AntlerHub, does it for the 100+ units we manage in Johor Bahru, including the mistakes.
Why is visitor registration a problem for homestay operators?
Because every building does it differently, and the guest only finds out at the barrier.
With one unit, you open the building's app, type the guest's details and forward the QR. With a portfolio, you have a different guard app in almost every building, each asking for different fields, each issuing passes that last a different length of time. One missed registration means a guest stuck at the guard house at 11pm, calling you.
| What changes from building to building | Example |
|---|---|
| Which app the guard house uses | iCares, Veemios, eCommunity, GProp, CSS (Klik), or the building's own QR system |
| Which details are compulsory | Name, unit and phone everywhere; some also want an IC or passport number |
| How long one pass lasts | One day, up to 7 nights, or the whole stay |
| What comes back | A QR picture, a link, or an invitation text |
| Car or walk-in | A plate pass needs the plate; no plate means a walk-in pass |
When should the gate pass be created?
Not at booking time. At booking time you often do not have the guest's real phone number, their car plate, or even their name (OTA bookings arrive with a platform relay email).
In our system the pass is created automatically when the guest finishes the identity step on their booking page and moves on to payment or "unit ready". At that point we have a verified name, a phone number, and the plate they typed in for this booking. If the unit's building has a visitor system linked, the guest is registered with it right then. If the building has none, nothing happens and nothing fails.
Two details we learned the hard way:
- The plate comes from the booking, not the guest's account. We used to read the plate saved on the guest's account. A guest with two bookings and two cars got the same plate on both passes, and the second car could not get through the barrier. Now the plate typed in for that booking wins, and the account plate is only a fallback. The booking page already caps the number of plates at the unit's parking bays.
- The owner is not a visitor. When a unit owner books a stay in their own unit, we do not register them as a visitor on a third-party guard app. The building already knows who owns the unit, and writing a wrong fact into a system that is not ours is worse than skipping it.
How does a pass get created on an app we don't control?
There are two very different cases.
Our own QR system (AntlerQR). If the building's management uses AntlerSecurity, the pass is a record we create and can revoke. The QR on the guest's phone is signed with the current minute and changes every 60 seconds, so a screenshot forwarded to a friend stops working.
A third-party guard app. iCares, Veemios, eCommunity, GProp and CSS have no way for a property manager's software to connect to them. So a worker program logs into that app with the operator's account, fills in the visitor form the same way a person would, and brings back whatever the app produces: a QR picture, a link or an invitation text.
This is honest automation, not integration. If the app changes its screens, the run fails, and someone has to look at it. Which brings us to failures.
Why do long stays need a new pass every day?
Because some apps only issue one-day passes.
| Guard app | One pass covers | What we do for a 5-night stay |
|---|---|---|
| iCares, Veemios, CSS (Klik) | One day | One pass per day, each sent the night before |
| eCommunity | Up to 7 nights | One pass |
| GProp | The whole stay | One pass |
| AntlerQR | The whole stay | One pass |
We used to ask one-day apps for 7 days at once. The result came back as one very tall picture with five or more QR codes stacked on it, one of them blank, and every QR too small to scan at the gate. Since 23 October 2026 we ask for one day per job: one small picture, one message a day.
For stays longer than one pass covers, the next pass is created the night before it is needed, at an hour each operator sets (default 10pm). The worker can only create passes from today onwards, so a pass created on day 3 of a stay starts on day 3.
How does the pass reach the guest?
The moment the pass is ready, AntlerChat sends it to the guest:
- Inside WhatsApp's 24-hour window (or on WhatsApp Web, WeChat and other channels without that window), the guest gets the pass itself with the days it is valid for.
- Outside the window on the official WhatsApp line, the guest gets an approved template message with a button that opens their booking page, where the gate pass tile shows it.
Each finished job is recorded once before anything is sent, so the guest never receives the same pass twice. A sweep every 5 minutes picks up any finished pass that was not delivered (for example if the server restarted mid-send). Cancelled bookings and stays that have already ended are skipped. A pass a colleague uploaded by hand is not sent automatically; the colleague decides.
What happens when it fails?
The guest is not told, and a person is.
If the worker cannot create the pass, the guest's chat thread is flagged for a colleague with the reason (for example, the app rejected a phone number already registered to someone else). We do not message the guest with an error they cannot fix. If they ask for their pass before a colleague has sorted it out, the chat hands over to a person.
Real failures we have had:
- A whole guard app silently produced nothing. Every CSS (Klik) listing looked linked in the system but never produced a single pass, because one internal mapping was missing and the error was treated as "no security system here". Fixed, but it ran unnoticed for a while.
- WhatsApp and the website disagreed. In August 2026 our chat assistant knew a building required electronic ID verification and stopped offering a manual ID form; the booking page did not. The same guest got two answers. Now one rule answers both.
- A default nobody chose. The "require eKYC" setting had a database default of on. Read on third-party guard apps, which never ask for eKYC, it would have stopped arriving guests for a check the guard house does not perform. eKYC can now only be forced on our own QR system, where the building's management decides.
- Missing details. No phone number anywhere, or no IC or passport number for an app that requires one (Veemios and eCommunity do), means no pass. Those are skipped and left for the operator to fix, not the guest.
What should you check before automating gate passes?
| Check | Why |
|---|---|
| Does the building allow short stays at all? | No software fixes a by-law ban |
| Which app and which account does the guard house accept? | The pass is created under that account |
| How many days does one pass cover? | Decides how many messages a long-stay guest gets |
| Is the plate collected per booking? | Two cars, two bookings, two different plates |
| Who sees a failed pass, and how fast? | The guest arrives either way |
Visitor registration is one step of the check-in flow; the door code is the next. We wrote about that in how each booking gets its own door PIN, and about the guest's side of it in first-time homestay check-in in Johor Bahru. The messages around it are in the 9 moments we message guests.
The limits, said plainly
We do not control the guard apps. When one changes, passes fail until we adjust. A failed pass depends on a colleague noticing the flag. Long stays on one-day apps mean a message every night. And the guard house still decides who gets in.
If you run homestay units in Malaysian condos and want gate passes created and sent with each booking, AntlerHub does what is described above for the guard apps listed. Details and current pricing are at /antlerhub.