> For the complete documentation index, see [llms.txt](https://docs.podplay.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podplay.app/owners-playbook/data-and-security/geo-fencing-or-geo-location.md).
# Geo-fencing or Geo-location
### Overview
PodPlay cannot read a Customer's physical location, so no feature can depend on where a Customer is standing. That rules out:
1. Geo-fencing Reservations to a radius around the Club
2. Verifying physical presence at Check-in
3. Checking a Customer in automatically when they arrive
This feature has been evaluated several times since 2024. The two constraints behind the decision are platform-level, not PodPlay-level, and neither has changed.
### What Clubs ask for
Three requests come up most often:
* **Restrict who can book** — only allow [Reservation booking](https://docs.podplay.app/reservations/customer-books-a-reservation) or [Membership purchase](https://docs.podplay.app/memberships/types-of-memberships#monthly-membership-in-app) from Customers within a set distance of the Club
* **Verify presence at Check-in** — confirm the Customer is physically at the Club before [check-in](https://docs.podplay.app/overview/how-to-use-the-check-in-button) succeeds, so a Customer cannot [check-in](https://docs.podplay.app/overview/how-to-use-the-check-in-button) remotely
{% hint style="info" %}
Geo-fencing isn't necessary with a QR code as the Customer must physically be in the Club to scan their QR code.
{% endhint %}
* **Auto Check-in on arrival** — detect that the Customer reached the Club and allow [check-in](https://docs.podplay.app/overview/how-to-use-the-check-in-button) without a button tap
**All three need the same underlying capability: a reliable, continuous read of the Customer's location**.
### Impossible on Web App
Browsers do not give a web application usable location data, nor can it be forced upon the Customer. And a large share of Customers (all new Customers who do not download the iOS or Android App before booking) book through the [Web App](https://docs.podplay.app/owners-playbook/the-podplay-system/overview-of-tiers/further-details-of-tiers#basic) (the basis of your Club's environment and Dashboard) rather than the [iOS or Android App](https://docs.podplay.app/owners-playbook/the-podplay-system/overview-of-tiers/further-details-of-tiers#basic-1).
Any location rule would therefore apply to some Customers and not others, which makes it unusable as a booking restriction or a check-in gate.
A rule that a Customer can bypass by opening the Web App is not a rule.
### Always Optional on App
The iOS and Android App can request location access. Apple and Google both require the Customer to grant that permission on their own device, and the Customer can refuse it or revoke it later.
**That permission prompt sits directly in the purchase path**. A Customer who declines it, or who is asked for it before they have booked anything, is blocked by extra friction from completing a Reservation. Adding a mandatory location prompt to the booking flow costs Clubs completed Reservations. This friction is a larger problem than the problem geo-fencing intends to solve.
{% hint style="warning" %}
**Location permission cannot be forced.** Even on the App, the Customer can always decide to not share location data. There is no setting a Club or PodPlay can apply that grants location access on a Customer's behalf.
{% endhint %}
### What to use instead
Access control in PodPlay works on Customer identity (email + phone number), not Customer location. These options cover most of what Clubs want geo-fencing for.
#### Restrict who can book
* [**Hidden Membership**](https://docs.podplay.app/memberships/types-of-memberships/hidden-memberships) — the Membership does not appear publicly; only Customers you send the link to can purchase it
* [**Corporate Membership**](https://docs.podplay.app/memberships/types-of-memberships/corporate-memberships) **/** [**Local Business Partner**](https://docs.podplay.app/memberships/types-of-memberships/corporate-memberships/local-business-partner) — assign a hidden [Group Membership](https://docs.podplay.app/memberships/types-of-memberships#monthly-membership-in-app) to a defined set of Customers, such as a partner business's employees
* [**Promo Code**](https://docs.podplay.app/payments/promo-codes) — gate a price behind a code you distribute to the group you want to reach
* [**Booking Horizon**](https://docs.podplay.app/reservations/rules-limits-and-settings#booking-horizon) — limit how far in advance any Customer can book
#### Verify presence at Check-in
* [**QR Code check-in on site**](https://docs.podplay.app/overview/how-to-use-the-check-in-button#customer-checks-in) — the Customer taps the Check-in Button in the App to generate a QR Code, then presents it at the Club
* The scan happens in the Club, at the front desk, so presence is confirmed by the scan rather than by location data
* [**Staff Check-in from the Dashboard**](https://docs.podplay.app/overview/how-to-use-the-check-in-button#in-the-dashboard) — Club staff Check in a Customer they can see in front of them
### FAQs
Could you add geo-fencing to the App only, and leave the Web App alone?
No. A restriction that applies only in the App is not a restriction, because the Customer can complete the same Reservation in the Web App. The gap would also be invisible to Club staff, who would assume the rule was being enforced.
Can you use the Customer's IP address instead of their device location?
IP address is not a usable substitute. It locates the network, not the Customer, and it is wrong or missing often enough that it cannot support a booking restriction or a Check-in gate.
We only want to stop Customers Checking in remotely. Is that different?
The requirement is the same, and the answer is on-site QR Code Check-in. The Customer presents a QR Code that Club staff or a scanner at the Club reads. Presence is confirmed at the point of scan, with no location data involved.
For Autonomous locations, where the Customer [Unlocks Door and Checks-in](https://docs.podplay.app/owners-playbook/data-and-security/autonomous+-monitoring#app-controlled-door-access), the same requirements persist: the Customer can use the Web App without the requirement of geo-location identification.
Will this change if Apple or Google change their rules?
While this would be interesting, Apple and Google will likely never publish an App that requires location-based identification based on federal and local regulations. Access to a Customer's location is always optional.
The Web App limitation is independent of Apple and Google, so a change on the App side would not entirely solve it. The permission model would also have to change so that location access no longer needs the Customer's consent, which is not a direction either platform is moving.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.podplay.app/owners-playbook/data-and-security/geo-fencing-or-geo-location.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.