Linking flow
Every partner integration starts with linking. The pilot is the source of consent. They generate a token in the Skyden app, paste it into your app, and your server redeems it for a permanent pilot_id.
Sequence
Section titled “Sequence”┌──────────┐ ┌──────────┐ ┌──────────┐│ Skyden │ │ Your App │ │ Skyden ││ (Pilot) │ │ (Server) │ │ API │└────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ 1. Generate code │ │ │ (SKDN-XXXX...) │ │ │ │ │ │ 2. Paste code │ │ │──────────────────>│ │ │ │ │ │ │ 3. POST /v1/link │ │ │──────────────────>│ │ │ │ │ │ 4. pilot_id │ │ │<──────────────────│ │ │ │ │ │ 5. GET /v1/pilot- │ │ │ totals │ │ │──────────────────>│ │ │ │ │ │ 6. Flight data │ │ │<──────────────────│Storing the pilot_id
Section titled “Storing the pilot_id”The pilot_id is opaque and permanent for this connection. Store it alongside your internal user record. You’ll pass it on every subsequent request.
If the pilot disconnects and later reconnects, a new pilot_id is issued. The old one is gone; store the new one and discard the old.
Disconnection
Section titled “Disconnection”Pilots can disconnect at any time from the Skyden app. When they do:
GET /v1/pilot-totalsreturns404 PILOT_NOT_FOUNDfor thatpilot_id.GET /v1/pilot-totals/batchsilently omits the disconnected pilot from the response, with no per-pilot error.
Compare the pilot_ids you requested against the ones returned to detect disconnections in batch calls.