Privacy Policy
Last updated: 11 September 2026
BidCheck provides an AI-powered roster bid optimization service for airline pilots. This Privacy Policy explains how we collect, use, and protect your information when you use the BidCheck iPad app and backend service. This policy is provided in accordance with the Australian Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).
1. Information We Collect
| Data | Source | Purpose |
|---|---|---|
| Apple ID email & name | Apple 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 | Apple App Store | Access control and billing |
| Buddy link data | You (invite/accept) | Connecting you with another pilot for joint bid optimization |
| 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 |
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 information is used solely for authentication and account identification.
- Subscription management: Subscription transactions are handled entirely by Apple via StoreKit 2. We store only your subscription status, not payment details.
- Buddy Bidding: When you link with another pilot, your name and crew category are shared with your buddy. During Buddy Sync, the backend reads both pilots' bid briefs server-side to generate buddy-aware bid sheets. Your buddy never sees your bid brief text, raw preferences, personal dates, email, or subscription status — only the resulting schedule overlap (matched patterns, shared slip days).
- Roster ingestion: Rosters you forward to your unique
@bidcheck.coaddress 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.
- 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 cookie exists, and it stays on your device in the system cookie store. 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.
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.
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 and payments via StoreKit 2. Governed by Apple's privacy policy.
- Resend (email delivery): If you use Special Meals or Roster Forwarding, the relevant emails are sent through Resend, an email delivery provider. 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). Resend's servers are located in the United States, so enabling either feature 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.
- 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.createdscope — 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. When you use Buddy Bidding, your name and crew category are shared with pilots you explicitly link with. You can remove a buddy link at any time from Settings, which immediately stops all data sharing with that pilot. 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, or third-party advertising services.
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 the 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: retained until either pilot removes the link. Removed links are soft-deleted (status set to “removed”) and purged after 90 days.
- 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.
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
- 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 from the app's Settings screen. This permanently removes all your data, including profile information, bid sheets, and optimization history. Account deletion is immediate and irreversible.
- 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.
Questions about this Privacy Policy or your data?
support@bidcheck.co