Privacy Policy

1. Data we don't collect

We only store the personal data described in this policy — nothing beyond what's needed to run the Service. We don't buy, sell, or trade personal data, and we don't run advertising of any kind. In particular:

• WME Requests itself doesn't record your IP address or location. Signing in happens on your WMEKit account, which keeps a security log of sign-ins (including IP address) as described in the WMEKit Privacy Policy.
• Submitting a request through the browser userscript doesn't require an account, and we don't collect your email address, real name, or Waze account credentials through that flow.
• We never see or store your Waze account password.

2. Data we do collect

Dashboard accounts (editors, moderators, admins)

• You sign in with your WMEKit account (auth.wmekit.com). Your sign-in details stay there (see the WMEKit Privacy Policy). WME Requests receives your account ID, name, email address and profile picture from it, and keeps a copy of your ID, name and email.
• Which countries you've been given access to, and your RSS feed token.
• A session cookie, shared across *.wmekit.com, that keeps you signed in.
• If you enable browser push notifications, an opaque push subscription endpoint and encryption keys issued by your browser — these identify a browser installation, not you personally.

Requests submitted via the userscript

When a Waze editor submits a downlock/uplock/imagery/PUR request from inside the Waze Map Editor, the Service stores:

• Your Waze editor username (as entered/detected in WME) and editor rank.
• The WME permalink to the relevant map location, and any notes you add.
• An optional screenshot of the map viewport, if you choose to attach one.
• The request type, lock level, and timestamps.

A Waze username is a public in-game identifier you chose yourself, not your legal name — but we recognize it can still identify you, and we treat it accordingly under this policy.

Integration credentials (admin-configured)

Global admins and users who configure notification channels may store webhook URLs, bot tokens, Google service-account keys, or SMTP/Postmark/Mailgun credentials so the Service can deliver notifications on their behalf. These are encrypted at rest (see § 5) and are never displayed again after saving.

3. Notifications and external providers

A country's admins choose which of the following channels, if any, receive a copy of a submitted request (permalink, notes, lock level, submitter username, and screenshot if attached). We only send data to a channel that's been deliberately configured — nothing is sent to a third party by default.

• Slack — via an Incoming Webhook or bot token, posted to a channel of the admin's choosing.
• Discord — via a server webhook (message or forum-thread post).
• Telegram — via the Telegram Bot API, to a chat/channel the admin controls.
• Google Chat — via a Google Chat incoming webhook.
• Google Sheets — via the Google Sheets API, appending a row to a spreadsheet the admin's Google service account has been given access to.
• Email — via Postmark, Mailgun, or an SMTP server the admin has configured with their own credentials.
• ntfy and Gotify — self-hosted or third-party push-notification servers, posted to an endpoint the admin controls.
• Custom webhook — a plain JSON payload posted to any URL the admin supplies.
• Web Push — native browser notifications for signed-in users who opt in via "Notify me". Delivery is relayed through your browser vendor's push service (e.g. Google, Mozilla, or Apple), which only sees an encrypted payload and the delivery endpoint, not its contents.
• Public RSS feed — a read-only feed of recent requests that anyone can pull into their own RSS reader. This isn't a push to a third party; it's the same public request data already shown on the dashboard, made available for you to fetch on your own terms.

None of these providers receive dashboard account data (your login email/password) — only the request content described above, and only for the countries/regions their channel is scoped to.

4. Analytics — PostHog

We use PostHog (hosted in the EU) for product analytics — understanding which features are used and catching errors. There are two categories:

• Browser analytics (consent-gated) — page views, button/feature usage, sign-in events, and client-side error capture in your browser. This is off by default and only starts after you accept it in the cookie banner (see § 6); you can withdraw consent at any time from that banner. For signed-in dashboard users who accept, your user ID, name, and email are attached to your analytics profile so we can distinguish one editor's usage from another's.
• Server-side operational events (not cookie-gated) — when the API itself performs an action (e.g. a request is created, a notification channel is tested, an invite is sent), our server logs that event to PostHog for operational monitoring, similar to a server access log. These use your account ID if you're signed in, or a random per-submission identifier for anonymous userscript submissions — never anything else that identifies you — and aren't affected by the cookie banner choice, since they're a direct, necessary record of the action the API just performed rather than behavioral tracking of you browsing the site.

Declining browser analytics doesn't affect your ability to use the Service.

5. Cloudflare and infrastructure

The Service runs entirely on Cloudflare's platform:

• Cloudflare Workers — hosts the dashboard and API, and sits in front of every request to the Service.
• Cloudflare D1 — the database storing accounts, requests, notification-channel configuration, and encrypted credentials.
• Cloudflare R2 — stores screenshots attached to requests.

As our infrastructure provider, Cloudflare processes this data on our behalf under its own privacy and security commitments; it is not used by Cloudflare for its own purposes.

6. Cookies

• Strictly necessary — a session cookie that keeps you signed in to the dashboard. These can't be disabled and aren't covered by the cookie banner, since the Service can't function without them.
• Analytics (optional) — PostHog cookies/local storage, set only after you accept analytics in the cookie banner. See § 4.

You can change your analytics choice at any time — clear your browser's local storage for this site to see the cookie banner again.

7. Security

• All traffic is served over HTTPS via Cloudflare.
• Sign-in is handled by the WMEKit account service; WME Requests never sees your password.
• Third-party integration credentials (bot tokens, service-account keys, SMTP/email credentials) are encrypted at rest with a dedicated encryption key held only as a server-side secret, and are never re-displayed after saving.
• Access to admin functions (Admin, Reports) requires an authenticated session and is scoped by role and by country/region.

No system is perfectly secure, but we design the Service to minimize what personal data it holds in the first place, so there's less to protect and less at risk if something goes wrong.

8. Data retention

Request records (including notes, screenshots, and permalinks) are automatically and permanently deleted 24 hours after submission, or sooner if an admin removes them manually. Before a request is deleted, an aggregate count of it (submitting editor, country, and request type — no permalink, notes, or screenshot) is added to a running per-user tally, which we keep indefinitely to power the Reports feature. Account and configuration data (users, countries, channels) is kept for as long as they're operationally useful, and deleted when an admin removes them. Analytics events in PostHog follow PostHog's own retention settings for our account.

9. Your rights

Your rights over your data in WME Requests are the same as for your WMEKit account: under POPIA, the GDPR or other law that applies to you, you can access, correct, export or delete your personal data, or object to or restrict certain processing. The WMEKit Privacy Policy explains these rights and how to complain to a regulator. To use any of them for WME Requests data, email wazer@wmekit.com. We'll respond within 30 days. Removing your access to WME Requests doesn't delete your WMEKit account, and deleting your WMEKit account doesn't by itself remove your WME Requests data. Ask, and we'll remove both.

10. Changes to this policy

We may update this policy as the Service changes. We'll update the effective date above, and if a change significantly affects how we use your data, we'll tell you before it takes effect. WMEKit is run from South Africa.