### Summary We'd love XCTrack to be able to **automatically upload a flight to We-Fly right after the pilot lands**, the same way it already auto-posts to XContest. We-Fly ([we-fly.cloud](https://we-fly.cloud)) is a paragliding logbook and analytics platform, and this is one of the integrations our users ask for most often. We're writing as the We-Fly dev team — happy to do the heavy lifting on our side (public API is already live and RFC-compliant OAuth 2.0), and to support you however is easiest. ### Why (user demand) This request comes straight from pilots. We regularly get messages from We-Fly users who already fly with XCTrack asking for a "post to We-Fly on landing" toggle, so they don't have to pull the IGC off the phone/vario and upload it by hand. It's the single most-requested integration in our community. We're not going to throw fake numbers at you — just: it's a recurring, frequent ask, and XCTrack is the flight computer most of them use. Right now the workflow is: land → grab the .igc → open a browser → upload. XContest users don't do that dance, and pilots keep asking why We-Fly can't be in the same "auto-post targets" list. ### What we're asking for A "We-Fly" entry in XCTrack's existing auto-upload / livetrack targets, mirroring the XContest flow: - Pilot connects their We-Fly account once (OAuth or a pasted API key). - On landing, XCTrack POSTs the recorded IGC to We-Fly. - Ideally the same "auto-upload after landing" checkbox UX pilots already know. ### How it could work technically The upload itself is a single authenticated POST — no We-Fly-specific SDK required. **Endpoint** ```http POST https://we-fly.cloud/api/v1/flights/upload Authorization: Bearer <token> ``` - Scope required: `flights:write` - Body — either works, pick whichever is easiest in XCTrack: - `multipart/form-data` with a `file` field, **or** - `application/octet-stream` with the raw IGC as the body (optional `X-Filename` header). This one is probably the least code for you. - Max IGC size: ~3 MB. - Response: `201 Created` for a new flight, `200 OK` if the flight was already there (dedup is by content hash), body `{ "data": { "hash", "fileName", "isNew" } }`. Uploads are **idempotent**, so a retry after a flaky-signal landing won't create duplicates — safe to just resend. **Authentication — a few options, in rough order of "nice for a mobile app":** 1. **Device Authorization Grant (RFC 8628)** — probably the best UX for a flight computer. XCTrack shows a short code, the pilot opens `we-fly.cloud` on any device, types the code, done. No embedded webview, no redirect handling on the phone. 2. **Authorization Code + PKCE (RFC 7636)** — the standard mobile/public-client flow if you'd rather do an in-app browser redirect. 3. **Personal API key** — the simplest possible path: the pilot generates a `wf_key_…` token in their We-Fly developer dashboard and pastes it into XCTrack. Great for a v1 / MVP. (API keys can upload but can't delete, by design.) Our whole API is standards-based OAuth 2.0 — RFC 6749, PKCE (7636), device flow (8628), metadata discovery (8414), revocation (7009), introspection (7662) — so you can reuse whatever OAuth machinery you already have. Endpoint paths are discoverable at `https://we-fly.cloud/.well-known/oauth-authorization-server` rather than hardcoded. ### What we'll do on our side - **Register + approve the XCTrack OAuth application** so it can act on behalf of any We-Fly user (approved apps aren't limited to read-only / owner-only the way pending ones are). - **Adjust the API if something about the current shape doesn't fit XCTrack's uploader** — extra header, different content type, whatever makes your side cleaner. Happy to iterate. - Provide test accounts and a direct contact for the integration. ### Documentation All public, no login required: - API overview & getting started: <https://we-fly.cloud/doc/api> - Concepts / base URL / conventions: <https://we-fly.cloud/doc/api-overview> - Device code flow (RFC 8628): <https://we-fly.cloud/doc/api-device-code> - Authorization Code + PKCE: <https://we-fly.cloud/doc/api-user-authorization> - Personal API keys: <https://we-fly.cloud/doc/api-keys> - Scopes reference: <https://we-fly.cloud/doc/api-scopes> - Endpoint reference: <https://we-fly.cloud/doc/api-endpoints> - OpenAPI 3.1 spec: <https://we-fly.cloud/doc/openapi.yaml> - Developer dashboard (register apps / keys): <https://we-fly.cloud/developer> Thanks for building XCTrack — it's what a lot of us fly with. If a "post to We-Fly on landing" option is something you'd consider, we're glad to help make it painless. Fair winds.