Privacy Policy

1. Information We Collect

Data	Source	Purpose
Apple ID email & name	Apple Sign In	Account creation & identification
Google account email, name & account identifier	Google Sign-In	Account creation & identification
Crew category, aircraft type, base	You (profile setup)	Filtering patterns to your eligibility
ARMS pattern book PDF	You (upload)	Parsing trip patterns for bid optimization
Bid briefs	You (free-text input)	AI-powered bid sheet generation
Bid sheets	Generated by the service	Optimization results for your review
Subscription status, plan and renewal dates, and the store’s transaction or purchase-token identifiers	Apple App Store (iPhone, iPad) or Google Play (Android)	Access control, verifying purchases, and billing support
Push-notification token, device platform, app version and operating-system version	Your device, when you allow notifications	Delivering the notifications you have switched on, via Apple Push Notification service (iPhone, iPad) or Firebase Cloud Messaging (Android)
Crash reports (Android): the crash stack trace, device model, operating-system and app version, and a random installation identifier	Firebase Crashlytics in the Android app	Finding and fixing crashes — never advertising
Problem reports: your description, any screenshots you attach, app and device details, and your account email	You (Report an Issue in the app)	Investigating and fixing the problem you reported
Pilot directory listing, buddy requests and links, and plans	You (your profile, the “Let other pilots find me” switch, requests you send or accept, plans you make or add)	Letting other pilots find you, sharing rosters with buddies you accept, and bidding together with pilots you make plans with
Forwarded ARMS roster emails	You (forwarded to your unique @bidcheck.co address)	Parsing your awarded roster into a calendar feed and proactive contact-window reminders
Awarded pattern records (pattern code, week of departure, your seniority number)	Derived from your forwarded roster	Aggregated, anonymized insights into pattern competitiveness for all pilots (e.g. typical seniority cohort that wins a given pattern)
Trip Swap discoverability flag, Qantas work email, employee number	You (Settings & in-app prompts)	Matching you with other pilots for a one-for-one trip swap and CC'ing your swap partner on the ARMS hand-off email
Trip Swap proposals & Port Requests (wishes)	You (Trip Swap screens)	Persisting your active proposals/requests, validating legality against crewing rules, generating the email pilots forward to crewing
Special-meal profile: meal type (dietary/health-related), authority reference, staff number, Qantas work email	You (Settings)	Automatically emailing your approved special-meal request to the relevant catering provider for each departure you operate
Catering email log (recipients, subject, send status — never the email body)	Generated by the service	Showing you what was sent and diagnosing delivery problems
Roster-forwarding recipients: email address and optional label (e.g. “Sarah”) of trusted people you choose	You (Settings)	Emailing a readable PDF version of your roster to the partner/family members you nominate
Roster-forwarding send log (recipient, bid period, send status — never the PDF itself)	Generated by the service	Avoiding duplicate sends, detecting amended rosters, and diagnosing delivery problems
Flightmates discoverability flag; your name, role, fleet and base shared with matched pilots	You (Settings toggle) & your forwarded roster	Showing other BidCheck pilots who else from the app is on the same sectors or layovers, and showing you to them
WhatsApp number & “allow flightmates to contact me” opt-in	You (Settings & onboarding)	Letting pilots on your trips message you on WhatsApp — shared only when you switch the opt-in on
Google account identifier & email address, and an encrypted Google Calendar authorization	You (connecting Google Calendar in Calendar Setup)	Writing your roster into a dedicated “BidCheck Roster” calendar in your Google account, and showing you which account it is going to
webCIS open-time board data: trip codes, departure and end dates, days away, credit hours, ports, and whether a trip is uncrewed or covering an absent crew member	You (signing in to Qantas webCIS yourself, on your device)	Showing you trips available for pickup, and — with your own bid markers removed — keeping a current shared board for pilots at the same base in the same crew category
Open-time alert records: which trips you have already been told about	Generated by the service	Making sure a trip is announced to you once and never repeated
Qantas work email verification: the address you verify, a one-way hash of the code we email to it (never the code itself), and when you verified	You (Settings → Account)	Confirming you are a Qantas pilot, which unlocks pattern browsing and bid optimization
Duties waiting to be accepted: the date, duty code, report time, number of days, credit, route and sign-on and sign-off of a duty crewing has assigned you	Your webCIS session, on your device, when webCIS shows its Crew Notifications page	Telling you straight away that a duty is waiting for you to accept in webCIS
Crew lists for the trips you open: the rank, fleet, base, name and pattern of each crew member on the flight	Your webCIS session, on your device	Showing you who is operating a trip. Passed straight back to your device; never stored by us
Flight details of amended open-time trips (sectors, times, aircraft, credit)	Your webCIS session, on your device, when you open such a trip	Showing every pilot the flights on a trip crewing has amended
Open Time device records: a random identifier BidCheck creates for each install (never a hardware serial or advertising identifier), device model and platform, app version, and when each device last refreshed Open Time or was signed out of webCIS	Your device, when Open Time refreshes	Telling you which of your devices needs signing in to webCIS again, and diagnosing refresh problems
Open-time watches: the date windows, ports and roster fit you choose	You (Open Time)	Alerting you when a matching trip appears
Co-parent Share: a label for the person you share with, optional contact details for them (stored encrypted), the dates and level of detail you choose, your notes for particular days, and the PDFs you issue	You (Roster → Sharing → Co-parent Share)	Showing a co-parent when you are home or away, at the level of detail you choose
Email Me My Roster: which of your own verified email addresses to use, whether automatic sends are on, and a record of each send (bid period, addresses, status)	You (Roster → Sharing)	Emailing a detailed copy of your roster to your own inbox
Leave swap and base swap postings and offers, and swap board listings and interests: the leave dates, trips or base you offer or want, any note, and your base, aircraft and crew category	You (Swap screens)	Showing your posting to the pilots it is visible to (see section 2) and preparing the hand-off for an agreed swap

1a. Sensitive (Health) Information

The special meal feature is optional. If you enable it, the meal type you select (for example gluten-free, lactose-free, or low-fat) relates to a dietary or medical requirement and is therefore sensitive information under the Australian Privacy Principles. We collect it only with your consent — given when you enable the feature and save your meal profile — and use it for a single purpose: requesting your approved meal from the catering provider for the flights you operate.

When BidCheck sends a request, your meal type (together with your name, staff number, authority reference, and operating flight details) is disclosed to the relevant third-party catering provider for that port, and you are CC'd on every email. You can disable the feature and delete your special-meal profile at any time in Settings. We never use this information for any purpose other than sending your meal request, and we never share it for advertising or analytics.

If you hold a written meal-approval document, BidCheck does not store or retain that document. The approval document stays on your own device and is never uploaded to our servers. We store only the structured fields you enter — the meal type and the authority reference number — which is all that is needed to send your request.

2. How We Use Your Information

• Bid optimization: Your bid brief and parsed pattern data are sent to Anthropic's Claude API to generate optimized bid sheets. No other purpose.
• Account management: Your Apple ID or Google account information is used solely for authentication and account identification.
• Subscription management: On iPhone and iPad, subscription transactions are handled entirely by Apple via StoreKit 2. On Android, they are handled entirely by Google Play Billing: Google processes your payment, and you manage, cancel, or request a refund through Google Play. When you buy on Android, the app sends us Google’s purchase token, which we check with Google to confirm and acknowledge the purchase. We never receive or store your payment details — only your subscription status and the store’s purchase identifiers.
• Push notifications: If you allow notifications, your device’s push token is stored against your account and used only to deliver the notifications you have switched on. The notification text (for example a contact-window reminder or a swap update) passes through Apple or Google to reach your device.
• Crash diagnostics (Android): The Android app reports crashes to Firebase Crashlytics so we can fix them. Crash reports contain technical information only — never your roster, bid brief, email address or Qantas credentials — and are not used for advertising or to track you.
• Pilot directory: If you are a verified pilot (you confirmed a Qantas email address or forwarded a roster), your name, rank, fleet and base are listed in a directory that other signed-in BidCheck pilots can browse and search, so they can find you, ask to share rosters, or invite you to bid together. Pilots you have flown or slipped with may see you at the top of their list with the flight or port and date you shared; that line appears only while your Flightmates discoverability is on. The directory is governed by a “Let other pilots find me” switch in Settings, which is on by default. Turning it off removes you from the directory immediately and stops new buddy requests and plan invitations reaching you; buddies you have already accepted keep seeing your roster until either of you removes the link. It is separate from the Flightmates and Trip Swap switches.
• Buddies (roster sharing): Nothing is shared until you agree. A pilot who wants to share rosters sends you a request, and you accept or decline it with one tap. Declining is silent: the pilot who asked is not told. Once you accept, your name and crew category are shared with your buddy, and each of you can view the other’s full roster in the app — duty codes, flight numbers, ports, and leave codes (including sick and personal leave) for the current and recent bid periods. Your buddy does not see your flown-hours statistics, your Flightmates, your bid brief, your email, or your subscription status. Removing a buddy stops roster viewing immediately.
• Bidding together (plans): You can invite any pilot in the directory, or a buddy, to plan to be in the same city on the same dates. The invitation shows them your name, the city, the dates and suggestions worked out only from the two pilots’ pattern books — nothing from your roster, leave, days off or bid brief. Until they add the plan, that is all they see. If they add it, its bids are added to their own bid sheet; if they narrow the dates first, the narrowed dates are shared with you and your bid sheet is updated to match. Neither pilot ever sees the other’s bid sheet or bid brief.
• Roster ingestion: Rosters you forward to your unique @bidcheck.co address are parsed into day-level structured data, stored against your account, and used to generate your private calendar feed and proactive contact-window reminders (A-day BLH/PLH, RM54 last-duty-free, 15-4 pre-duty call-in).
• Aggregated pattern competitiveness insights: The patterns awarded to you and your seniority number, derived from forwarded rosters, are retained and combined with the same data from other pilots to produce aggregated, anonymized insights about which seniority cohort typically wins each pattern. Individual awards are never disclosed to other users, attributed to you by name, or linked to your identity in any user-facing surface.
• Special Meals: If you enable the optional special meal feature, BidCheck reads your current roster to determine each port you operate a departure from, and emails your approved meal request (your name, staff number, meal type, authority reference, and flight numbers and dates) to that port's catering provider between roughly 48 and 24 hours before departure. You are CC'd on every email and replies route to your nominated work email. We send on your behalf; we never receive catering's response. See section 1a for how we handle the dietary/health aspect of this data.
• Roster Forwarding: If you add trusted recipients (for example a partner), BidCheck re-renders your parsed roster as a readable PDF — a calendar grid plus per-trip detail (flight numbers, ports, sign-on and landing times) — and emails it to each recipient you have nominated. Recipients are double opt-in: an address receives nothing until the person clicks a verification link, and every email carries a one-click unsubscribe. A new or amended roster is forwarded automatically, and you can send on demand from Settings. This data reveals your location and movements, so it is shared only with the people you explicitly choose and verify; you can remove a recipient at any time, which stops all further sends to them immediately. We do not Cc ourselves and we do not retain the PDF.
• Flightmates & WhatsApp contact: When you forward a roster, BidCheck indexes the sectors you operate and the nights you spend at each downroute port so it can show other BidCheck pilots on the same trip who else is there — and show you the same. Matched pilots see your name, role, fleet and base (with a marker if you are buddies); they never see your staff number, email, bid brief, or any part of your roster beyond the shared sector or layover. This is governed by a Flightmates discoverability flag, which is on by default — turn it off in Settings to disappear from other pilots' lists immediately. Separately and independently, if you add a WhatsApp number and switch on “allow flightmates to contact me” (off by default), your number is shared with pilots on your trips so they can open a WhatsApp chat with you in one tap. You can be visible in Flightmates without sharing a number, and switching the WhatsApp opt-in off (or clearing the number) stops it being shared immediately.
• Trip Swap: If you are discoverable for swap proposals (on by default — see below), the trips on your current roster become visible to same-base pilots in your aircraft + crew category cohort when they look for a match. They can see the pattern code, sign-on date, credit hours, and your display name + base. They cannot see your bid brief, leave dates, personal preferences, or roster outside the cohort filter. When you propose a swap to another pilot, both of you become visible to each other and the proposal is shared with both. When you post a Port Request, the destination you want and the trips you're offering are visible to out-of-base pilots in your same cohort — those pilots cannot see your wider roster, only what you chose to expose in the request. You can disable Trip Swap discoverability at any time in Settings → Privacy; doing so removes you from match lists and hides your trips from other pilots immediately, though buddies you have explicitly linked still see your trips for swap purposes regardless of the flag.
• Leave swaps, base swaps and the swap board: These also require Trip Swap discoverability. A leave swap posting (an annual leave block you want to trade) is shown with your display name to discoverable pilots in your aircraft and crew category at every base; offers made on it, and the names of the pilots offering, are visible only to you. A base swap posting is shown with your display name, home base, the bid period, your note, your rotation position and seniority group, to pilots at the base you want to move to in your aircraft and crew category. On the swap board, listings are shown to discoverable pilots in your bid period, aircraft and crew category without your name (pilots at other bases can view them, but can only respond if you have said you are willing to commute) — as “Another B787 F/O”, for example — except to your buddies, to a pilot whose trip matches, and to a pilot who has said they are interested. When a swap is agreed, the hand-off text (both pilots' names, employee numbers and home bases) goes only to the two of you; BidCheck never contacts crewing.
• Google Calendar sync: Optional and off unless you connect it. If you connect a Google account, BidCheck creates a dedicated “BidCheck Roster” calendar in that account and writes your roster into it — duty type, dates and times, ports, and the same trip detail the app shows you (flight numbers, sign-on and landing times, credit and allowance figures). Your roster is pushed again whenever it changes, so an amendment appears in seconds rather than waiting for Google to refresh a subscribed feed. We use this access for nothing else. You can disconnect at any time from the app’s Calendar Setup screen.
• Open Time (webCIS): Optional. You sign in to Qantas webCIS yourself, inside a window on your own device, exactly as you would in a browser — Microsoft SSO and your 2FA run in your own session. Your Qantas password is never sent to us and never stored by us. Only the session cookies exist, and they stay on your device: in the system cookie store and, on iPhone and iPad, also in the device’s Keychain so the app can reuse your session after a restart. Signing out of BidCheck deletes them. The open-time page itself is sent to BidCheck, where it is parsed into the list of trips you see in the app and the page is then discarded — we do not keep the raw page. The parsed board is stored against your account, and a copy with your own bid markers removed is shared with pilots in your base and crew category (see section 2b). If you turn on open-time alerts, BidCheck also reads your own roster to work out whether a trip clashes with something you are already flying, so the alert can tell you — your roster is never shared with anyone as part of this.
• What BidCheck reads from webCIS: When you use webCIS inside BidCheck, the pages you look at are not sent to us, with these exceptions, which happen only on a device where Open Time is on: (1) the open-time board, which BidCheck refreshes in the background — including while you are browsing webCIS in BidCheck, at most every 10 minutes; (2) the Crew Notifications page, when webCIS is holding you there because crewing has assigned you a duty; (3) the flight details of an amended open-time trip, when you open it; and (4) crew lists, as described below. A webCIS page opened from a call-in reminder sends nothing to us. BidCheck never bids, accepts or rejects a duty, or changes anything in webCIS for you.
• Duties waiting to be accepted: When webCIS holds you on its Crew Notifications page, that page is sent to us, along with webCIS’s own duty-details view if it is open — which can show your name, staff number, seniority and roster. We keep only the waiting duty’s details (listed in section 1) so we can notify you, and we discard the page without storing or logging it. BidCheck shows you the duty; accepting it is always yours, in webCIS.
• Crew lists: When you open an open-time trip, or an upcoming trip on your roster, your device looks up the crew list for its first operating sector in webCIS, on your own session (other sectors only when you tap them). The crew-list section of that page is sent to us and parsed into each crew member’s rank, fleet, base, name and pattern; seniority, position and staff numbers are discarded as it is parsed. The result goes straight back to your device, which keeps it in memory for 30 minutes; we store none of it and log no names. It is the same list webCIS already shows you. Your own staff number, from your roster, is used only to mark your own row and then discarded. BidCheck never touches webCIS’s option to remove your name from the crew list.
• Which device is signed out: Each device reports how its Open Time refreshes went, with a random identifier BidCheck creates for that install and its model, so we can tell you which device needs signing in to webCIS again and diagnose refresh problems. These reports are written to our server logs; the per-device record is described in section 1.
• Qantas verification: To confirm you are a Qantas pilot, BidCheck emails a one-time code to the Qantas work address you enter. We store a one-way hash of the code, never the code, and record that you verified and which address you proved. A roster you forward also counts as verification.
• Co-parent Share: Optional. You choose a date range and a level of detail, and BidCheck creates a private link (and, if you want, a signed PDF) showing the person you share it with when you are home or away. At the least-detailed level they see only “home” or “unavailable” days; at the most detailed, destinations, flight numbers and trip times. Your notes for particular days are shown too. They never see sick-leave labels (those days show as home or away), your buddy, swap or bid data, or which level you chose. You send the link or PDF yourself; BidCheck does not email or text it. Contact details you enter for that person are stored encrypted and are not currently used to send anything. Revoking a share stops the link working immediately. We record only when a link was last viewed and how many times, and use no tracking pixels.
• Email Me My Roster: Optional. BidCheck can email a detailed copy of your roster — including your name, staff number, category, base, seniority, hours and qualification expiry dates, every sector, and the original ARMS roster text as an attachment — but only to your own verified addresses (the email you sign in with, or a Qantas address you have verified); you cannot enter any other address. Automatic sends when your roster changes are off unless you turn them on, and every email carries a one-click unsubscribe.
• Voice bid briefs (iPhone, iPad): If you dictate a bid brief, it is transcribed by Apple’s on-device speech recognition; the audio never leaves your device and is never sent to us.

2a. Trip Swap Default — What Changed

From version 1.13 onwards, Trip Swap discoverability is on by default for all accounts. Previously this setting defaulted off and required an explicit opt-in. We changed the default to make the feature actually usable — a default-off swap directory with a small user base means nobody finds anyone, so the feature dies.

When the change went live, every existing account was flipped to discoverable. The next time you opened the upgraded app, the What's New screen showed you a toggle so you could opt back out in one tap. If you want to opt out at any time, go to Settings → Privacy → Discoverable for swap proposals.

What "discoverable" means and what data is shared is described in section 2 above. Trip Swap is a same-cohort, same-aircraft feature: pilots flying different aircraft or in different crew categories never see each other regardless of the flag.

2b. Open Time — What Your Check Shares

The open-time board is not personal to you. It is the board for a cohort — every pilot at the same base, on the same aircraft, in the same crew category. Two pilots in that group see the same trips. So when one pilot checks it, BidCheck keeps that board and shows it to the others, which is what stops you looking at a board that went stale days ago because your own webCIS session expired.

Two things about you are never shared, and are removed before your check reaches anyone else: which trips you have placed a bid on, and any bid of yours that has since died. Those are the only facts on the board that are about you rather than about the trips. Everything else — trip codes, dates, credit hours, ports, and whether a trip is uncrewed or sick cover — is identical for everyone in your cohort and is shared as-is. The pilot who contributed a board is never identified to anyone.

There is no opt-out for this, and we think you should know why rather than find out later. The shared board is only current because pilots keep signing in and checking it; an opt-out would let people read a board kept fresh by everyone else while contributing nothing, and the board would go stale for the whole group. Signing in to webCIS is what contributes. If you would rather not contribute, do not use the open-time feature — nothing is collected from webCIS unless you sign in.

When you open an open-time trip that crewing has amended, BidCheck fetches its flight details on your session and keeps them with the boards that show that trip, so every pilot sees the same flights. That record holds only the trip — never who fetched it — and is deleted three days after the trip departs.

Sharing is confined to your own cohort: pilots at a different base, on a different aircraft, or in a different crew category never receive your check. If you have forwarded a roster, we use the base and crew category from it rather than what you typed into your profile, so you are matched to the board you actually fly.

3. Third-Party Services

• Anthropic (Claude API): Bid briefs and parsed pattern data are sent to Anthropic's servers in the United States for AI-powered optimization. Anthropic's use of this data is governed by their privacy policy. Anthropic does not use API inputs to train their models.
• Apple: Authentication via Apple Sign In, payments via StoreKit 2, and push notifications on iPhone and iPad via Apple Push Notification service. Governed by Apple's privacy policy.
• Google (Sign-In, Google Play and Firebase): Authentication via Google Sign-In; on Android, payments via Google Play Billing, push notifications via Firebase Cloud Messaging (which receives your device’s push token and the notification text in order to deliver it), and crash reports via Firebase Crashlytics. Google’s servers are located in the United States and elsewhere, so using these services involves a disclosure of that information overseas. Governed by Google’s privacy policy and the Firebase privacy information.
• GitHub and Discord (support tools): A problem report you send from the app is filed in our private GitHub issue tracker and posted to our internal Discord channel so we see it promptly; both services are operated from the United States. They receive only what the report contains.
• Resend (email delivery): If you use Special Meals, Roster Forwarding or Email Me My Roster, or verify a Qantas email address, and when we email you about something you reported or asked, the relevant emails are sent through Resend, an email delivery provider (or, when it is our configured delivery route, Amazon Simple Email Service, which processes the same information on the same terms under Amazon Web Services' privacy notice). To send a message, Resend processes the recipient address, your name, and the message content — for Special Meals that includes your staff number, meal type, authority reference, and flight details; for Roster Forwarding it includes your roster PDF attachment (your flying schedule); for Email Me My Roster it includes your detailed roster and the original ARMS roster text; for Qantas verification it is the one-time code. Resend's servers are located in the United States, so using these features involves a disclosure of your information overseas — including, for Special Meals, the sensitive dietary information described in section 1a. Governed by Resend's privacy policy.
• Cloudflare (email routing and off-site backups): Roster emails you forward to your personal @bidcheck.co address are received by Cloudflare Email Routing and passed straight to our server, and our encrypted off-site database backups are stored in Cloudflare R2. Cloudflare operates globally, including in the United States, so these involve a disclosure of your roster information overseas. Governed by Cloudflare's privacy policy.
• Catering providers: When you use Special Meals, your meal request is emailed to the third-party in-flight catering provider for each port you operate a departure from (for example dnata, LSG Sky Chefs, Gate Gourmet, Newrest, or SATS). Those providers receive your name, staff number, meal type, authority reference, and operating flight details for the sole purpose of preparing your meal.
• Roster-forwarding recipients: When you use Roster Forwarding, your roster PDF is emailed to the trusted people you nominate and verify (for example a partner). They are not BidCheck users and we assume you trust them with your schedule; they receive only what is in the PDF. You choose, verify, and can remove each recipient, and each recipient can unsubscribe at any time.
• Google (Calendar sync): Optional and off unless you connect your Google account. BidCheck requests a single Google Calendar permission — the https://www.googleapis.com/auth/calendar.app.created scope — which limits BidCheck to calendars it created, so BidCheck cannot read or modify your personal or work calendars. Alongside it, connecting uses Google’s standard sign-in scopes — openid, email (your email address) and, on iPhone and iPad, profile (your name and profile picture), which Google’s official Sign-In SDK adds automatically — so we can show you which Google account your roster is going to. These are non-sensitive, and BidCheck requests no other Google data. BidCheck creates one dedicated “BidCheck Roster” secondary calendar in your account and writes your roster events into it — duty type, dates and times, ports, and the flight detail shown in the app. Google’s servers are located in the United States, so connecting Google Calendar involves a disclosure of your roster information overseas. Governed by Google’s privacy policy. Disconnecting from the app’s Calendar Setup screen deletes the “BidCheck Roster” calendar from your Google account and revokes BidCheck’s access.

We do not sell, rent, or share your personal information with any third parties except as described in this policy. When you use Special Meals, your meal request details are emailed on your behalf to the catering provider(s) for the ports you operate, and routed via the email provider above, as described in sections 1a and 2. If you are a verified pilot and “Let other pilots find me” is on (the default), your name, rank, fleet and base are visible to other signed-in BidCheck pilots in the pilot directory. When you accept a buddy request, your name and crew category are shared with that pilot and each of you can view the other’s full roster; you can remove a buddy at any time, which immediately stops roster sharing with that pilot. A plan invitation shows the other pilot only suggestions worked out from the two pattern books until they add the plan, as described in section 2. Leave swap and base swap postings show your display name to the pilots described in section 2; swap board listings do not show your name except to buddies, matching pilots and interested pilots. When you use Co-parent Share, the person you give the link or PDF to sees what is described in section 2. Crew-list names you look up pass through our server to your device and are never stored. When Trip Swap discoverability is on (the default — see section 2a), your display name, base, crew category, and the trips on your current roster are visible to other pilots in your same-base cohort, and your destination wishes are visible to out-of-base pilots in your same aircraft + crew category cohort. Turning the toggle off in Settings → Privacy removes you from those surfaces immediately. Aggregated pattern competitiveness insights derived from forwarded rosters are shown to other BidCheck users only in anonymized, statistical form — never as individual awards, never attributed to you. When Flightmates discoverability is on (the default), your name, role, fleet and base are visible to other BidCheck pilots on the same sectors or layovers; if you also opt in to WhatsApp contact, your WhatsApp number is shared with those pilots so they can message you, and tapping to message opens the third-party WhatsApp application (governed by WhatsApp's own privacy policy). Both can be turned off in Settings. When you check Open Time, the trips on that board — with your own bid markers stripped out and with no indication that the check came from you — are shown to other BidCheck pilots at your base in your crew category, as described in section 2b. We do not use analytics, tracking cookies, advertising identifiers, or third-party advertising services; the only diagnostics we collect are the Android crash reports and the Open Time refresh reports described above.

3a. Google API Services User Data Policy

BidCheck’s use and transfer of information received from Google APIs to any other app will adhere to Google API Services User Data Policy, including the Limited Use requirements.

In practice this means the Google Calendar access you grant is used for one purpose only: writing your own roster into the “BidCheck Roster” calendar in your own Google account, and removing that calendar again when you disconnect. We do not sell this information, we do not use it for advertising or any form of profiling, we do not use it to train any AI or machine-learning model, and we do not transfer it to anyone other than Google in the course of writing your calendar. No human at BidCheck reads it, except where you ask us to in order to resolve a support issue, where it is necessary for security purposes, or where we are required to by law.

4. Data Retention

• Account data (email, name, profile): retained until you delete your account.
• Bid sheets: retained for 12 months, then automatically deleted.
• Uploaded PDFs: parsed server-side and not retained after parsing is complete. We do not store your pattern book files.
• Buddy links and buddy requests: a link is retained until either pilot removes it; a request until it is accepted, cancelled or declined. Removed links and cancelled or declined requests are soft-deleted (their status is changed) and purged after 90 days; a link that an old Buddy Sync bid sheet still refers to is purged once that bid sheet is deleted.
• Plans (bidding together): a plan is kept for both pilots while it can still affect a bid, whatever its state, and is deleted 90 days after the end of the bid period it was for. Deleting your account deletes your plans straight away and takes their bids off the other pilot’s bid sheet.
• Forwarded rosters & derived day-level data: retained until you delete your account, after which they are removed.
• Aggregated award records: the per-award rows (pattern code, week of departure, seniority, trip start date) are retained indefinitely to build historical coverage. When you delete your account, the link back to your identity (pilot_user_id) is set to NULL but the anonymized award row remains in the aggregate dataset.
• Trip Swap proposals & Port Requests: active proposals/requests are retained until accepted, declined, withdrawn, expired, or invalidated by a roster change. Once resolved they are retained for 90 days for support/audit, then deleted. Wishes auto-expire at the end of their bid period or 14 days from creation, whichever is sooner. When you delete your account, all your proposals and requests are deleted immediately; proposals made to you by other pilots are anonymised but retained for the other pilot's history.
• Special-meal profile (meal type, authority reference, staff number, work email): retained until you disable the feature, delete the profile, or delete your account.
• Special-meal approval document: not stored. BidCheck never receives or retains your approval document — it stays on your own device.
• Catering email log: the recipients, subject, and send status of each request (never the email body, which we do not store) are retained against your account so you can see your send history and so we can diagnose delivery problems. They are removed when you delete your account.
• Roster-forwarding recipients (email, optional label, verification/unsubscribe status): retained until you remove the recipient or delete your account.
• Roster-forwarding send log: the recipient, bid period, and send status of each forward (never the PDF, which we do not store) are retained against your account to prevent duplicate sends, detect amended rosters, and diagnose delivery problems. They are removed when you delete your account.
• Flightmates index: the sector and layover index derived from your forwarded roster is rebuilt each time you forward a roster and is removed when you delete your account.
• WhatsApp number & contact opt-in: retained until you clear the number, switch the opt-in off, or delete your account.
• Google Calendar link: we store your Google account identifier and email address (so you can see which account your roster is going to), an encrypted authorization token, the id of the “BidCheck Roster” calendar we created, and sync bookkeeping (when we last synced successfully and any recent sync error). The authorization token is encrypted at rest and is never returned by any BidCheck API. All of it is deleted when you disconnect Google Calendar or delete your account. In both cases we also delete the “BidCheck Roster” calendar from your Google account and revoke our access, so nothing of ours is left behind in your Google account.
• webCIS open-time page: not retained. The page is parsed into trips and discarded; we do not store the raw page, and we never log it. Your Qantas credentials are never received in the first place.
• Your parsed open-time board: we keep only the most recent one — each check replaces the last — and it is deleted when you delete your account.
• The shared cohort board: one board per base and crew category, replaced by whichever check is most recent. Because it is the cohort's board rather than any one pilot's, it is not deleted when you delete your account — but it holds no information about you: your bid markers were stripped before it was shared, and the record of who contributed it is cleared when your account goes.
• Open-time alert records: the record of which trips you have been told about is removed once the trip has departed, and immediately when you delete your account.
• Qantas verification records: the verified address and the record of each code we sent (stored only as a one-way hash; codes expire after 10 minutes) are kept until you delete your account.
• Duties waiting to be accepted: a duty is marked cleared once it is no longer waiting; the record stays against your account until you delete it. The Crew Notifications page itself is never stored.
• Crew lists: not stored by us. Your device keeps the most recent results in memory for 30 minutes and clears them when you sign out.
• Amended trip details: deleted three days after the trip departs. They are not linked to you.
• Open Time device records: records for a device that has not been active for 90 days are removed, and all of them when you delete your account. Refresh reports are kept only in server logs.
• Open-time watches: deleted a day after their date window ends, or when you remove them or delete your account.
• Co-parent Share: the share, your notes, the encrypted contact details and the PDFs you issued are kept until you delete your account. Revoking a share stops it working straight away but keeps the record, so a PDF you issued can still be confirmed as genuine. Shares expire on the date you set (at most about two years ahead).
• Email Me My Roster: your settings and the record of each send are kept until you delete your account. We do not keep the emails themselves.
• Leave swaps, base swaps and swap board listings: expired, withdrawn and completed items are kept as history until you delete your account; turning swap discoverability off withdraws your open postings.
• Subscription records: your subscription status and the store’s purchase identifiers are retained until you delete your account. Apple and Google keep their own purchase records under their own policies.
• Push-notification tokens: kept while notifications are registered on that device; removed when you sign out on it, when Apple or Google reports the token invalid, or when you delete your account.
• Android crash reports: kept by Firebase Crashlytics for 90 days, then deleted by Google.
• Problem reports: kept in our issue tracker until the issue is resolved and no longer needed; we delete them on request.
• Support emails: when we email you about something you reported or asked, we keep a copy (your address, the subject and the message) so we can follow up. It is deleted when you delete your account.
• Server access logs (which include IP addresses): kept for 7 days for security and rate limiting, then deleted.
• Backups: the database is backed up once a day to access-controlled storage, on our server and off-site, used only to recover the service after a failure — never to restore or look up an individual account. We keep the 30 most recent daily backups, so deleted data is gone from them within about 30 days. The first backup of each month is also kept in a disaster-recovery archive for 12 months and then automatically deleted, so deleted data is gone from every backup within about 12 months.

5. Data Security

We protect your data using:

• TLS encryption for all data in transit
• JWT-based authentication with HS256 signing
• Server-side API key management (your device never holds AI service credentials)
• PostgreSQL with connection encryption
• AES-256-GCM encryption at rest for third-party credentials, such as your Google Calendar authorization, and for co-parent contact details
• Rate limiting and request size controls

6. Your Rights

• Access: You can view your profile data and bid sheets within the app at any time.
• Deletion: You can delete your account at any time in the app on iPhone, iPad or Android (Settings → Account → Delete Account), or, if you no longer have the app, by emailing us from your account’s email address as described on our account deletion page. Deletion immediately and irreversibly removes your data from the live service, including profile information, rosters, bid sheets, and optimization history. What is kept afterwards — anonymised award records, the shared Open Time board (which holds nothing about you), and copies in our backups (daily backups for about 30 days; monthly archive snapshots for 12 months) — is set out in section 4 and on that page. Deleting your account does not cancel an Apple or Google Play subscription — cancel it with the store first.
• Portability: Bid sheets can be viewed and copied from within the app.

7. Children's Privacy

BidCheck is designed for professional airline pilots. We do not knowingly collect information from anyone under the age of 18. If you believe a child has provided us with personal information, please contact us and we will delete it.

8. Changes to This Policy

We may update this Privacy Policy from time to time. We will notify you of material changes through the app or by updating the "Last updated" date above. Continued use of BidCheck after changes constitutes acceptance of the updated policy.