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) — CLIs, varios, and other browser-less devices.
- Personal API keys — for your own scripts; can't grant destructive scopes.
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 |
| 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 |
| 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 |
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.