Skip to content

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.

┌──────────┐ ┌──────────┐ ┌──────────┐
│ 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 │
│ │<──────────────────│

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.

Pilots can disconnect at any time from the Skyden app. When they do:

  • GET /v1/pilot-totals returns 404 PILOT_NOT_FOUND for that pilot_id.
  • GET /v1/pilot-totals/batch silently 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.