callRecord.id no longer matches call.callChainId — how to link live calls to call records?

Hello Hello daraA, You’re correct: the behavior changed recently, and what used to work (matching call.callChainId from the live call to callRecord.id) no longer holds.

• Previously: callRecord.id often matched the callChainId from the live call object, so you could link them easily.
• Now: callRecord.id is its own unique identifier and does not equal callChainId or call.id. This is by design; the API team decoupled these IDs as part of recent updates to the callRecords API.
  
  Is there a stable property you can use?
  1. callChainId still exists in both the live call and the call record, but it’s no longer the primary key. Instead, it’s now intended as a correlation identifier for related calls (e.g., transfers, consults, or meetings with multiple legs).
  2. The callRecord resource includes id (unique per record) and still exposes callChainId for grouping. So you can:
  Capture call.callChainId during the live call.
  When you receive a callRecord notification or query /communications/callRecords, filter or match on callChainId instead of id.
  Reference Document-
  1.callRecord resource type - Microsoft Graph v1.0 | Microsoft Learn
  2.Microsoft Graph Call Records API FAQ - Microsoft Graph | Microsoft Learn
  
  
• callChainId is not guaranteed to be globally unique—it’s unique per chain of related calls, not per individual call leg. If you only need to link “this live call session” to its record, and you know there’s no transfer/merge scenario, it’s safe enough.
• If you need absolute uniqueness, you’ll have to maintain your own mapping table keyed by call.id → callChainId → callRecord.id once the record arrives.
• Meeting URL (joinWebUrl) is unreliable for recurring meetings, as you noted.