Privacy Policy
1. Operator and scope
Bartr is operated by Pratyush Gavali, sole trader, ABN 30 490 757 095, based in Murrumbeena VIC 3163, Australia. Contact us at hello@getbartr.com. The suburb and postcode are our business locality; contact us to arrange postal correspondence.
This policy covers Marketplace listings, offers and conversations, Eatery food posts and pickups, organisation administration, the waitlist, and support. It explains our handling practices and how to raise a concern. We do not sell personal information or disclose it for another business's marketing.
We aim to handle information consistently with the Australian Privacy Principles. Whether particular Privacy Act obligations apply depends on the law and our circumstances, including applicable small-business exceptions. This policy does not remove any rights you have under Australian law. See the OAIC small-business guidance.
2. Information we collect
We collect information you enter, records generated when you use Bartr, and information other people provide in conversations, reviews, reports or organisation administration.
| Category | Information and purpose |
|---|---|
| Account and authentication | Email, account identifier and type, password handled by Supabase Auth, verification codes, confirmation records and session tokens. These create and secure your account. Supabase stores password hashes; Bartr does not retain plaintext passwords. |
| Profile | Name, university, campus, faculty where requested, and optional photo, bio and social links. |
| Age eligibility and agreement | Every member supplies their own date of birth, including club and store administrators. We store it privately to check the 18+ requirement, along with the Terms version and acceptance time. It is not displayed on your profile. Corrections require contacting support. |
| Marketplace | Listing descriptions, prices, rental and trade details, condition, category, campus, photos, view counts, saved listings, offers and messages, including their participants and timestamps. |
| Eatery | Food descriptions, photos, servings, price where applicable, dietary and allergen declarations, pickup location and window; reservation and collection records, deadlines, cancellations and expiry outcomes. |
| Organisations | Name, type, campus, logo, description, memberships, administrative roles, approval records and operational settings. Stores supply registration details such as an ABN or food-business registration for manual review. |
| Trust and support | Reviews, ratings, reports, reasons and supporting details, relevant listing/conversation references, support correspondence and notifications. A deletion request records your account identity, request time, status and reference. |
| Waitlist | Email, intended account type, university and campus, to understand demand and plan where to open. Joining the waitlist does not create an account. |
| Technical and usage information | Providers handle request and authentication logs, including IP addresses and browser/request metadata. Bartr records limited product-event names and coarse properties, operational logs and traces. Rate limiting uses temporary counters keyed by protected identifiers. |
Six-month email checks: the flow records your account identifier, verified email and the time of successful OTP proof. It uses those records to decide when to prompt again. Stores are exempt. These checks establish access to your email address; they do not establish your age or current enrolment.
We do not ask for payment-card or bank credentials, GPS tracking, biometric verification, student-card scans or enrolment documents. We do not run advertising profiles or session replay. Food labels describe the food, not a health profile of you. Your filter choices, messages, reports or photos may nevertheless reveal sensitive information; avoid including health details, identity documents or other people's private information unless needed for the matter you are reporting.
Some information is needed to operate a feature: without an account email we cannot verify access; without campus information we cannot provide the intended campus experience. Optional profile fields can be left blank. Only give us information about others when you have a legitimate reason and keep it relevant.
3. Purposes and automated processes
We use these records to run accounts, listings, conversations, reservations and reviews; show relevant campus content; review organisations and reports; respond to requests; prevent abuse; investigate faults; and understand how the MVP is used.
- University-email checks allow student and club accounts using
.eduor.edu.auaddresses. Email verification proves access to a mailbox, not current enrolment or identity. - Eatery reservations depend on capacity and a two-per-Melbourne-day allowance. Releasing a claim restores allowance; collected and expired claims count. Pickup deadlines affect availability.
- Message limits, authentication checks and rate limits may prevent an action. Quick chat has a three-message daily limit per listing, even if the seller replies.
- Marketplace search ranking and category preferences run in your browser. Usage events describe actions and result counts, not the text you searched for.
- Organisation approvals and reviews of user reports involve the operator. Contact us if you believe an automated restriction is incorrect.
4. Sharing and providers
Other users see the profile and listing information the product displays. Conversation participants see their messages and offers. Organisation admins see information needed to manage reservations and pickups. Store registration details are restricted to the organisation's admins and the operator; they are also included in approval emails.
Public Marketplace share links reveal a limited listing preview without sign-in. Uploaded profile photos, logos and listing images use public URLs. Anyone with an image URL may open or pass it on. Removing a listing from the feed does not necessarily delete its image.
| Provider | Information handled | Location and status |
|---|---|---|
| Supabase | Authentication, profiles, content, conversations, reservations, storage and realtime updates; service and authentication logs. | Project hosted in Sydney, Australia. Overseas support and subprocessors may also be involved; Sydney hosting is not a promise that all handling stays in Australia. |
| Vercel | Web hosting and API requests, request metadata, security controls, logs, traces and Web Analytics. | Functions configured for Sydney. Global edge delivery and a US provider mean handling may occur overseas, including the United States. Speed Insights performance collection is integrated but provider activation remains pending. |
| Brevo | Recipient addresses, verification and recovery messages, service notices, report receipts and operations alerts, including their contents. | Brevo states its data storage is in France, Germany and Belgium. It is the configured email provider. |
| Google Gmail | The operator's MVP operations mailbox receives reports, support and approval correspondence. Report emails include details and relevant identities; store approval emails include registration information. | A personal Gmail mailbox is used for the MVP. Google may process mail outside Australia, including the United States. |
| Upstash Redis | Temporary request counts and expiry times keyed with an HMAC-derived identifier. Raw user IDs and IP addresses are not placed in these keys; this is a security mechanism, not an advertising profile. | Configured resource in Sydney. Provider administration and support may involve overseas processing; it is not used to cache private messages or profiles. |
| OpenStreetMap Nominatim | Place-search text sent through Bartr's server and the server's request metadata. Do not enter private information into place search. | The OpenStreetMap Foundation states non-tile personal data is stored in the United Kingdom and the Netherlands, with backups in the EU. See its privacy policy. |
Not active: Sentry error reporting and PostHog product analytics are implemented but remain disabled pending configuration and processing-location confirmation. We will update this disclosure before enabling them. Cloudflare inbound-mail routing has not been confirmed and is not represented here as an active recipient.
We may provide relevant information to advisers or authorities where required by law or reasonably necessary to address fraud, a safety threat or a dispute. We aim to limit disclosures to what is needed. Provider contracts, subprocessors and final overseas processing arrangements are reviewed as our service changes.
5. Security and visibility
We use encrypted transport on hosted services, Supabase authentication, database access rules and rate limits. Server requests use the caller's authorization rather than a service-role bypass. Passwords, OTPs and session tokens are not intended to be logged. Access controls reduce risk but cannot guarantee that a service will never suffer a breach.
Messages are stored for delivery and relevant support or safety investigations; they are not end-to-end encrypted. Public image URLs and shared listing previews are not private. Use available profile controls carefully and do not assume all profile information is hidden from other signed-in users.
The six-month check is an in-app re-verification prompt. It does not automatically revoke sessions or prevent every direct API request from an overdue account.
6. Browser storage and analytics
Browser storage keeps your sign-in session, interface preferences, recent search/category preferences, cached account data and supported unsaved drafts. Drafts expire after 24 hours and are cleared on sign-out. Passwords and tokens are excluded from draft storage; authentication tokens are stored separately to keep you signed in. Closing a tab or clearing browser storage can remove drafts. Some device preferences persist separately.
Web Analytics measures page visits. The app removes query strings, fragments and UUID path segments from those events. Product telemetry records a fixed list of actions, such as onboarding, listings, offers, messages, claims, reviews, reports and deletion requests, plus coarse properties. It excludes message contents, search text, emails, account IDs and listing IDs. A random tab-scoped identifier accompanies these events; the application does not put that identifier in its product logs.
Web Analytics and product-event code respect supported Global Privacy Control and Do Not Track signals. Necessary service and security logs still operate. These preferences should not be understood as disabling all provider processing. We do not use advertising cookies or sell analytics data.
7. Retention and deletion
Account, transaction and support records remain stored while used to operate Bartr, resolve requests, investigate abuse or meet legal obligations. A soft-deleted listing or hidden record may remain in the database. Messages, reports, reviews and reservation history are not automatically erased when you remove something from a feed.
Deletion is a manual request, not an immediate automated erasure. Use Request account deletion in Settings to record an authenticated request and receive a reference. If you cannot sign in, contact us from your account email. We may verify the request before acting and explain information that must be retained and why.
Fixed retention schedules, the complete account-erasure procedure and storage cleanup are still being finalised. We do not promise deletion within 24 hours or permanent removal from backups immediately. Provider logs and backups have separate retention arrangements. Temporary rate-limit counters expire with their enforcement window; supported browser drafts expire after 24 hours.
8. Access and correction
You can edit supported profile fields in Settings and use the verified email-change flow. For a copy of information held about you, corrections not available in the app, waitlist removal or a deletion enquiry, email hello@getbartr.com. Include enough information to locate the record, but do not email a password or OTP.
We may verify identity and protect other people's information when responding. If we cannot provide access or make a correction, we will explain our reasons and how to challenge the decision, subject to lawful restrictions. There is no automated full-account export at present. You may make a general enquiry without an account; account-specific requests normally require identification.
9. Email and marketing
Service messages include verification and recovery codes, password-change notices, organisation approval correspondence, report receipts and deletion-request correspondence. You cannot disable essential authentication messages while using the related feature. We do not treat account creation or a security-email request as marketing consent.
The current waitlist supports demand planning. Promotional or launch-email campaigns are not currently enabled. Before sending them, we will obtain any required consent, identify the sender and provide a working unsubscribe method. We will not repurpose existing waitlist entries for an undisclosed campaign.
10. Age eligibility
Only people aged 18 years and over may be Bartr members, including people administering organisations. We check your supplied date of birth against the 18-year age threshold before enabling member features. Accounts with a missing or underage date cannot access those features. You must supply an accurate date.
This is a date-of-birth eligibility check, not independent identity or document verification. A university email alone does not prove adulthood. We plan to add campus integration for verification in future; it is not currently active and we do not currently obtain age or enrolment records through such an integration. Before enabling it, we will explain the information exchanged, purpose and any choices you have.
If you believe we hold information about someone below the intended age threshold, contact us so we can restrict the account and review appropriate handling of its records.
11. Contact, complaints and incidents
Contact Pratyush Gavali, Bartr, Murrumbeena VIC 3163 at hello@getbartr.com. Email is the current contact channel; ask us to arrange postal correspondence. We aim to acknowledge enquiries within five business days and respond substantively within 30 days, or explain any delay.
If a privacy complaint remains unresolved, the OAIC complaint process explains available options and its jurisdiction. This does not limit other rights or remedies.
We investigate suspected breaches, take steps to contain harm and notify affected people and regulators where legally required. Where the Notifiable Data Breaches scheme applies, we take reasonable steps to assess suspected eligible breaches within 30 days and notify as required. Report security concerns through the contact address without accessing other users' data. Bartr is not an emergency service.
12. Policy changes
We will update this page when our practices change and show the revised date. Material changes to handling of information already held will be communicated in the app or by email where appropriate. New optional monitoring providers will be disclosed before activation.