What this is
we-fly exposes an OAuth 2.0-compliant REST API so external platforms (flight trackers, coaching tools, mobile apps) can upload IGC flights and read pilot data with explicit user consent.
Four credential flows are available:
- Server-to-server (client credentials): your backend acts on your own we-fly account.
- Authorization Code + PKCE: your app acts on behalf of any user who grants consent.
- Device code (RFC 8628): native mobile apps, CLIs, varios, and other browser-less devices.
- Personal API keys: for your own scripts; can't grant destructive scopes.
Shipping a native mobile app? Start with automated upload from a native app: it compares the device flow, personal keys, and the Leonardo protocol side by side.
All four end up presenting a Bearer token to /api/v1/* endpoints.
Want event push instead of polling? Register a webhook under your application: we'll POST signed payloads to your URL when a flight is uploaded, deleted, or other events you subscribe to.
Where to start
- Register an application or API key: /developer.
- Authorization server metadata:
/.well-known/oauth-authorization-server(RFC 8414: discover endpoint paths instead of hardcoding). - Machine-readable spec:
openapi.yaml: OpenAPI 3.1.
Partner documentation
| Document | Read when |
|---|---|
| Overview | First time integrating: concepts, base URL, conventions |
| Automated upload from a native app | You ship an iOS/Android/desktop app and want it to upload IGC flights automatically |
| Server-to-server (client credentials) | You own a backend that needs to sync data for accounts you control |
| User authorization (Authorization Code + PKCE) | You ship an app/website that wants to act on behalf of we-fly users |
| Device authorization grant | You ship a CLI tool, vario, or other browser-less device |
| Personal API keys | You want a personal token for your own scripts |
| Webhooks | You want event push notifications instead of polling |
| Scopes | Reference list of permissions |
| Instrument integration | You ship a flight instrument: tasks, waypoints, sites, screen layouts, live tracking, safety notifications, thermals, airspace |
| Endpoint reference | Reference list of HTTP endpoints, requests, responses |
| Errors | Mapping of HTTP statuses + error codes |
| Rate limits | Quotas, headers, retry behaviour |
| Usage telemetry | Per-application counters, error-rate definition, owner / admin views |
| Security expectations | What we expect partners to enforce on their side |
| IGC flight-recorder format | You produce or read .igc files: the upload format, B-record layout, interactive spec |
| OpenAir airspace format | You read or write airspace files: records, grammar, and an interactive spec |
| Saved airspace files | You pull the OpenAir files a pilot saved from the XC planner: private, kept 30 days, v1 or v2.1 |
| SeeYou CUP waypoint & task format | You produce or read .cup files: waypoint columns, task section, observation zones, interactive spec |
| Competition task formats | You produce or read task files: .xctsk, .fsdb, .tsk, .cup, and an interactive spec for each |
| Waypoint & route formats | You produce or read waypoint or route files: the three .wpt dialects, GPX, KML, and an interactive spec for each |
| Terrain elevation (SRTM / HGT) | You need ground elevation or AGL: the public DEM we use, how to decode it, and how to match our numbers |
Sixty-second example
# Server-to-server token
TOKEN=$(curl -s -X POST https://we-fly.cloud/api/oauth/token \
-u "wf_app_…:wf_secret_…" \
-d "grant_type=client_credentials" \
-d "scope=flights:read" | jq -r .access_token)
# Use it
curl https://we-fly.cloud/api/v1/flights \
-H "Authorization: Bearer ${TOKEN}"
RFC compliance
- RFC 6749: OAuth 2.0 Authorization Framework
- RFC 6750: Bearer Token Usage
- RFC 7009: Token Revocation
- RFC 7636: PKCE (mandatory for public clients)
- RFC 7662: Token Introspection
- RFC 8414: Authorization Server Metadata (
/.well-known/oauth-authorization-server) - RFC 8628: Device Authorization Grant (
/api/oauth/device_authorization)
Token theft detection follows RFC 6819 §5.2.2.3: refresh token rotation is single-use, and replay revokes the entire token chain for that user+app.
Status
The integration platform shipped in alpha.28. Endpoints under /api/v1/* and /api/oauth/* are part of the public contract; everything else is internal to the dashboard and may change without notice.
For partner support, reach out through the contact page.