Privacy policy

This Privacy Policy explains how Polyfence ("we", "us", or "our") collects, uses, and protects your data when you use the Polyfence platform at polyfence.io, our REST API, and related services (collectively, the "Service").

If you use our open-source SDKs, each carries its own privacy policy for the package you actually install: Flutter, React Native, and the native Kotlin/Swift engine. Anonymous telemetry belongs to the two bridges. The native engine makes no network calls at all. You do not need a Polyfence account to use any of them.

Polyfence collects zero PII about your end users. We never ask who they are. The personal information in our system is about you, not them: your account details and billing, same as any paid SaaS, identical to what Stripe or Vercel hold about you. The sections below describe what else we hold, including the address of anyone you invite to a workspace and what our logs keep about a request. One other thing is held about you, and only about your use of this website: a code that lasts a day and groups this browser's visits to it. It carries no account identifier, and we do not join it to your account. Nor, as explained below, do we line its timings up against one.

Our core principle: We collect only what's necessary to run the Service. We don't sell your data, we don't serve ads, and positions are evaluated and discarded by default. Server-side position retention is an explicit, workspace-level opt-in. Manage your retention setting.

Information we collect

Account information

When you create an account via GitHub OAuth, Google OAuth, or magic link email, we receive and store:

• Email address
• Your name, username and profile picture link, where your sign-in provider sends them
• Authentication provider identifier (e.g., GitHub user ID)
• Any display, first or last name you type into your account

If you invite someone to a workspace, we store the email address you typed, so the invitation can be issued and matched when someone accepts it. The invitation expires after a week; the address stays on the record of it until the workspace is deleted.

We only request the minimum OAuth scopes needed for authentication. We do not access your repositories, contacts, or other provider data.

Zone data

When you create geofence zones through the dashboard or API, we store:

• Zone geometry (circle center/radius or polygon coordinates)
• The zones you create, including a region and country we work out from their coordinates rather than ask you for
• Creation and modification timestamps

Zone data belongs to you. We never share it with anyone outside your account, and never use it for any purpose beyond providing the Service. Anyone you invite into a workspace sees the zones in it: that is what the invitation is for.

API keys

API keys are stored as SHA-256 hashes, not in plaintext. We cannot retrieve your key after creation. Only you see the full key, at the time it's generated. Keys are revocable at any time through the dashboard.

Data connector credentials

If you configure data connectors (ETL imports), the API keys and credentials you provide for external services are encrypted at rest using AES-256-GCM encryption. These credentials are only decrypted at sync time and are never logged or exposed in API responses.

Usage & log data

We collect operational data to monitor the health and security of the Service:

• API request logs (endpoint, method, status code, timestamp, which of your API keys was used, a shortened IP address, the operating system, timing, and a short piece of any error reply; no request bodies. See Data retention)
• Rate limiting counters (request counts per time window, held in server memory for minutes and never stored)
• Feature usage (tier limit checks, feature access patterns)
• Error reports (stack traces and request context, sent to Sentry)

Cookies & local storage

We use essential cookies only (no marketing or tracking cookies, and no cookie is used to count visits):

• Authentication session: managed by Supabase Auth, required to keep you logged in
• Early Access notice: remembers that you dismissed it, so it stays hidden
• Visit counting turned off: set only if you switch off visit counting, and holds nothing but that choice. Counting itself sets no cookie at all.

We also keep a few interface preferences in your browser’s local storage. These stay on your device and are never sent to our servers:

• Theme: light or dark mode
• Whether your account is an administrator: kept for the tab you have open and cleared when you close it, so the dashboard need not ask on every page
• UI state: such as your map view, dismissed notices, onboarding progress, and the last Wi-Fi network used during device setup

Counting visits to this site

We use Umami, an open-source analytics tool we run ourselves, to see how polyfence.io is used so we can improve it. It sets no cookies, and never receives your name, email or account. No Google, no third-party analytics, no ad network.

The analytics database is our own, in Stockholm, and the analytics app is not publicly reachable: it sits behind a login. The pages themselves are served from wherever you are, like any site on a CDN, and our host sees those requests the way any host does.

This section is about you browsing polyfence.io. Nothing about your end users changes: we still collect zero PII about them and still never ask who they are. It is also not the anonymous SDK telemetry described under Open-source SDK telemetry, which comes from apps you build rather than from this website.

You can check all of this. The script is served from this site rather than an analytics domain, and every count is a POST to /api/visits. Open your browser's network tab and read exactly what leaves the page. If your browser sends Do Not Track or Global Privacy Control, or you switch counting off below, the script is not loaded at all, so nothing is read and nothing leaves. Switch it off on a page that is already open, and that page sends nothing more.

What a visit records

• The page you opened, as its pattern: /w/[workspace]/devices/[id], never the workspace's name or the device's ID. A page we don't recognise is recorded as /[not-found].
• Where you arrived from: another site by its address alone, never the full link. A page on polyfence.io is recorded as its pattern, the same way the page you opened is.
• Campaign tags on the link you arrived by. Everything else after a ? is dropped, and anything after a # is never sent.
• Your country, as our host reports it. Region and city are never collected: the country goes with the visit, so nothing ever looks one up from your address, and neither field is ever filled in.
• Your browser, operating system and device type: for example Chrome on macOS, on a desktop.
• Your browser's language, and the time.
• Five moments in signing up, if you reach them: the Get Early Access button pressed; a sign-in started, with which of three ways you chose (GitHub, Google or an emailed link); a sign-in link sent; a sign-in completed; and a sign-in that failed, with which of four things went wrong.
• Six moments in using it, once you are in: which of four things you picked on the welcome screen; each step of the device wizard you reach, and which of four things you were doing (setting one up, re-flashing, resetting or removing it), so we can see where it loses people; a device added; a zone created; a set of zones imported; and an API key created.
• Nothing else travels with any of them: no name, no email address, no account, no zone, device or key name, nothing you typed. Not which board you set up, either. A zone or a device is counted, never which one.
• One thing they do carry is the time. A moment like "a zone created" is stamped to a fraction of a second, and the zone itself is a row in our product database with its own timestamp and an owner. We hold both, so we could line one up against the other. At that precision the match is exact on any day, not only a quiet one. It would not stop at the one moment: until re-keying, every row from the same visit shares a code, so a single match would carry the rest of that day's browsing with it. Nothing in a counted row says whose it is; the connection would come from putting the two databases side by side. We do not do that. Re-keying does not change it either: after two months the shared codes are replaced, which breaks the chain to the rest of the day, but the moment keeps its name, its page and its hour, and the match by time and by which moment it was still stands. The rounding widens the window it sits in rather than closing it. We say all of this because "cannot" would be untrue, and this page is only worth anything if you can check it.

Signed-in pages are counted the same way as public ones, by page pattern. The reports say which pages were opened, and hold nothing that names who opened them. Admin pages are never counted at all. An admin address is never one we report: the script isn't loaded on a fresh admin page, and a move to one from elsewhere in the dashboard is dropped in your browser before any request leaves.

What is not recorded

• Not your IP address, and not the browser string itself. Both are used to work out a one-way code, and there is no column for either. The address is also the key for three counters that limit how often one address may send a count, fetch the script, or flip the switch; they live in server memory, are gone within minutes of the last request and are never written down. Apart from that, neither goes any further. What we keep from that string is the browser, operating system and device type it names.
• Not your screen size.
• Nothing you are signed in as. The request carries this site's cookies, because that is how our server sees whether you switched counting off. None of them go any further, and the reports have no column for who you are.
• Nothing from the page itself: not its title, not its text, not anything you typed. What gets sent is built from a fixed list of fields and everything else is dropped: once in your browser before the request leaves, and again on our server when it arrives.

How a visit is grouped

By a one-way code worked out from your address, your browser string, the date and a secret we hold. Within one day the code is what lets the pages you open count as one person rather than several strangers. The date is part of it, so the code changes at midnight UTC and one day's rows share no code with the next, and nothing in a row says who you are. We never reverse it. Because we hold the secret, we could work out the code for a given address and browser on a given day. The analytics database keeps neither, and we do not do it.

How long it is kept

After two months, every row is given a code of its own, its time is rounded to the hour, and its language is removed, so no two rows share a code. On a quiet day, rows from the same hour with the same browser and country may still plainly belong together. They hold nothing that says whose they are. After 25 months they are deleted. Both run on a nightly schedule.

Deleting your account

Deleting your account does not change what has already been counted. Those rows were never linked to your account, and nothing in them says whose they are. But, as the timing above explains, a named moment could still be lined up against the row it refers to, and deleting your account does not reach back into moments already recorded. What it does remove is the other half of that match: the zone, device or key a moment refers to goes with your account, so the row it could have been matched against is gone. The moments themselves age out on the schedule above.

Turning it off

If your browser sends Do Not Track or Global Privacy Control, we don't count you whatever the switch says. You don't have to tell us, and no visit of yours is recorded either way. The switch and those two signals also stop the page-load timings we send to Sentry, listed below.

Switching it off sets one cookie in this browser, holding nothing but that choice (see Cookies & local storage). Switching it back on deletes it, so this browser is indistinguishable from one that never touched the switch: the choice is never stored on our side. Clearing your cookies clears it, and it doesn't follow you to another browser or another device. It lasts 400 days at most, and nothing renews it; after that the switch no longer holds and reads on again. The same switch is under Account → Privacy & data if you have an account.

How we use your data

We use your data exclusively to provide, secure, and improve the Service:

• Provide the Service: authenticate you, store and serve your zones, process API requests
• Billing: manage your subscription tier and process payments
• Security: rate limiting, CSRF protection, abuse detection, error monitoring
• Support: respond to your inquiries and debug issues
• Improve the Service: analyze aggregate usage patterns, and see which pages get used and where a flow loses people, so we know what to fix. Nothing in those reports says who you are (see Counting visits to this site)

We do not sell your data, use it for advertising, profile you, or share it with data brokers. Ever.

Third-party services

The Service relies on the following third-party providers. Each receives only the minimum data needed for their function:

An error report is the route, the status and the stack: what finds the fault. It does not carry your name, your email address, or the body of your request. Nothing in our code tells Sentry who you are, and the fields that would are deleted before a report leaves your browser, so that stays true of whoever adds the first one.

Some failures attach one more thing, so the failure can be traced to the work it belonged to: the workspace a lost usage record came from, the customer and subscription ids our payment provider uses when a billing message cannot be processed, the zone being edited when the map editor refuses an action, and, when an email request arrives of a kind we do not handle, the domain of the address it named, never the address itself. These say whose work failed, which is what makes a failure worth investigating; none of them says who you are.

The address of the page travels with it. The workspace name is taken out of that address; the rest of it is not, so where a route names a thing (a device, a zone, an account on an admin page), that identifier goes too, because it is what places the fault.

Two things travel that we do not choose. Your browser sends its own name, its operating system, its timezone and its language. And Sentry records the city your connection came from. It works that out at its end, from the connection itself, after ours has removed the address from what it sends. We have asked it not to keep addresses, and the city is recorded anyway. We cannot see inside that to tell you more than what arrives. So a report says that someone in a city, on a browser, opened a route and it failed, and names whatever that route named. It does not say your name or your email address, and we never tell Sentry which account is yours.

We do not use Google Analytics, Mixpanel, Amplitude, or any third-party analytics or advertising tools. No analytics service outside Polyfence and no ad network receives anything about you. We count page visits ourselves (see Counting visits to this site).

Where your data goes

Some of the services above are based outside the UK. Where they are, the transfer is covered by appropriate safeguards: the UK Addendum to the European Commission's standard contractual clauses, or the UK Extension to the EU-US Data Privacy Framework where the provider is certified under it.

Data security

• Encryption in transit: all connections use TLS/HTTPS, enforced via HSTS headers
• Encryption at rest: database encrypted at rest; connector credentials use AES-256-GCM
• API key hashing: SHA-256 hashed with timing-safe comparison to prevent enumeration
• Rate limiting: applied per API key, per account for requests from the dashboard, or per device for LoRaWAN messages, on the busiest and most sensitive routes (location evaluation, device reports, creating zones, keys and connectors, and address search), at a ceiling set by your plan or, on a few, a fixed one
• Tenant isolation: a query for your zones, devices or connectors is scoped to your account, or to the workspace the record lives in

Our own staff can reach account data through internal admin tools. That is how support, billing and abuse investigations work. When a member of staff opens your account, or acts on your records from another account, we record that it happened. Admin pages that list many accounts at once, such as the feedback inbox or the request logs, are not recorded against each account they show. The record is part of the data export you can ask for: it tells you when someone looked, though not which member of staff it was.

If data we hold is exposed by a security failure, we will investigate, and we will tell you where the law requires it or where knowing would let you act.

Data retention

We keep each kind of data for as long as the job it does requires. Where that is a fixed period, it is named below. Otherwise it is kept while your account is open and deleted when you delete it, except where this list says something is kept. Your payment record sits with our payment provider under its own rules, and if you worked in a workspace someone else owns, the zones and connectors you made there stay with that workspace.

• Account & zone data: retained while your account is active
• API logs: retained for 90 days for operational monitoring and security purposes, then deleted; anonymised as the row is written, never afterwards. The end of the IP address is replaced before it is stored, so what is kept points at a network and not at your line: the first three of an IPv4 address's four blocks, or the first three of an IPv6 address's eight groups. What is kept of the caller's user-agent is the operating system and its version (or, where the call comes from one of our own SDKs, the SDK's name and version), and never the full string. The row also holds the method and the path, the status and how long it took, and the last four characters of the key that made the call. Two things in it can carry your own content. Where a request fails, we keep a short piece of the reply we sent, so the fault can be traced, and that reply sometimes quotes what you sent: ask for a zone whose name is already taken and the name comes back in the error. And on some paths the recorded address holds the id of the thing you were working on rather than a placeholder
• Sign-in records: signing in creates a session and an audit entry held by Supabase, which runs our authentication. Those keep your IP address in full and your browser's full user-agent string (the line every browser sends with each request, naming itself, its version and your operating system). Supabase's session and audit entry are not ours to write or to trim, and deleting your account removes them along with the authentication record itself; that step runs after the rest and can fail on its own, and when it does our erasure log records that it did, so the gap is visible rather than silent. In the tables we write ourselves we never keep your address whole: the request log cuts it short. Our host's request log keeps your full address and your full user-agent string for a day, and the user-agent string is also kept in full on a feedback message, described below.
• Operational logs: our servers' own log lines, held by our host rather than in our database. One is written when we send you an email (which kind, your account id, your address masked, and its domain in full); when a device key is created or revoked (your account id, the device id, and the last four characters of the key); when your plan changes, a billing message is processed, stored positions are purged, or a usage record cannot be saved (your account id); and when a LoRaWAN device is registered or one of its uplinks is backfilled, unexpected or refused for arriving too fast (the device's DevEUI, and on registration your account id and the device id). Because our address-search routes take what you typed (or a pair of coordinates) in the address of the request, those appear in the host's request log as well. One line carries more than the rest: when a billing message cannot be matched to an account, the email address it named is written in full, with the reference data the payment provider attached to it, because otherwise the payment cannot be traced to anyone. These exist to run the service, they are not used for analytics, and they are not part of the data export.
• Aggregate SDK telemetry: non-identifying signals (battery, GPS quality, never raw location). Retained for 24 months, then deleted. On account deletion it is anonymized (your account link is removed) and kept in aggregate for the remainder of that period.
• Error reports (Sentry): retained for 30 days, then deleted
• Limits: the per-second counters live in server memory and are gone within minutes. When a request is refused for going over a limit (a rate limit, a plan quota, or a feature your plan does not include), we record your account and workspace, which limit it was, the count and the ceiling at the time, the endpoint, and the time. No request content. That record stays while your account is open and is deleted with it.
• Zone events: for devices that report to our servers (the evaluate API, LoRaWAN uplinks and event backfill; never the mobile SDKs), the transitions we record: entry, exit and dwell, each with the device ID, the zone and its name, and the time. Never coordinates. No fixed period: this is the history your dashboard shows. It stays while your account is open and is deleted with it, and it outlives both the device and the zone it refers to, so removing either does not remove its history.
• Usage records: one record for each authenticated request: the route, the method, the time, and which API key or sign-in made it. Never the request body. This is what monthly API-call limits are counted from. Alongside it, a daily count of the zones, devices, keys and connectors you have, which we use to decide where plan limits should sit. No fixed period: both stay while your account is open and are deleted with it.
• Feedback you send us: your message and its category, the address of the page you sent it from (which can include your workspace's address and a device ID), and your browser's full user-agent string. No fixed period, and it is not deleted with your account: deleting your account removes the link to you, but the message and the page address stay as sent. Email us if you want one removed.
• Counted visits: 25 months, then deleted; re-keyed and rounded to the hour after two months, so no two rows share a code (see Counting visits to this site)
• Revoked API keys: soft-deleted (hash retained for abuse prevention), never reactivated
• Administrative records: who at Polyfence viewed or changed your account, and when. Retained for 24 months, then deleted. These records survive account deletion; afterwards they hold only an account identifier that no longer resolves to anyone.

Deleting your account removes your zones, API keys, profile, connector configurations and app registrations. That is permanent, and there is no recovery. Request logs go with them wherever the log records which of your API keys made the request.

A few things stay. It is worth knowing which before you press the button.

Deleting also tells our payment provider. Any subscription is cancelled, and we ask them to anonymise the customer record they hold: the email address becomes a hash and the billing address is cleared. Two things outlast that, and we would rather say so than let you assume otherwise. Invoices and orders are fixed once issued, so whatever they already carried, a billing address among it, stays as it was issued. And where a tax number applies, the business name on the record is kept rather than hashed. If we cannot reach them at that moment we record that we could not, and you can ask us to try again.

The anonymised telemetry and the administrative records are both listed in the data export you can request before deleting; the payment record sits with the provider and is not ours to export. Counted visits also remain, for the periods above. They were never linked to your account and hold no account identifier, so there is nothing in them that points at you to delete. What does go is the other half of the match described above: the zone, device or key a named moment refers to is deleted with your account, so the row it could have been lined up against is gone. The moment itself stays, and after two months the rounding to the hour widens the window it sits in rather than closing it: on a quiet hour a single moment is still a single moment. If we terminate your account for cause, such as a breach of the Terms, we may retain data as required by law or for legitimate security purposes before deletion.

Your rights

Regardless of where you're located, we provide the following rights to all users:

Access & export

You can export your zone data at any time: select the zones on the Zones page and use the Export button (GeoJSON or CSV format). For a full data export covering your entire account, email hello@polyfence.io and we run it for you. There is no button for it yet. It works from a list of the tables we hold about you: your account and workspace records, your zones, devices and keys, the zone events your devices recorded, your LoRaWAN and app registrations, any feedback you sent us, your connectors and their sync history, your request logs and usage records, the record of requests refused for going over a limit, the daily counts of what you have, the aggregate telemetry and the administrative records. Two things are not in it: the authentication record described above, and an invitation someone else sent to your address, which is filed against that address rather than against you. Ask and we will send those two as well. Some columns are held back on purpose. Credentials stay out: the encrypted key your LoRaWAN devices join the network with, and the keys and headers your connectors use, because a live credential does not belong in a file sent by email. Request log entries show when, which endpoint and whether it succeeded, without the shortened address, the operating system or the error reply described under Data retention. The record of staff access says when someone looked, not who.

Correction

You can update your zone data and account details directly through the dashboard at any time.

Deletion

Go to Account → Profile → Delete account to permanently remove your account and data (aggregate telemetry is anonymized, not deleted, as described under Data retention). This is immediate and irreversible. Our database provider also keeps a daily backup for seven days, so your data stays in those backups until they roll over, and is gone after that. Two things have to be cleared first: a workspace you own cannot still have other members in it, and you cannot have devices registered in someone else's workspace. We will tell you which applies. You can also request deletion by emailing hello@polyfence.io.

If you only want to purge stored device positions (without closing your account), visit Account → Privacy & data and use the "Delete stored positions" action. This clears the last-known coordinates for every device in the workspace you are in (another workspace you own is cleared separately), and is independent of the retention toggle. It is the workspace owner's action.

Portability

Zone data can be exported in machine-readable GeoJSON or CSV format. For other data, contact us and we'll provide it within 30 days.

Objection & restriction

If you object to how we process your data, contact hello@polyfence.io. We'll respond within 30 days.

If you are unhappy with how we have handled it, you can also complain to your data protection authority. In the UK that is the ICO, and in the EU it is your national authority.

Legal basis for processing (GDPR)

If you're in the European Economic Area or UK, we process your data under the following legal bases:

• Contract performance (Article 6(1)(b)): account data, zone storage, API access, and billing are necessary to provide the Service you signed up for
• Legitimate interest (Article 6(1)(f)): security monitoring, rate limiting, error tracking, aggregate usage analysis, and counting visits to this site, so we can maintain and improve the Service

Counting a visit stores nothing on your device, apart from the one cookie that remembers you switched it off, which is set only because you asked for it. The script does read a few things from your browser, such as its language and the page you came from. UK law allows that without asking first when it is used only for statistics to improve the site, you are told about it here, and you can switch it off. That is why this site has no cookie banner. You can stop it at any time with the switch under Counting visits to this site, and we honour Do Not Track and Global Privacy Control without being asked.

Classification of data fields under GDPR can vary by context and jurisdiction; consult qualified counsel if your use of the Service requires a formal data protection assessment.

California residents (CCPA)

If you're a California resident, you have the right to know what personal information we collect, request its deletion, and opt out of its sale. We do not sell personal information and have never done so. Whether specific data fields qualify as personal information under CCPA can depend on context; consult counsel if your use case requires a formal determination.

To exercise your CCPA rights, email hello@polyfence.io or use the account deletion feature in the dashboard.

End-user location data

Mobile SDKs (on-device)

The Polyfence mobile SDKs (Flutter, React Native, native Kotlin/Swift) perform all geofencing on-device. GPS coordinates and geofence events are processed locally on your users' devices and are never transmitted to Polyfence servers. Where the SDK's telemetry is left on, counts of what happened travel (how many crossings, how long dwells lasted), never the events themselves.

Server-side evaluate API (IoT & embedded)

If your devices or your server send coordinates to Polyfence, through the evaluate endpoint (POST /api/v1/evaluate) or as LoRaWAN messages passed on by your network server, we check them against your zones. What happens to those coordinates depends on a single workspace-level setting:

What we collect by default

• Zone events: ENTER / EXIT / DWELL transitions. References to zones; never coordinates.
• Account & billing: your email, the identifiers our payment provider uses for you, and the record of staff access. We hold no card details.
• Anonymous mobile-SDK telemetry: aggregate accuracy averages, event frequencies, etc. NEVER coordinates, NEVER end-user identifiers. Each session carries the package name of the app the SDK is in, which we require, and if you configure an API key the session is linked to your account. Collected by default; one line of code disables it.

What we collect ONLY when you opt in

• Raw latitude / longitude positions: the retention feature for fleet, agriculture, asset, anywhere you need hosted history. Off by default; turn it on at Account → Privacy & data. The setting is reflected in API responses via GET /v1/account/retention and on every GET /v1/devices/{deviceId} row. Even with retention on, we keep only the most recent point, never a track or route.

What we never collect

• Device identifiers beyond what you give us
• Route or track history from coordinates: we never build one; the retention opt-in stores only the single latest point. Zone events, described under Data retention, do record which zones a device entered and left.
• Anything from the polyfence-embedded C library: it doesn't phone home, by design

You are the data controller for any location data your application sends to the evaluate API. You are responsible for obtaining appropriate consent or legal basis from your end users before transmitting their coordinates to Polyfence. We process this data solely on your behalf to provide the geofencing Service.

Embedded library (on-device)

The Polyfence embedded C library runs entirely on your hardware (Raspberry Pi, ESP32, etc.). All geofencing is performed locally, and the library itself sends nothing. The firmware we publish for our reference boards does send positions to Polyfence, through the two routes above, under the same setting.

Regardless of which integration path you use, you are responsible for your own privacy policy and compliance with applicable location data regulations.

Device provisioning & setup

When you set up a physical device through the in-browser flash wizard, we store the configuration needed to identify and authenticate that device. Apart from the name you choose for it, none of it is PII about your end users, and none of it asks who they are: a device_id is a pseudonymous identifier the device generates, not anything tied to a person.

What we store when you provision a device

• Device identity: the device_id the device announces during setup and a device-bound API key. We store only the SHA-256 hash of the key, never the raw key.
• Device metadata: board type, backhaul (LoRaWAN / Wi-Fi / cellular), and firmware version, so the dashboard can show board-specific UI.
• The name you give it: free text, stored whenever you set one and shown to everyone in the workspace, so if you would rather we did not hold a person's name, do not put one there.
• LoRaWAN join credentials (LoRaWAN devices only): when you provision a LoRaWAN device we generate and store OTAA credentials (AppEUI, DevEUI, AppKey) scoped to your account, so you can register it with your LoRaWAN network server. The AppKey is stored encrypted at rest, and re-provisioning rotates all three values. These identify the device, never your end users.

Provisioning data is device configuration, not location data. It is kept for the life of the device registration. Deleting the device removes the registration, its LoRaWAN credentials, its per-zone state and its zone assignments. Two things stay: the device-bound key is marked revoked rather than deleted, so its hash and the device_id remain on the record and the key itself stops working; and the device's zone events stay, as described under Data retention. Deleting your account removes both. It is not affected by the position-retention setting described above. That setting governs coordinates only.

Wi-Fi setup

• Credentials go to the device, not to us. The network name (SSID) and password you enter during setup are sent straight to the device over a local USB connection in your browser. The Wi-Fi password is never transmitted to or stored by Polyfence.
• Network scans are transient. If you scan for nearby Wi-Fi networks during setup, the results (network names and signal strength) are shown only in your browser and are never stored or sent to our servers.
• Convenience only. The last network name you used is kept in your browser’s local storage (see Cookies & local storage above) so you don’t have to retype it. It stays on your device.

Open-source SDK telemetry

Our open-source SDKs (Flutter, React Native, native Kotlin/Swift) collect anonymous performance telemetry (enabled by default, opt-out with one line of code). This telemetry contains no location data, no PII, and no end-user identifiers. It does carry the package name of the app the SDK is in, and a link to your account if you configure an API key.

Categories of data collected:

• Integration context: The package name of the app the SDK is in, the platform, the SDK version and the bridge it runs through, the core engine version, and, if you set them, the industry and use case you describe your app as.
• Session metadata: Duration, zone count, accuracy profile, update strategy, session quality score, the date, and the hour the session started.
• Activity patterns: Activity distribution (still/walking/driving), stationary ratio, average speed when an event fired
• GPS performance: Average poll interval, interval distribution, accuracy, detection latency, time to first detection
• Zone interactions: how many zone transitions and boundary events happened, how long dwells lasted, the false event count, the spread of zone sizes, how many of your zones are circles and how many polygons, and average distance to a boundary
• Battery impact: Battery level at start/end, charging status during session, drain per hour, and whether battery optimisation is switched off for the app
• Reliability: how often the service was interrupted, the share of GPS readings that were usable, whether and how many times a zone was detected, how many events were sampled, and how often battery optimisation was checked
• Device context: Device category (not specific model), OS major version
• Counts of errors the SDK ran into, by kind, never their messages.

Two of those are worth saying plainly. The package name is the app the SDK is embedded in: it identifies your app, not anyone using it, and the endpoint requires it. And the hour the session started is the hour on the device, while we record when it reached us in UTC: the difference is the device's offset from UTC, which is a wide band of longitude. Not a location, but more than a clock.

The embedded C library does not include telemetry.

For the full field list, see the Telemetry Reference on GitHub. Opt-out instructions and how long telemetry is kept are in the Flutter and React Native privacy policies linked at the top of this page.

Children's privacy

The Service is designed for developers and businesses. We do not knowingly collect data from children under 13 (or the applicable age of consent in your jurisdiction). If you believe a minor has created an account, contact us and we'll delete it promptly.

Changes to this policy

We may update this policy to reflect changes in our practices or legal requirements. Every change moves the "Last updated" date at the top of this page, including small ones, so if that date hasn't moved, nothing here has changed.

We don't send policy updates by email. When a change affects what we collect or how we handle it, we describe it in plain terms on this page rather than leaving you to compare two versions. Where the law requires stronger notice or consent for material changes, we will comply. Continued use of the Service after changes constitutes acceptance of the updated policy.

Questions? hello@polyfence.io