Privacy policy

The whole free app — the map, parking rules, reports, timers, saved spots and find-my-car — works with no account and no sign-in, and that stays the default for everyone. We don’t ask for your name, phone number or payment details, because none of that is needed to use Zippark.

An account is optional and only exists for zippark+, the paid tier. If you create one, all we ask for is an email address — see Accounts.

Your device’s location is used on your device to centre the map and find spots near you. It is never sent to Zippark’s own servers and we never store it. There is one exception, and it is the map itself: drawing a route preview or searching for a destination sends coordinates to Mapbox, which renders the map and works out the route — see Your location.

Without an account, the only thing you can send us is an anonymous parking report (“plenty” / “limited” / “full”) for a spot on the map — and it stays anonymous whether or not you have an account. With one, a few more things are stored against it: the spots you save, the car parks you ask to be alerted about, and the address your phone or browser receives notifications at — see Accounts and Notifications. You can delete the account, and all of that with it, from inside the app.

Zippark is free and carries advertising, but no advertiser is given your location, your reports, or anything else you do in the app — see Advertising.

When you tap “Find a park near me”, the app asks your browser or your phone for your current position. That position is used to:

• centre the map on where you are and show your position marker;
• sort nearby parking spots by distance from you;
• act as the starting point when the app draws a route preview to a spot — the only one of these that leaves your device, because Mapbox works the route out, not us;
• check once, when you come back to a spot you opened directions to, whether you are anywhere near it — a single reading, used both before asking you how parking went there and before sending an answer you gave from the follow-up notification. If it puts you somewhere else entirely, the question is dropped and the answer is discarded rather than sent.

That last one is the only time Zippark reads your location without you tapping something first, so it is worth being precise about. If you open driving directions to a spot, the app makes a note of it and asks how parking went when you next come back — or, if you have notifications on, in a notification about twenty minutes later. Before it asks, and before it sends an answer you gave from that notification, it takes a single reading and compares it with that spot’s coordinates, so that it doesn’t ask you about somewhere you never ended up — an answer about a place you didn’t visit is bad data on the map for everyone else. The comparison happens entirely on your device and all that comes out of it is yes or no; neither your position nor the distance leaves your device. It uses only a location permission you have already granted — it will never raise a permission request of its own here — and if it can’t get a reading, or the reading is too rough to mean anything, the app simply asks the question anyway.

Zippark’s own servers never receive your position. There is no background or passive location tracking: the app can only read your location while it is open and in front of you, it never does so on a schedule or while it is in the background, and it doesn’t keep a history of where you’ve been.

Mapbox is the exception to all of that, so it is worth being exact. Mapbox draws the map, and it does two things that need coordinates. When the app previews a route from you to a parking spot, your position is sent to Mapbox as that route’s starting point. When you type in the search box, the app sends Mapbox what you typed along with the centre of the map you are currently looking at, so that results near you rank first — if you have just centred the map on yourself, that centre is where you are. Each search also carries a random identifier generated for that one search and discarded afterwards; it exists so Mapbox bills a search rather than a keystroke, and it is not tied to you, your device or any other search. That is the whole of it: it goes to Mapbox rather than to us, under Mapbox’s privacy policy.

Tapping “Directions” hands off to Google Maps — or Apple Maps on an iPhone or iPad — in a separate app or tab for turn-by-turn navigation. From that point you are using that app, not Zippark. All Zippark does is open a link containing the spot’s coordinates; your own position is not part of the link.

You can refuse or revoke the location permission at any time in your browser or device settings. The map still works; it just won’t know where you are.

When you report a spot as having plenty of space, being limited, or being full, we store one row in our database. That row contains exactly:

• the spot’s identifier and its fixed coordinates — the car park’s location, taken from our map data, not your location;
• the status you chose (plenty, limited or full);
• a random anonymous ID generated in your browser and kept in your device’s local storage. It isn’t linked to any identity and it never leaves the app except on a report;
• a one-way SHA-256 hash of your IP address, combined with a secret salt. We do not store your raw IP address, and the hash cannot be reversed back into one;
• the time the report was made;
• the word user, recording that a person submitted it rather than it being loaded in from a data source, and a short identifier for the version of Zippark that was deployed at the time. Neither is about you — they are about our own software, and they exist so we can tell human reports apart from imported data and set aside reports written by a build we later find to be faulty.

The anonymous ID and the hashed IP exist for one reason: rate-limiting. They let us stop one person flipping the same spot back and forth or flooding the map, without knowing who that person is.

Reports are aggregated and shown publicly on the map as a colour, and count towards availability for 45 minutes before going stale. Nobody — including us — sees an individual person’s reporting history, because there is no identity to attach one to. That holds whether or not you are signed in: reports are never linked to a zippark+ account.

An account is optional. The whole free app works exactly the same with no account and no sign-in, and that is still how most people will use Zippark. The only reason to create one is zippark+, the paid tier, which needs somewhere to attach a subscription to.

Signing in works by email one-time code: you give us an email address, we send a code to it, and you type the code back in. There is no password to set or remember, and we don’t ask for your name, your phone number, or a social login.

Sign-in is handled by Supabase Auth — part of the same Supabase project that already runs Zippark’s database, listed under Who processes data for us. It stores the email address you sign in with and issues a session token that keeps you signed in. That token is kept in your browser’s local storage, on your device, the same as everything else described on this page.

Creating an account adds one row to our database holding your zippark+ status — whether it is active, when it expires, and, if you subscribed on the web, the Stripe customer and subscription references that let a payment be matched to you. Using the paid features then adds more, and here is all of it:

• Your email address, held by Supabase Auth. It is the only contact detail we have and the only thing that identifies you as a person.
• Your saved spots, if you subscribe. A saved spot is stored as your account id plus the spot’s identifier and the time you saved it — so it is a short list of places you are interested in, attached to an email address. Without a subscription, saved spots stay on your device and are never sent to us.
• Car parks you’ve asked to be alerted about, if you subscribe. One row per car park: your account id, the Transport for NSW facility id, its name, and the number of free spaces below which you want to hear about it — plus the address your notifications go to, described under Notifications. Deleting the alert deletes the row.
• A notification address per device, once you turn an alert on — again, see Notifications.

What is not attached: your timers, your parked-car location, your search history, and your parking reports, which stay anonymous whether or not you are signed in. None of those are ever sent with an account id on them.

You can sign out at any time. You can also delete your account from inside the app — open the account sheet and choose “Delete account”. That removes your email address, your subscription-status row, your synced saved spots, your car-park alerts and the notification addresses registered to you. It cannot be undone, and there is nothing to email us about first.

The app keeps a small amount of data in your browser’s local storage. It stays on your device, we can’t read it, and clearing your browser data removes it:

• the random anonymous ID described above;
• the spots you’ve saved and the ones you’ve recently viewed. Recently-viewed spots never leave your device. Saved spots do too, unless you subscribe to zippark+ and they sync across your devices — see Accounts;
• a note of the spot you last opened directions to, so the app can ask how parking was when you come back. It is a spot identifier and a timestamp — not a record of where you were — and it is discarded once you answer, once you dismiss the question, or once the app finds you nowhere near that spot;
• the parking timer you set — which spot, when it started, and how long you chose. In the iPhone and iPad app that stays on your device. In a browser, the times you want reminding at and the wording of each reminder are sent to us so the reminder can still arrive with the tab closed — see Notifications;
• where you parked, if you use “I parked here” or start a timer — a coordinate, the spot’s name and the time, so the app can show you the way back. It is stored on your device only, is never sent to Zippark and never attached to a report, and it is discarded when you clear it or after two days, whichever comes first;
• a flag recording that you've already seen the welcome screen;
• the date you first opened Zippark and the date you last opened it, a count of how many separate days you've used it, and a running total of how many reports you've submitted — used only to produce the anonymous measures described under Analytics. The report total is a bare number: it does not record which spots you reported, what you said about them, or when.
• if you have signed in for zippark+, the session token that keeps you signed in — issued and read by Supabase Auth, not written by Zippark’s own code; see Accounts;

Zippark is currently an invite-only preview. If you unlock it with an access code, that code is stored in a single cookie named zp_access so you don’t have to re-enter it. It is a strictly functional cookie — it holds only the access code, not anything about you. It is the only cookie Zippark itself sets; the advertising cookies described below are set by Google, not by us.

Zippark sends three kinds of notification, and they work differently enough that it is worth separating them.

The parking-timer reminder, in the app. If you start a timer in the iPhone or iPad app, the reminder is a local notification scheduled by your own device — it is not a push notification, no Zippark server is involved in sending it, and nothing about your device is sent anywhere.

The parking-timer reminder, in a browser. A web page cannot wake itself once the tab is closed, which is exactly when a timer matters, so this one is sent from our server instead. To make that possible, the app sends us your browser’s push subscription — the delivery address your browser’s push service (Google, Mozilla, Apple, depending on the browser) issues for this browser, and the two keys that let a message be encrypted so only your browser can read it — along with the times you want to be woken at and the wording of each reminder, which names the spot and the time left. Those are stored until the reminder is sent, and are deleted when you end the timer early. The rows are keyed to a random identifier for the timer, not to your account, so nobody can look up a person’s reminders.

Notification permission is only ever requested at the moment you start a timer, never when you open the app. If you decline it, the timer still runs as an in-app countdown, and nothing is sent.

The “how was parking?” question. If you tap “Open in Google Maps” or “Apple Maps” from a spot, the app can schedule one notification, 20 minutes later, asking how parking went there — with three buttons: Plenty, Limited, Full. It is not scheduled at all if a parking timer is already running for that spot.

This one is local, exactly like the in-app timer reminder above — it is scheduled by your own device, nothing is sent to a Zippark server to arrange it, and no device token or identifier is involved. It exists only in the iPhone and iPad app. The app never asks for notification permission for this feature on its own; it can only appear for someone who has already granted that permission by starting a timer at some point. If you have not granted it, you are never prompted for it here and you never see this notification.

Tapping Plenty, Limited or Full sends exactly the same anonymous report the in-app card sends: the spot’s identifier, the status you chose, the random anonymous ID described above, and the spot’s own fixed coordinates — never your position. Before it sends, the app runs the same on-device proximity check described above, under “Your location”; if that check finds you are demonstrably somewhere else, the answer is discarded rather than sent, and that reading never leaves your device either. The notification is cancelled and cleared from your notification centre as soon as you answer it or dismiss it.

The Park&Ride “it’s filling up” alert. This one is a zippark+ feature, it needs an account, and it is the only notification that is genuinely about something happening on our server rather than on your device. When you turn it on for a car park we store, against your account: which car park it is, its name, and the number of free spaces below which you want to hear about it — plus a note of whether we have already told you, so you are not warned twice for the same dip. A scheduled job on our side watches the Transport for NSW feed and sends the alert.

It has to reach your device, so it also stores an address to send to. In a browser that is the same push subscription described above — delivery address plus the two encryption keys — kept alongside the alert. In the iPhone and iPad app there is no such thing, so the app registers with Apple’s Push Notification service instead and sends us the device token Apple issues, which we store against your account so we know where to deliver. That token identifies an install of the app on a device, not a person; it changes when you reinstall, Apple can rotate it at any time, and it is deleted along with everything else if you delete your account. Permission is requested at the moment you turn an alert on, never before, and declining simply means the alert is not set up.

A reminder is only a timer you chose to set. It is not a statement about what the parking rules at that spot are, and it is not a substitute for reading the signs. If a duration is prefilled from the map, that number comes from OpenStreetMap and can be out of date — the signs at the spot are what actually govern how long you can park there.

We use Vercel Analytics to understand roughly how the app is being used. It records page views and a handful of anonymous, aggregate events — that a search happened, that a report was submitted, that directions were opened, that a spot was shared.

A few of these describe what the app managed to show you rather than what you did: that a spot was opened and whether we had any parking rules to show for it, that a spot was opened with no recent reports behind it, that a parking timer was ended and whether it had already run out, and that a timer was already running when a second one would otherwise have been offered. They tell us where the app is thin, which is how we decide what to fill in next. None of them carries which spot it was, where it was, or anything you typed.

One of them concerns the location check described above: it records whether the app decided you were near the spot, decided you were somewhere else, or couldn’t tell — and in that last case, which of the reasons it was (permission not granted, no fix, or a reading too rough to use). It is how we measure how often the app would otherwise have asked about a place nobody went. It carries no coordinates and no distance: three words, one of them the outcome.

Every one of these events now also carries three things about the session it came from: whether you are on the free plan or zippark+, whether you are using the app in a browser or the iPhone app, and a coarse band for how many separate days you have opened Zippark and how many reports you have submitted — “1–2”, “3–5”, “6+”, never the exact figure. It is how we tell whether a feature is being used by people on their first day or their fortieth. Bands rather than numbers on purpose: an exact visit count paired with an exact report count starts to be distinctive, and three bands are not.

There are also events for the zippark+ upgrade panel — that it was shown, which part of the app it was opened from, how long it was open before it was closed, and whether a purchase was started. They carry no payment details of any kind; Stripe and Apple handle those and we never see a card number.

One further event records, once per session, whether you have opened Zippark before and on how many separate days — nothing more than a couple of small numbers. It also carries how many spots you have saved and how many reports you have submitted, both rounded into broad bands (none, one or two, a few, several) rather than exact counts. It is how we tell whether the app is useful enough to come back to. The dates and totals behind it are kept on your device, never sent to us, and cleared whenever you clear site data.

One event is an exception to “no location”, and rather than bury it: turning a Park&Ride alert on or off records which car park it was — the Transport for NSW facility id, a public identifier for a public commuter car park. It is how we tell whether the feature is used at one or two big sites or across the network. It carries nothing else: not your account, not your email, not your position, and there is no identifier in the event that could join it to any other event. No other analytics event names a place.

Otherwise these events carry no personal information and no location. Vercel Analytics does not use cookies for tracking and does not build a cross-site profile of visitors. Analytics and advertising are kept separate: nothing measured here is passed to an ad network, and the only thing we record about an ad is that one was shown, tapped or dismissed in a given slot — never who saw it.

Zippark is free to use and is paid for by advertising. Ads appear in exactly two places: a card in the bottom corner of the map, and a row underneath the parking timer when you open a spot. Both are labelled Ad, and the card can be dismissed.

Ads are never placed on the map itself. No pin, no colour and no availability count is ever paid for. The map is the one thing the app asks you to trust, and an advertiser inside it would make every other pin worth less — so that surface is not for sale, and this is a design rule rather than a current pricing decision.

In a web browser the ads are served by Google AdSense; in the iOS app they are served by Google AdMob. Which one runs is decided by which container you are in, and they never both load. On the web, Google may set cookies to choose and measure ads, under Google’s policy for its partner sites and apps.

In the iPhone and iPad app, ads are not personalised, and Zippark cannot make them so. Every ad request the app makes is flagged non-personalised before it is sent, so Google is asked for an ad chosen without a profile of you. Zippark also never asks for permission to track you across other companies’ apps and websites: the app contains no such prompt, and the entry the App Store requires before an app may even show one is deliberately absent from the app, so iOS will not release your device’s advertising identifier to us or to Google here. There is nothing for you to decline, because the request is never made.

What we do not do is give advertisers anything from inside the app. Your location is never passed to an ad network — it never leaves your device at all, for any purpose. Neither are your parking reports, your saved spots, your search history, or your timers. Advertisers do not know which spot you were looking at when their ad appeared; the ad is chosen without any of that.

• Vercel — hosts the app and provides the analytics described above. Like any web host, its servers process standard request data (such as IP address) in order to serve pages.
• Supabase — the database that stores parking reports, and, via Supabase Auth, the provider that handles email one-time-code sign-in for zippark+ accounts. It stores the email address you sign in with and issues the session token described under Accounts. It also holds everything else listed under Accounts and Notifications. Access to the report table is locked to our server; it cannot be read or written directly by the public.
• Mapbox — renders the map, answers address and place search, and calculates the in-app route preview, from your browser or your phone. It is the one processor that receives your precise position, and only for the two purposes described under Your location.
• Stripe — takes the payment if you subscribe to zippark+ on the web, and holds the card details, which never reach us. We keep only the customer and subscription references Stripe gives us, so a renewal or a cancellation can be matched to your account.
• Apple — takes the payment if you subscribe inside the iPhone or iPad app, through the App Store. Apple’s Push Notification service also delivers the Park&Ride alerts described under Notifications.
• RevenueCat — checks an App Store subscription is real and tells our server when it starts, renews or lapses. It is given your account id so the subscription can be attached to the right account, and no payment details.
• Google AdSense / AdMob — selects and measures the two ad placements described above. It receives no location, no reports and nothing else from inside Zippark.
• Transport for NSW Open Data Hub — supplies live Park&Ride occupancy. We request it from our server, so no information about you is sent to TfNSW.

Parking locations come from OpenStreetMap — map data © OpenStreetMap contributors, used under the Open Database Licence. That data is fetched ahead of time and shipped with the app, so browsing the map sends nothing to OpenStreetMap.

Zippark is a driving aid intended for adults. It is not directed at children, and we do not knowingly collect information from them.

Parking reports are kept as a historical record of how busy places have been, but they stop affecting the map after 45 minutes. Because reports are anonymous, they can’t be traced back to a person.

Everything held on your device — the anonymous ID, saved spots, the access cookie — disappears when you clear your browser data or delete the app.

If you have a zippark+ account, everything listed under Accounts — your email address, your subscription status, your synced saved spots, your car-park alerts and the notification addresses registered to you — is kept for as long as the account exists. Deleting the account, from inside the app, removes all of it.

A web parking-timer reminder is kept only until it is sent, and is deleted when you end the timer early. Those rows are keyed to the timer rather than to an account, so deleting your account does not reach them — ending the timer, or simply letting the reminder fire, is what clears them.

Australian privacy law gives you rights to access and correct personal information an organisation holds about you. If you have never signed in, this is largely academic: we hold no contact detail and no stored location history for you, so there is nothing personal to look up, export or delete.

If you have a zippark+ account, the personal information we hold is the email address you signed in with plus the items listed under Accounts. You can delete all of it from inside the app — open the account sheet and choose “Delete account”. You do not need to ask us, and there is no waiting on a reply. If you would rather ask what we hold or have something corrected, email support@zippark.app.

You can clear everything the app has put on your device at any time through your browser or device settings. If you believe we hold something about you beyond what’s described here, get in touch and we’ll look into it.

If the app starts handling data differently, this page is updated before that change ships, and the date at the top changes with it.