Gym Door Access Control + Member App: How the Integration Actually Works

There are two ways a door integration fails, and both of them are expensive. A paying member stands outside at 5:30am and the door doesn't open. Or a member who cancelled six weeks ago walks in every morning because nobody's sync job noticed. Everything in this article exists to prevent one of those two outcomes.

This is the technical version — what the access control APIs actually give you, how the three credential types behave in the real world, what breaks when the internet goes down, and what you take on when you unlock the building at 2am with nobody in it.

The architecture in one paragraph

Your gym management software is the system of record for membership state: who is paid up, frozen, in a contract, banned, or a guest on a day pass. The access control platform is the system of record for credentials and doors: which token opens which reader at which hours. The integration is two flows in opposite directions — you push membership state into the access system, and you pull door events back out. Almost every real-world problem is a latency, ordering or reconciliation failure in one of those two flows.

That's it. It's not complicated. It's just unforgiving.

What the access control vendors actually give you

The cloud access control market has consolidated around a handful of platforms that a gym is likely to encounter, and they are not equivalent from an integration standpoint.

Brivo is one of the older cloud-native platforms and is common in multi-site commercial deployments. It exposes a REST API with OAuth-style authentication behind a developer program you apply to, covering users, groups, credentials, schedules and event retrieval. Practically: you get programmatic control over people and their credentials, and you get access events, but you should plan on an application and approval step before you have keys in hand.

Avigilon Alta — the platform formerly sold as Openpath, now under Motorola Solutions — is built around mobile credentials from the ground up. Its differentiator is the multi-modal unlock: tap in the app, wave a hand near the phone, or unlock remotely. That's attractive for gyms because it works with the phone in a pocket. It also has an API for user and credential management.

Kisi has the most openly documented API of the mainstream options — public docs, straightforward REST, webhooks — which matters a lot when you're building rather than buying. It's widely deployed in coworking and boutique fitness, and it supports both phone credentials and cards.

Gantner is the one most often overlooked by developers and most often already installed in a large fitness facility, because it also owns the locker and wristband side. If your operator has electronic lockers, check what's on the wall before you pick an access vendor.

Also in the field: SALTO (including offline door locks that carry permissions on the credential itself), PDK, Verkada, Genea, and Paxton Net2 on the on-premise side.

The four API capabilities you must confirm before signing

Do not evaluate access control vendors on the marketing site. Ask these four questions and get written answers:

1. Can I create, suspend and delete a credential programmatically, and how fast does that take effect at the door? "The API returns 200" and "the reader has actually stopped accepting that card" are different events, sometimes minutes apart.
2. Do I get access events pushed to a webhook, or do I have to poll? Polling is fine at gym volumes but changes your architecture and your attendance latency.
3. Do events include denials, not just grants? Denied entries are the single most valuable signal you'll get — they're your failed-payment early warning and your credential-sharing detector. Some platforms report grants generously and denials thinly.
4. What is the local cache behavior when the site loses internet? See below. This is the one that decides whether your gym opens on a bad Tuesday.

Credential types: QR vs NFC vs BLE

This is the decision that determines your hardware bill, your support load, and whether members like the thing.

QR is cheap and leaks

A QR code is a bearer token displayed on a screen. If it's static, it is a photograph away from being shared with the member's entire training group, and you will not detect it without exit reads or camera review. The only defensible QR implementation is a short-lived rotating code: the app holds a device-bound secret provisioned at login, derives a time-based code locally (the same pattern as an authenticator app), and the door validates it server-side or against a cached secret. Rotate on the order of seconds to a minute.

Crucially, deriving the code locally means it still works when the member has no signal in a basement gym. A QR implementation that fetches a fresh code from your API on every scan is a QR implementation that fails in exactly the places gyms are built.

NFC is the best experience and Apple owns the gate

On Android, an app can emulate a contactless card through host card emulation, and a modern NFC reader will accept it. On iOS this has historically not been available to third-party apps at all — the NFC hardware was reserved for Apple Pay and Wallet. Apple has since opened a path for third-party in-app contactless transactions under a specific entitlement, commercial agreement and fee, with region limits.

What that means practically, today: if you want iPhone users to tap their phone at your door, you almost certainly go through Apple Wallet, and adding a credential to Wallet requires the access control vendor to have an agreement with Apple. It is not something you build yourself. Several major access vendors support Wallet passes for access; that support is a purchasing criterion, not an engineering task on your side.

The other NFC trap is the reader you already have. A large number of installed gym readers are 125 kHz proximity readers reading HID Prox or EM-format cards. Those are one-way, unencrypted, and cloneable in seconds with a device that costs less than a month's membership. They also cannot read a phone, ever, at any software version. If phone-based entry is the goal and you have prox readers on the wall, you're buying readers.

If you're replacing readers anyway, specify the credential technology explicitly. MIFARE Classic's Crypto-1 cipher has been publicly broken for years and should not be specified for new installs. Current-generation options are MIFARE DESFire EV2/EV3 and HID Seos/iCLASS SE.

And while you're in the wiring: Wiegand is not a secure protocol. It's a one-way, unencrypted signalling standard from the 1980s, and an attacker with a minute of access to the reader's back can install an inline device that captures every credential presented and replays them later. The replacement is OSDP with Secure Channel over RS-485, which is authenticated and encrypted, and supports bidirectional communication. If your integrator is quoting Wiegand for a new 24-hour site, ask why.

BLE is the best-feeling and the hardest to make reliable

Bluetooth Low Energy unlock is what members mean when they say "I want it to just open." It's also where the engineering time goes.

The core problem is that iOS aggressively limits what an app can do in the background. An app that isn't running cannot simply be scanning for a door all day. The workable patterns are beacon region monitoring — where the OS wakes your app when it enters a monitored region, which requires "Always" location permission and a permission conversation with the member — plus Core Bluetooth state restoration so the app resumes correctly after the system has killed it. Android has its own background execution restrictions and OEM-specific battery optimizers that will happily kill your service on some handsets and not others.

Then there's range. BLE range estimation is based on signal strength, which is affected by the phone being in a pocket, a hand, a bag, or behind a person. Tune the threshold too generously and the door unlocks as members walk past on the street. Tune it too tight and it only works if they hold the phone against the reader, at which point you built an expensive NFC.

The pattern that works in practice is not a single credential type. It's BLE or Wallet-tap as the primary path, with a manual in-app button as the always-available fallback, and a physical fob available at the desk for the member whose phone is dead. Every 24-hour gym eventually learns that "phone only" means "and also we need a way to let people in when their phone is dead at 6am."

The sync layer: designing for the 5:30am lockout

Here's the part that's actually your code.

Push membership state, don't push events. Your access system should be able to answer "what is the correct access state for member 4417?" from a single source. Build a function that computes desired state — active/suspended, which door groups, which time schedule — from your membership ledger, and a reconciler that makes the access platform match it. Do not scatter revokeAccess() calls through your billing code. Every time someone adds a new membership status, the scattered version breaks.

Reconcile on a schedule regardless of webhooks. Webhooks get lost. API calls fail. A nightly full reconciliation between your membership ledger and the access platform's credential list, with a diff report someone actually reads, is the difference between finding out about a drift problem from your own log and finding out from an ex-member's Instagram post about training for free.

Make every write idempotent and log the intent. When you replay a failed sync, it must not create a second credential for the same person. Store the access platform's credential ID against your member record and treat it as a foreign key.

Decide your revocation latency deliberately and write it down. When a payment fails at 11pm, is the member locked out at 11:01pm, at the next scheduled sync, or after a three-day grace period? This is a business decision, not a technical one, and the correct answer for most gyms is a grace period — because the cost of a wrongly locked-out member in a public entrance at peak hour is much higher than three days of free training. Encode the grace period in your software, where the front desk can see and override it. Don't encode it in the access platform where nobody can find it.

Dedupe inbound events. Access events arrive with vendor-assigned IDs. Use them as an idempotency key. Webhooks retry, and a member who checked in once should not show three visits in their retention profile.

What happens when the network drops

Three separate networks can fail, and they fail independently. Design for each.

The site loses internet. This is the one that matters. A cloud access control system that stops opening doors when the ISP goes down would be unsellable, so mainstream controllers hold a local credential cache and continue making grant/deny decisions offline, buffering events until they reconnect. But the specifics vary and they matter enormously: how many credentials are cached, whether schedules and time restrictions are cached with them, how long the event buffer holds, and what happens to a credential you revoked ten minutes before the outage. Get these numbers from the vendor in writing.

The member's phone has no signal. Common in basement and steel-frame buildings. Your credential must be usable offline: a device-bound rotating token, a Wallet pass, or a BLE credential provisioned to the phone in advance. If your unlock flow requires an API round-trip at the door, it will fail for a predictable set of members every day.

Your server can't reach the access platform's API. Doors keep working, because the controller has the cache. What breaks is your provisioning: new members can't be added and cancellations can't be revoked. Queue writes durably, retry with backoff, and alert when the queue depth exceeds a threshold. An access sync queue that silently backs up for a week is how the "cancelled member still training" story starts.

Separate from all of this is the power question, which is not a networking question and is not yours to answer alone. Fail-safe (unlocks on power loss) versus fail-secure (stays locked) is governed by fire and building code, egress requirements, and your local authority having jurisdiction. Free egress from inside the building is a life-safety requirement, not a configuration option, and magnetic locks in particular carry specific code obligations. Take this from your fire alarm contractor and your AHJ, not from your software developer and not from this article.

24-hour unstaffed access, and the liability that arrives with it

Unlocking the building overnight is a revenue decision that quietly becomes a risk decision. The technical controls exist to manage a small number of very specific scenarios.

Tailgating is the biggest one, and it's both a revenue leak and a safety problem — an unbadged person is in your building at 3am and you have no record of who. A swing door cannot prevent it. Optical turnstiles or a full-height turnstile at the entry can; so can camera-based tailgating analytics, imperfectly. Whatever you choose, your software's job is to surface the signal: a grant event with no corresponding member activity, or occupancy that doesn't reconcile.

Anti-passback — preventing one credential from being used twice without an exit in between — requires exit reads. If you only read on the way in, you cannot do true anti-passback and you cannot count occupancy accurately. Adding an exit reader is a hardware line item people skip and then wish they hadn't. Soft anti-passback (log and flag) is usually better for gyms than hard anti-passback (deny), because denying a member entry over a data artifact at 6am generates a very bad morning.

Lone occupant emergencies. The reason a member is in your building alone is the reason 24-hour access is valuable and the reason it's frightening. The mitigations are physical and procedural more than they are software: panic and duress buttons throughout the floor, monitored video, and in many cases a third-party monitoring service. Your software contributes occupancy awareness — knowing someone is inside, knowing how long they've been there, and being able to escalate.

Minors, AEDs, insurance and local rules. Several US states have statutes governing AEDs in health clubs, and rules around unsupervised access for members under 18 vary by state and sometimes by municipality. Insurance carriers frequently attach their own conditions to unstaffed hours — video coverage, emergency communication, specific signage. None of this is software, and all of it lands on the operator.

Zee Palm builds the software side of this. We don't provide legal advice, we don't determine your insurance obligations, and we'd rather say so than let you assume otherwise.

The part that pays for itself

Door events are the highest-quality behavioral data a gym has, and most operators never use them. Visit frequency measured against a member's own established baseline is the best early churn signal in the business — better than any survey, better than any NPS score, and available every single day.

Once the events are flowing into your system, the useful build is small: a rolling visit-frequency score per member, a flag when it drops materially against that member's own norm, and a queue for whoever does retention outreach. That's a dashboard, not a platform. We build those from $799, and it is genuinely the highest-return thing you can do with an access integration.

Denied-entry events are the second gift. A cluster of denials at a specific reader means a hardware problem. A denial on a member with an active membership means a sync bug you'd otherwise never see. A denial on a cancelled member means your revocation worked — log it, because that's the number that justifies the project.

What this costs

Access integration is not a standalone package on our price list, because it's always part of a larger system. The relevant bands:

• MVP Planning Sprint — $1,500, 5 days. For an access project specifically, this is where the vendor evaluation, credential-type decision and offline behavior get resolved on paper. Credited toward the build.
• MVP build — from $12,000 for the membership and access layer as a bounded version one.
• Full custom build — from $25,000 where you need multi-site, a member app and the analytics layer together.
• App maintenance from $1,000/mo. Access control is life-critical to a gym's operations. It needs monitoring and someone on call.

More on how we approach it on the gym management software page, and if you're a multi-site operator, what we do for gyms and studios.

If you're evaluating vendors right now, tell us what's on your wall — reader model, controller, whether there's an exit reader — and we'll tell you what's integrable and what needs replacing before anything else is worth discussing.

Frequently asked questions

Which gym management software integrates with door access control?

Most established gym platforms integrate with at least one access vendor, but the depth varies enormously — some only push a member list nightly, which means a cancelled member can train for another day. What you want to confirm is bidirectional: real-time or near-real-time credential revocation, and inbound access events including denials. If your platform only does one direction, a custom integration layer between your software and the access API is often a smaller project than switching platforms.

Can members open the gym door with their phone instead of a keyfob?

Yes, through one of three mechanisms: a rotating QR code scanned at a camera reader, an NFC tap (via Apple Wallet on iPhone, or host card emulation on Android), or a Bluetooth unlock from your app. Which one is available depends entirely on the reader hardware installed — 125 kHz proximity readers, still very common in gyms, cannot read a phone at all and must be replaced.

What happens if the internet goes down — can members still get in?

With mainstream cloud access control, yes. The door controller keeps a local copy of valid credentials and keeps making decisions offline, buffering the event log until it reconnects. The details vary by vendor and are worth getting in writing: how many credentials are cached, whether time schedules are cached too, and how a revocation issued just before the outage is handled.

How do I stop members sharing a QR code with their friends?

Don't use a static QR. Use a short-lived rotating code derived on the device from a secret provisioned at login — the same mechanism as a two-factor authenticator app — so a screenshot is worthless within seconds and the code still works with no phone signal. Pair it with exit readers so you can spot the same credential entering twice without leaving, and with a turnstile if tailgating is your real problem.

Is a fingerprint or face reader a better option for 24-hour gyms?

It solves credential sharing definitively, and it brings a category of privacy law with it — Illinois' BIPA in particular carries a private right of action and statutory damages per violation. For most operators, the honest answer is a rotating phone credential plus a turnstile, not biometrics. We covered the full trade-off in biometric gym access: build considerations, privacy law and cost.

How long does an access control integration take to build?

The API wiring is typically the fastest part. The calendar goes into the reconciliation design, the grace-period and revocation rules, offline behavior, and testing against real hardware — which means being physically at a door, opening it, and watching events arrive. Budget for on-site QA. A sync tested only against sandbox data will fail in the building.