Read a support session by id

Support-session alerts provide bounded facts immediately. When you need the operator's stated reason, fetch the one session whose grantId you already hold:

curl https://api.example.yekar.ai/api/partner/v1/support-sessions/00000000-0000-4000-8000-000000000040 \
  -H 'Authorization: Bearer ykt_eyJhbGciOiJIUzI1NiIsImtpZCI6InB0ay0xIn0.eyJzdWIiOiJleGFtcGxlIiwiZXhwIjo0MTAyNDQ0ODAwfQ.ZXhhbXBsZS1ub3QtYS1yZWFsLXNpZ25hdHVyZQ'

The ykt_ value is an obviously fake example. The response contains:

{
  "grantId": "00000000-0000-4000-8000-000000000040",
  "orgId": "00000000-0000-4000-8000-000000000010",
  "mode": "safe_write",
  "escalationCategory": null,
  "reason": "Investigate the failed customer refund flow",
  "escalationReason": null,
  "startedAt": "2026-08-14T06:00:00.000Z",
  "endedAt": "2026-08-14T06:14:00.000Z",
  "actionCount": 2,
  "impactCounts": { "configuration": 2 }
}

There is deliberately no collection or history endpoint on the machine API. A held grant id authorizes only an id-addressed lookup within the platform represented by the leased token. A foreign, detached, plain, or nonexistent target returns the same not-found response.

The push/pull split keeps free-text reasons out of webhook infrastructure while preserving precise transparency when an authenticated operator asks for a known session.