Flight Crew View Logbook API
Access Policy

Version 1.1

Overview

The Flight Crew View (“FCV”) Logbook API is designed solely for logbook workflows: importing, normalizing, and exporting a user’s flight history for record-keeping. This policy sets expectations for partners across three access tiers (Hobbyist, Indie, Established), defines permitted and prohibited uses, and describes minimum standards for branding, pricing transparency, security, and incident handling. It is intended to keep pilots’ data safe, avoid brand confusion, and ensure the API is never used for flight planning, dispatch, or other operational purposes.

1. Definitions & Scope

1.1 Definitions

“Logbook Workflows”

Workflows whose primary purpose is to maintain, review, analyze, and export a pilot’s or flight attendant’s flight history for record-keeping or compliance with logbook requirements. Typical examples:

• Importing flights from FCV into a logbook app.
• De-duplicating flights and reconciling discrepancies.
• Normalizing time zones and computing block/flight/landings.
• Exporting to logbook formats (e.g., LogTen, CSV, PDF) for record retention.

“Operational Use”

Any use where the FCV Logbook API output could reasonably influence decisions for upcoming or active flights, including but not limited to:

• Flight planning, dispatch, or go/no-go decisions.
• Weather/NOTAM briefings or operational alerts.
• Runway/taxi guidance, approach recommendations, or performance calculations.
• Live operational monitoring (e.g., ADS-B/FlightAware overlays used to make real-time operational decisions).

“Operational Documents”

Any document or packet used for upcoming or active flight operations, including but not limited to: dispatch release/flight plan, fuel plan, NOTAM packet, weather briefing package, MEL/CDL/TAC items, performance data, flight plan route/navlog, and airport surface materials.

“AI / LLM Processing”

Use of machine learning systems (including large language models) to summarize, extract, classify, rewrite, or generate text from input data.

“Derived Operational Artifact”

Any output (summary, highlight list, “brief,” checklist, alert, recommendation, or decision aid) created from Operational Documents or real-time operational data that could reasonably influence decisions for upcoming or active flights.

“User’s Own Flights”

Flights associated with the FCV account that initiated the authorization flow. For the purposes of this policy:

• Data must be used only for the end user who granted access.
• Aggregation across multiple users is allowed only in tiers and workflows explicitly approved by FCV and only for logbook-centric usage (e.g., admins managing multiple logbooks, anonymized analytics).

“Synthetic Test Dataset”

A fixed, non-production sample account exposed via a documented test passkey (e.g., TEST1234) that always returns the same example flights. This dataset:

• Must be used for development/demo until production access is approved.
• Must not be marketed as real user data.
• Helps validate auth flows, time zone handling, and idempotent imports.

“Indie” Tier

A commercial or semi-commercial access tier intended for independent developers and small teams. Features:

• Multi-user support under lower rate limits.
• Additional review and compliance requirements beyond Hobbyist.
• For logbook-centric apps that provide clear value beyond FCV’s native features.

“Established” Tier

A higher-throughput tier for mature products and teams. Features:

• Higher rate limits and additional support expectations.
• Demonstrated operational maturity (monitoring, support, incident handling).
• May include additional contractual and insurance/indemnity requirements.

1.2 Scope of This Policy

• Applies to all FCV Logbook API clients (Hobbyist, Indie, Established).
• Supplements, but does not replace, the FCV Terms of Service, Privacy Policy, or any signed partner agreements.
• Focuses on:
  • Logbook-only scope.
  • Brand and UX requirements.
  • Security, data handling, and rate-limit behavior.
  • Tier upgrade criteria and enforcement.

2. Tier Matrix

Dimension	Hobbyist	Indie	Established
Intended Use	Personal, self-only logbook experimentation and use.	Commercial or semi-commercial logbook apps for small/medium user bases.	Mature commercial logbook platforms with significant user volume.
Auth Method	OAuth 2.0 Authorization Code (server-side only).	OAuth 2.0 Authorization Code (server-side only).	OAuth 2.0 Authorization Code (server-side only).
Subject Binding	Access tokens bound to a single FCV user_id (self-only).	Access tokens bound to individual FCV user_ids, one per end user.	Same as Indie, with additional monitoring & audit expectations.
Data Scope	User’s own flights only. No multi-user analytics.	User’s own flights only; optional aggregated, anonymized analytics if approved.	Same as Indie; may include limited admin dashboards if logbook-only.
Default Rate Limits	300 /flights/ and /revokeToken/ requests per minute (per client), subject to global caps and per-user limits. 5 /token/ requests per minute.	300 /flights/ and /revokeToken/ requests per minute (per client), subject to global caps and per-user limits. 30 /token/ requests per minute.	300 /flights/ and /revokeToken/ requests per minute (per client), subject to global caps and per-user limits. 120 /token/ requests per minute.
Automated Polling	Max 1 per day per end user; overnight (North America) recommended; keep within a small fraction of tier cap.	Same as Hobbyist; additional monitoring expectations.	Same as Indie; may negotiate custom polling patterns in partner agreement.
Allowed Endpoints	/flights/, /token/, /revokeToken/ only.	Same as Hobbyist; additional endpoints only by written approval.	Same as Indie; additional endpoints only by written approval.
Synthetic Test Dataset	Provided for initial development and demo.	Provided for regression tests and demos.	Provided for QA and sandbox environments.
Support / SLA	Best-effort email.	Email support; reasonable response-time targets (e.g., 3 business days).	Email support; reasonable response-time targets (e.g., 3 business days).
Billing	Free.	Free.	Free.
Required Documents	None beyond acceptance of FCV terms.	Public website, ToS, Privacy Policy, logbook-only attestation.	Same as Indie, plus established logbook that is used and recognizable within the industry.

3. Permitted Uses

The FCV Logbook API may be used for the following logbook-centric workflows, provided all other terms are met:

Logbook sync and import

• Downloading the signed-in user’s flights from FCV.
• Incremental sync (e.g., using start_datetime_* filters).
• Reconciliation and de-duplication using fcv_flight_id or equivalent stable identifiers.

Logbook review, QA, and analytics

• Displaying flight history for the user’s own record-keeping.
• Discrepancy detection (e.g., missing tails, inconsistent block times).
• Tail-number completion using FCV-provided fcv_tail_number and schedule tail info.
• Personal analytics (e.g., hours by aircraft type, night vs day, landings).

Normalization and exports

• Time zone normalization to IANA zones, including DST and overnight flights.
• Conversion into third-party logbook formats (e.g., logten:// deep links, CSV, PDFs).
• File exports and Logten syncs are already provided by FCV, so there must be a clear, material added value.
• Idempotent imports (e.g., re-running sync without duplicating flights).

User-controlled data operations

• User-initiated export (e.g., CSV, logbook export, or in-app data download).
• User-initiated deletion of imported copies of their FCV data.
• User-facing settings for controlling polling frequency and date range.

AI for Logbook Workflows (Permitted with constraints)

AI/LLM Processing may be used only for historical logbook-centric functions (e.g., categorizing past flights, generating summaries of past experience totals, helping the user find entries, formatting export notes), provided outputs:

• Are limited to the user’s historical flight history.
• Do not create alerts/briefs/checklists for upcoming or active flights.
• Do not ingest Operational Documents.

4. Prohibited Uses

The FCV Logbook API must not be used for:

4.1 Operational Use (Strictly Prohibited)

• Any weather/NOTAM briefing, flight planning, dispatch, or go/no-go recommendation.
• Runway/taxi routing, airport surface guidance, or any navigational assistance.
• Summarizing, highlighting, or generating a “shortened brief” from Operational Documents (e.g., dispatch releases, NOTAM packets, weather briefings, MEL/CDL/performance notes), including via AI/LLM Processing, even if presented as “informational only.”
• Creating Derived Operational Artifacts for upcoming or active flights, regardless of whether the output includes an explicit recommendation.
• Real-time operational monitoring, including:
  • Combining FCV schedule/logbook data with live ADS-B, FlightAware, or similar feeds where the resulting workflow is used to influence operational decisions.
• Alerts that could affect active or upcoming flights, such as:
  • “Do not depart” alerts, performance warnings, or derived safety advisories.

For avoidance of doubt: AI-generated or AI-assisted briefs of Operational Documents are Operational Use under this policy.

Any Operational Use is grounds for immediate suspension or revocation.

4.1.1 Combination With Other Data Sources (Also Prohibited When Operational)

Partners must not combine FCV Logbook API data with Operational Documents or real-time operational data (e.g., ADS-B/FlightAware, live weather/NOTAM feeds, company documents) to produce Derived Operational Artifacts or otherwise enable Operational Use.

4.2 Data Scope Violations

• Accessing or using data for anyone other than the FCV user who authorized the app, except:
  • Aggregated, anonymized analytics explicitly approved by FCV for logbook-only insights.
• Building employer-, airline-, or dispatcher-facing tools that use individual user data without a separate written agreement with FCV.

4.3 Feature Duplication Without Value-Add

• Replicating FCV-native features and charging for them without clear, material added value, including:
  • Basic schedule viewing or notifications FCV already provides.
  • Native logbook export/sync flows (e.g., “FCV > LogTen” workflows that simply wrap existing FCV functionality) without meaningful enhancements (automation, cross-provider reconciliation, advanced analytics, etc.).

4.4 Brand and UX Misuse

• Presenting as an official FCV product, partner, or “Pro/Plus” SKU without written approval.
• Using FCV logos, trademarks, or confusingly similar names in your app name, icon, or domain.
• Hiding or minimizing required disclaimers.

4.5 Technical Misuse

• Storing FCV credentials or passkeys; scraping or MITM-ing FCV apps or websites.
• Client-side calls directly to the Logbook API (bypassing secure servers).
• Rate-limit abuse (e.g., ignoring 429 responses, aggressive polling beyond policy).

5. Branding & UX Requirements

To avoid brand confusion and clearly communicate scope:

5.1 Required Disclaimers (Exact Wording)

Partners must display all three of the following statements, verbatim:

• “Uses the Flight Crew View Logbook API. Not affiliated with Flight Crew View.”
• “For logbook purposes only. Not for flight planning or operational use.”
• “Requires an active Flight Crew View subscription (sold separately).”

5.2 Placement Requirements

The disclaimers must appear:

• Above the fold (no scrolling required) on:
  • Your primary marketing page for the integration or app.
  • The main pricing page for the product.
• Pre-OAuth / Pre-Connect Flow
  • On the screen where the user chooses to “Connect with Flight Crew View” (or similar).
  • In a visually clear location near the connect button or instructions.
• In-App Settings / Legal
  • Within an “About,” “Legal,” or “Data Sources” section accessible from the main app navigation.
• App Store Listings (if applicable)
  • Within the description on app store pages where the FCV integration is a core feature.

Failure to implement these placements is grounds for delaying or revoking Indie/Established access.

6. Pricing Transparency & Consumer Protection

Partners must maintain honest, clear, and accessible pricing:

Public pricing page

• Accessible without login, with:
  • Price amounts.
  • Billing interval (e.g., monthly/annual).
  • Any onboarding or setup fees.

Subscription details

• Clear statement of:
  • Auto-renew behavior (if any).
  • Trial length and what happens at trial end.
  • How to cancel before being charged.

Cancellation & Refunds

• A direct, reasonable cancellation path (no forced phone calls or email-only cancellation).
• An accessible refund policy page (even if refunds are rare).

No dark patterns

• No pre-ticked boxes adding paid options.
• No hiding core functionality behind ambiguous “upgrade” buttons.
• No misleading copy implying FCV ownership, endorsement, or requirement beyond logbook workflows.

7. Security & Data Handling (Minimums)

The controls in this section are:

• Required for all Indie and Established partners.
• Strongly recommended best practices for Hobbyist clients. FCV may not actively enforce every control at the Hobbyist tier, but reserves the right to require them (or an upgrade) if usage or risk increases.

At a minimum, all tiers (including Hobbyist) must not capture FCV credentials or passkeys and must use the documented OAuth-style authorization flow.

7.1 Authentication & Credentials

OAuth 2.0 only

• Use FCV’s OAuth-like flow as documented; no password or credential scraping.
• Passkeys are entered on FCV pages only; your app must never capture or store them.

Server-side only

• All /token/, /flights/, and /revokeToken/ calls must originate from your secure backend.
• No direct calls from mobile/web clients. This is required for Indie and Established tiers, but is good practice for Hobbyist tiers as well.

7.2 Token Handling

Storage

• Access and refresh tokens encrypted at rest (e.g., disk/database encryption + application-level access controls).
• Accessible only to systems and staff that require them (least privilege).

Rotation

• Always replace refresh and access tokens with the newest set returned by FCV.
• Treat any error or unexpected behavior as a potential token compromise and rotate accordingly.

Subject Binding

• Associate each token pair with exactly one FCV user_id.
• Prevent cross-account or cross-user access via token misuse.

7.3 Data Retention, Export, and Deletion

• Retain FCV-derived logbook data only as long as needed for the user’s chosen workflows.
• Provide:
  • User-initiated export (e.g., CSV, logbook export, or in-app data download).
  • User-initiated deletion of FCV-derived data.
• Document retention and deletion expectations in your Privacy Policy.

7.4 Breach Notification

• Implement reasonable monitoring for suspicious access or token abuse.
• If you detect or suspect unauthorized access to FCV tokens or FCV-derived data:
  • Contain, investigate, and revoke affected tokens.
  • Notify FCV at [email protected] within 24 hours of confirmation, with:
    • Scope of impact.
    • Actions taken.
    • Planned user communication.

7.5 Logging, Idempotency, and Rate Limits

Log:

• Authorization attempts (without storing passkeys).
• Token operations (success/failure).
• API calls metadata (timestamp, endpoint, status code) with no more PII than necessary.

Implement idempotent imports:

• Use fcv_flight_id or your own stable identifiers to safely re-run imports.

Implement backoff and retries:

• Respect 429 and 5xx responses with exponential backoff and hard caps.
• Do not hammer the API or ignore rate-limit headers.

Maintain compliance with:

• Per-end-user polling guidelines (e.g., once per day per user for automated sync).
• Documented per-minute rate limits and any tier-specific caps.

7.6 AI / LLM Data Handling (If Used at All)

If a partner uses AI/LLM Processing for permitted Logbook Workflows:

• The partner must disclose the use of AI in their Privacy Policy and in-app “Data Sources/AI” note.
• FCV tokens, refresh tokens, and authorization codes must never be sent to any AI provider.
• FCV-derived data shared with any third-party AI service must be data-minimized, and the partner must not use FCV-derived data to train models unless the user has explicitly opted in and it is permitted by law and the partner’s agreements.

8. Upgrade Criteria & Review Gates (Rewritten)

8.0 Baseline Maturity Gate (Indie and Established)

To reduce user risk, prevent brand confusion, and keep FCV support burden manageable, multi-user access (Indie or Established) requires baseline product maturity.

Applicants must satisfy Gate A to be eligible for Indie (multi-user) access.

If Gate A is not met, FCV may, at its sole discretion, offer Pilot Access only under Gate B (Section 8.3). Gate B is not a shortcut to Indie.

Gate A — Standard Eligibility for Indie (Multi-User)

An applicant must meet all of the following:

Public Availability (Two Platforms)

The application is publicly available in both:

• Apple App Store (iOS), and
• Google Play Store (Android).

Minimum Age

The application has been publicly available for at least 12 months (based on first release date or verifiable public availability).

Adoption Signal (Any One)

The application demonstrates adoption via at least one of the following:

• ≥ 50 combined public ratings/reviews across app stores, or
• Meaningful public user community footprint (e.g., active community forum/group with real engagement), or
• Other FCV-verified adoption indicator (at FCV discretion) that is difficult to fabricate and can be independently corroborated.

If any of the above are not satisfied, the applicant is not eligible for Indie access and remains eligible only for Hobbyist (self-only), unless FCV offers Pilot Access under Gate B.

Notes:

• FCV may require applicants to provide links/screenshots sufficient to verify public availability, age, and adoption signals.
• FCV may update thresholds over time to reflect ecosystem conditions.

Gate B — Pilot Eligibility (Pilot-Only, Not Indie)

If Gate A is not met, FCV may (at its sole discretion and based on bandwidth) offer Pilot Access only via Section 8.3. Pilot Access is time-limited, tightly scoped, and intended solely to validate basic safety, correctness, and user experience.

Pilot Access does not imply Indie approval. Promotion to Indie requires successful pilot completion and is at FCV discretion.

8.1 Hobbyist > Indie

The Hobbyist tier is intended for personal, self-only experimentation and use.

To be considered for Indie (multi-user) access, applicants must:

Step 1 — Meet Baseline Maturity Gate

• Satisfy Gate A in Section 8.0 (standard eligibility), or
• Be explicitly offered Pilot Access under Gate B / Section 8.3 (pilot-only).

Step 2 — Technical / Demo Requirements (Required)

• Working OAuth 2.0 flow using the Synthetic Test Dataset.
• Correct mapping and parsing of:
  • Flight identifiers (fcv_flight_id).
  • Deadhead vs operating legs.
  • Tail numbers (fcv_tail_number preferred).
• Time-zone handling demo:
  • Includes DST transitions and overnight flights.
• Idempotent import behavior: re-running sync does not duplicate flights.
• Export or handoff demonstration where applicable (e.g., CSV, logten://, PDF).
• A short live demo or video walkthrough of:
  • The sync process.
  • Idempotent behavior.
  • How your product provides clear, material value-add beyond FCV’s existing capabilities.

Step 3 — Security & UX (Required)

• Security note describing token storage, rotation, and access controls (least privilege).
• Logbook-only attestation (simple written statement).
• Required disclaimers implemented in marketing, pricing, and pre-OAuth / pre-connect screens.

Step 4 — Public Presence & Transparency (Required)

• Public website with:
  • Terms of Service.
  • Privacy Policy.
  • Clear description of the value-add beyond FCV’s native features.
  • Pricing transparency if commercial.

FCV may deny Indie access if the app’s primary integration is feature duplication without meaningful value-add, or if the integration increases operational-use risk, support burden, or brand confusion.

8.2 Indie > Established (Unchanged Eligibility, Clarified Relationship to Gate A)

To be considered for Established, the applicant must already meet Indie requirements (including Section 8.0 Gate A or a successfully completed pilot that led to Indie approval), and must demonstrate:

Production Stability

• Monitoring and alerting for API failures and high error rates.

Support & Operations

• Defined support process and response time commitments for end users.
• Documented incident handling process, including:
  • Communication templates,
  • Postmortems (for material incidents).

Compliance History

• No significant, unresolved violations of this policy.
• Timely remediation of any previous issues.

Scale Indicators

• Active user volume or growth that justifies higher limits.
• (Optional) Insurance/indemnity documentation for larger partners, if requested.

8.3 Pilot Allowlist Step (Rewritten: Default for Gate B)

FCV may offer a Pilot Allowlist as a controlled evaluation mechanism. Pilots are most commonly used for Gate B applicants (those that do not meet Gate A) and may also be used for Gate A applicants when FCV deems it necessary.

Pilot Terms (Default)

• Up to 10–25 named testers (real crew using their own FCV accounts).
• Duration: 30–60 days.
• Strict rate limits and tight global caps.
• No charging and no public marketing of the FCV integration during the pilot.
• Pilot must remain logbook-only and must not introduce Operational Use workflows.

Pilot Objectives

Used to validate:

• Real-world UX and support behavior.
• Data correctness across airlines and fleet types.
• Compliance with branding, operational, and security requirements.
• Responsible polling and rate-limit behavior (including backoff and idempotency).

Promotion Criteria (Pilot > Indie)

Promotion to Indie is at FCV discretion and generally requires:

• No policy violations during the pilot (especially no Operational Use).
• Reliable sync behavior (no persistent high error rates or abusive polling).
• Correct disclaimers placement across required surfaces.
• Demonstrated real demand measured via FCV-observed usage (e.g., distinct connected testers and retention), not solely applicant-provided screenshots.
• Clear value-add beyond FCV-native features.

FCV may extend a pilot, require remediation, or end the pilot without promotion.

9. Monitoring, Enforcement & Revocation

FCV reserves the right to monitor API usage for compliance:

Monitoring

• Aggregate metrics on rate-limit usage, endpoint mix, and error codes.
• Investigation of unusual patterns (e.g., aggressive polling, high error rates).

Violations & Strike Policy (example framework)

• Minor issues (copy/branding gaps, missing disclaimers, non-material rate overages):
  • Notice + remediation window (e.g., 90 days).
• Repeated or unaddressed minor issues:
  • Temporary throttling or suspension.
• Major issues (Operational Use, clear misrepresentation, security incidents):
  • Immediate suspension or revocation, subject to review.

Immediate Revocation

• Any Operational Use.
• Evidence of credential theft, token misuse, or malicious activity.
• Material misrepresentation of relationship with FCV.

Appeal Process

• Partners may email [email protected] with:
  • Description of the issue.
  • Remediation steps taken.
  • Request for reinstatement or reconsideration.
• FCV may, at its discretion, re-enable access under additional conditions.

10. Legal Clauses (not legal advice)

The following are short-form policy anchors and do not replace formal contracts:

Operational Use Prohibited

The FCV Logbook API may not be used for flight planning, dispatch, weather/NOTAM briefing, go/no-go decisions, or any other operational purpose.

AI Briefing Prohibited

The FCV Logbook API may not be used, directly or in combination with other sources, to summarize or generate briefs from dispatch releases, NOTAM/weather packets, MEL/CDL/performance materials, or any other Operational Documents, including via AI/LLM Processing. Such outputs are considered Operational Use and are grounds for immediate revocation.

User’s Own Data Only

Access is limited to flights for the FCV account that authorized your app, except where explicitly agreed in writing for aggregated, anonymized analytics or admin use cases.

Branding / Non-Affiliation

You must not hold yourself out as Flight Crew View, an official FCV product, or an exclusive partner unless you have a signed agreement explicitly granting such status.

Pricing Transparency

You must provide clear, honest pricing and cancellation terms without dark patterns, and you must not misrepresent FCV subscriptions or FCV’s role in your billing.

Security Minimums

You must implement reasonable technical and organizational measures to protect tokens and FCV-derived data, including encryption, least privilege, and incident response.

Audit & Kill Switch

FCV may audit your usage (at a reasonable level consistent with privacy policies) and may suspend or revoke access at any time to protect users, FCV systems, or regulatory obligations.

Indemnification (for commercial tiers)

Indie and Established partners may be required to indemnify FCV for claims arising from your product’s actions, representations, or security failures, as set forth in a separate agreement.

Change Management / Notice

FCV may update this policy and/or API behavior; where feasible, FCV will provide reasonable advance notice for breaking changes and updated requirements.

Termination

Either party may terminate access according to the FCV Terms of Service or applicable partner agreement. Upon termination, you must cease all API calls and delete or anonymize FCV-derived data as required.

11. Changelog & Versioning

Version	Date	Notes
1.1	Feb 27, 2026	Added AI/LLM definitions, operational-use restrictions, permitted AI logbook workflows, AI data handling requirements, and tightened upgrade criteria with Gate A/B and pilot-only rules.
1.0	—	Initial publication of the FCV Logbook API Access Policy.

Future updates will be published with versioned notes and, where applicable, migration guidance.

Appendix A — Developer Checklists

A.1 Hobbyist Checklist

• Using Synthetic Test Dataset for initial integration and testing.
• OAuth 2.0 flow implemented server-side only.
• Idempotent import logic using fcv_flight_id or equivalent.
• Time zone handling verified (including overnight flights).
• No Operational Use features implemented.
• No FCV credentials or passkeys stored or captured.

A.2 Indie Checklist (see Section 8.1)

• All Hobbyist items completed.
• Public site, Terms of Service, and Privacy Policy published.
• Required disclaimers implemented across marketing, pricing, and pre-OAuth screens.
• Clear value-add beyond FCV native features (documented for review).
• Security note prepared (token storage, access controls, rotation).
• Pricing page includes billing interval, auto-renew info, trial terms, cancellation path, and refund policy.
• Automated polling limited to once per day per user and within rate limits.
• A short live demo or video walkthrough.

A.3 Established Checklist (see Section 8.2)

• All Indie items completed.
• Monitoring and alerting for API errors, timeouts, and rate-limit events.
• Documented incident response plan and escalation contacts shared with FCV.
• Support SLAs defined for your users.
• (If applicable) Insurance/indemnity documentation available.
• Production metrics (uptime, error rates) collected and sharable with FCV upon request.