Linking used to be a one-shot effort: you started the link and waited until the asset was created. This could take a long time, or simply fail — and either way, you had no way to confirm whether the session had actually failed, let alone why. That made it hard to know whether a retry was worth it or the failure was permanent.
This is now solved with the introduction of link sessions. The link endpoint now includes a sessionID in its response, which you can poll via GET /systems/{system_id}/linksessions/{session_id} to track its progress.
Status
The response carries an aggregate status for the whole session, plus a results array with one entry per requested asset type:
pending— still in progress; keep pollingcompleted— finished successfully; the result carries the createdassetIdfailed— finished unsuccessfully; the result carries afailureKind(see API docs for possible values)expired— no completion arrived within the session’s TTL; start a new link attemptsuperseded— replaced by a newer link attempt for the same system
The session-level status is derived from the per-asset-type results: pending while any asset type is still unresolved, completed only once every asset type succeeded, and failed if at least one of them failed.
Why multiple results?
A single link call can request several asset types at once (e.g. assetTypes: ["EV", "EVSTATION"]). Each asset type is tracked independently, so results contains one entry per requested asset type with its own status and outcome, instead of a single outcome for the whole call.