API Changelog

Track changes, improvements, and updates to the Virtual Performance Tool API.

Takeoff Performance — Selectable Graphic Format

Release Date: August 2026

New

• Client-selectable image format. The Takeoff Performance request now accepts an imageFormat string ("svg", "png" or "jpg", default "svg") controlling which raster format is generated for graphic, cduGraphic and rtoGraphic. svg is always produced regardless of the request — it's cheap and is the canonical source the other formats are rendered from — while png/jpg now require a genuine Imagick rasterization pass and are only generated when explicitly requested, since most calculations are only ever displayed as SVG and never need a raster export.

Takeoff Performance — RTO Graphic

Release Date: August 2026

New

• Rejected-takeoff (RTO) graphic. The Takeoff Performance response now includes an rtoGraphic (svg, png, jpg), always generated since it only needs V1 and the calculated ASDR. It plots the estimated accelerate-stop distance for a reject initiated at V1, 100kt and 80kt on the same runway/exits/windsock layout as the existing takeoff distances graphic. The ground/air brake cooling time for each speed (from brakeCoolingSchedule) is shown alongside the distance only when the aircraft profile has landing.brakeCooling.isBrakeCoolingAvailable set. The 100kt/80kt distances are estimated from the calculated V1 ASDR using estimateASDRAtSpeed(asdr, v1, targetSpeed) = asdr × (targetSpeed / v1)², scaling by the kinetic-energy ratio between the two speeds.

Checklist Management API

Release Date: July 2026

New

• New Checklist Management API: checklistList, checklistGet, checklistSave, checklistDelete and checklistRate for creating, editing, deleting and listing user, virtual-airline and community checklists.
• Built-in default/generic checklists (previously only reachable through an aircraft profile's checklists.file) are now individually addressable via a stable default:{folder}:{file} id, and can be listed, rated, and cloned into a user's own checklist.
• Community sharing: checklist owners can opt in with shareCommunity, and community + default checklists can be rated 1–5 stars.
• Aircraft profiles can now reference any checklist — built-in or custom — by a single stable checklistId via checklists.checklistId, resolved through the same code path used by the new endpoints. Access to private checklists is enforced server-side.
• See Checklist JSON Format for the schema shared by every checklist, wherever it is stored.

Version 1.3.0

Release Date: January 2026

Bug Fixes

• Subscription plan-change handling rewritten. Three coupled fixes for upgrades and downgrades through 2Checkout:
  • Upgrading (e.g. Lite → Pro) no longer leaves the previous plan’s row Running in the database. A new supersede pass runs after every CREATE / plan-change event and marks all other Running / Paused rows of the same user as Superseded, guaranteeing exactly one active subscription per user.
  • Downgrades that arrive only as an LCN (the typical 2Checkout behaviour — no ORDER_CREATED IPN because there is no charge) are now detected. When an STATUS=ACTIVE LCN carries a changed NEXT_RENEWAL_PRICE the dispatcher calls GET /subscriptions/{ref}/ on 2Checkout, reads the current PCODE, resolves it to a local product and routes the event through the plan-change handler so the subscriptions row is actually updated.
  • Downgrades are now re-prorated server-side. Because 2Checkout does not refund the unused portion of the more expensive plan, we extend date_end using remainingValue / newDailyRate so paid value carries over (capped at 1095 d). See Plan Change Server Behaviour.
  New files: api/Subscriptions/PlanChangeService.php and Database/migrate_subscription_status_width.php (widens subscriptions.status from VARCHAR(10) to VARCHAR(20)). Run the migration once: php Database/migrate_subscription_status_width.php.
  
  Hotfix mirrored to legacy site. Until the 2Checkout IPN/LCN webhook URLs in the Merchant Control Panel are switched to the new api.virtualperformancetool.com/api/webhooks/2checkout/… endpoints, the same three-bug fix has also been applied to upgradeSubscriptionIPN() in the legacy marketing site (assets/php/subscriptions/2checkout/dataLibrary.php) so production IPNs receive the fix immediately.

New Features

• Flight Data history (audit log). A new append-only flight_data_history table records every insert / update / delete performed via flightDataSave and flightDataDelete, including the full payload snapshot and the actor’s userId. Exposed via the new flightDataHistory endpoint — supports a metadata-only mode (default) or full payload streaming (includePayload: true) so clients can implement “who changed what” UI and undo-last-change without storing snapshots locally.
• OFP cross-account sharing. Four new JWT-authenticated endpoints — ofpShare, ofpShareList, ofpShareAccept, ofpShareRevoke — let an OFP owner invite another VPT account to view or co-edit a stored flight and its Flight Data. Invites can be issued by email, by short share-code, or by QR deep-link (vpt://share/{token}) which the client renders from the returned qrPayload. Two permission levels: view (read OFP + Flight Data) and edit (also Flight Data writes); OFP delete stays owner-only. Centralised in a new OfpAccessService used by all OFP and Flight Data handlers. See OFP Sharing.
• Flight Data store. Four new JWT-authenticated endpoints — flightDataList, flightDataGet, flightDataSave, flightDataDelete — let the client persist any free-form payload attached to an imported OFP (journey log, fuel log, post-flight notes, …). The server never inspects the payload, so the schema can evolve entirely client-side. Each entry is keyed by (userId, ofpId, dataKey) and carries a monotonic version + updatedAt; saves include an optional expectedVersion and lastDownloadedAt for optimistic locking. On a stale write the API returns 409 VERSION_CONFLICT with the server's current copy in current, so the client can offer a Cancel / Download latest / Override dialog. See Flight Data.

Breaking Changes

• All API response keys now use camelCase naming convention (e.g., apiVersion, calculationPossible, maxTow)
• Previous PascalCase and UPPER_CASE response keys have been converted (e.g., RTOW → tow, MaxRTOW → maxTow)

Improvements

• User payload exposes structured subscription state. The login response (and every endpoint that returns the user object) now includes a user.subscription object at MEDIUM and FULL access levels — title, level, status, expiry, daysRemaining, isActive, isExpired, isTrial, isPaused, isAutoRenew, paymentMethod and a capabilities sub-object (isNotam, isNnc, isMel, isCdl, isCommercial, isFleetDatabase, maxCalculation). See Authentication » The subscription object.
• Embedded preview block on every subscription. The user.subscription object now carries an embedded preview sub-object that signals when the user is experiencing the API as a limited Pro preview (no real subscription, expired subscription, or otherwise inactive). When subscription.preview.active is true the API enforces the allowedAirports restriction server-side. Users with no real subscription receive a synthesized PREVIEW subscription built from product id 3 (VPT Pro Demo) so the client can render the full Pro UI. See Authentication » The embedded preview block.
• User preferences restructured. The userPreferences response now groups settings by feature area (defaultAircraftOnStartup, performance containing takeoff and wb, export, simbrief, efb, weather) and exposes a new top-level efb object with module toggles (enableEFB, modules.briefingNavlog, modules.checklist, modules.library, modules.tools) plus an opaque toolsOptions JSON store synchronized across the user's clients. A new top-level weather group combines weather.display with weather.notification (opt-in to the new weather notification stream).
• Adaptive partial save. saveUserSettings now writes only the keys present in the request payload — missing keys leave their DB columns untouched. Unknown keys are silently ignored (forward-compatible). saveUserSettingsMobile is kept as an alias.
• Server-enforced settings lock. settingsLocked is now admin-only: saveUserSettings rejects writes when set, and any attempt to set or unset the flag through the user-facing endpoint is silently dropped. Only the admin save path can toggle the lock or bypass it.
• Runway exits always drawn. landing.displayRunwayExits is no longer consulted by the landing performance graphics in API 1.3.0 — exits are always rendered when available.
• userId-based queries. Internal preference lookups now join on a new user_preferences.user_id column (UNIQUE FK to users.id) instead of api_key. Existing rows are backfilled by the 012_user_preferences_refactor.sql migration; the api_key column is preserved for legacy API versions.
• Clean camelCase query names throughout the API (e.g., "airport" instead of "get_airport", "allowedAircrafts" instead of "allowed_aircrafts", "apiVersion" instead of "get_api_version").
• All request parameters use camelCase natively (e.g., userRegistration, virtualAirline, requestType)
• Standardized subCalculation values: OPTIMUM, FIXED_DERATE, WINDSHEAR, MAX_RTOW
• Fixed RTOW+OPTIMUM calculation logic to use the first actual rating when rating is set to OPTIMUM
• New Performance API architecture with improved error handling

Deprecated (kept in DB for legacy API versions)

• displayDemoAircraft, landing.displayRunwayExits, disclaimer.*, visualCustomization.*, export.exportEmail, export.exportURL are no longer returned by API 1.3.0. They remain in the user_preferences table (with COMMENT 'DEPRECATED in API 1.3.0') so that older API versions continue to behave identically.
• The exportEmail dispatch case no longer reads a secondary email from preferences. Exports are sent to the user's primary users.email only.

Version 1.2.9

Release Date: December 2025

Initial public release of the Virtual Performance Tool API with basic takeoff and landing performance calculations.