Delay in getting meeting transcript via graph api using application credentials after meeting ends

Question

Delay in getting meeting transcript via graph api using application credentials after meeting ends

Sushil Dangi 0

Delay in getting meeting transcript via graph api using application credentials after meeting ends. Once meetign ends, after 20 mins we are seeing transcript via graph api even though file is available under chats in teams app. is there any documnet which explains this ? how long it takes usually on an average for 30 - 60 mins meeting. Also pls provide any relevant details.

0 comments

1 answer

Your answer

Answer 1

Demi-N 20,075 Microsoft External Staff Moderator

Hello Sushil Dangi,

Good day! Welcome to Q&A forum.

You’re absolutely right in observing that the transcript file often appears in the Teams chat interface noticeably earlier than it becomes available for programmatic access. We’ve investigated this and can confirm that this is expected behavior within the Microsoft 365 ecosystem.

Here’s a simple breakdown of why this happens:

Initial Processing: Once a meeting ends, Microsoft begins processing the audio to generate the transcript. Making this file visible in the Teams chat for users is a high-priority, initial step, which is why you see it so quickly.
API Availability: A separate, secondary process then makes that same file available to applications like ours through the Graph API. This step, which involves indexing and updating, naturally takes additional time.

Essentially, there is a built-in delay between when a transcript is ready for human viewing in the chat and when it's ready for programmatic retrieval by our application. While this behavior is by design, we recognize that faster access would be ideal, and we appreciate your patience as we work within the constraints of the Microsoft 365 platform.

Regarding the specific timing, Microsoft does not provide a fixed Service Level Agreement (SLA) for this. The delay can vary based on factors like meeting duration and current load on Microsoft's servers. A delay of 5 to 30 minutes for a typical meeting is quite common, so the 20-minute timeframe you experienced is well within the expected range.

To ensure we reliably retrieve the transcript, our system is designed to handle this variable delay. Once a meeting is over, our application will periodically check with Microsoft's API until the file is confirmed to be available. This ensures we can process your transcript as soon as it's ready.

We truly appreciate your understanding and continued partnership. If you have any further questions or concerns, please don’t hesitate to reach out. We’re here to help.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment”.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Sushil Dangi 0 Reputation points

2025-07-23T06:29:53.87+00:00

Thanks Demi-N. Is it the same behaviour with communications/callrecordings api. Once meeting ends its taking 20 to 45 mins to appear in callrecordings api response. is there any workaround to get it sooner? or any alternative of this api is available which provides all meetings including recurring alogn with participants data (not invitees) within a particular duration?
Demi-N 20,075 Reputation points Microsoft External Staff Moderator

2025-07-23T08:47:03.4966667+00:00
Hello @Sushil Dangi

Thank you for your follow-up and for confirming the behavior you're seeing with the communications/callrecordings API. You are correct; this delay is expected behavior for this API as well, as it follows the same asynchronous post-meeting processing pipeline.

To be direct, there is currently no workaround to accelerate the backend processing on Microsoft's side. This delay is inherent to the service as it needs time to properly process, index, and finalize all meeting data.

However, the most efficient approach is not to speed up the process itself, but to optimize how you are notified when the data is ready. For this, we strongly recommend using Change Notification Subscriptions on the callRecords resource.

For post-meeting analytics, communications/callrecordings is the definitive API to get a detailed report, including the list of actual participants.

Other APIs, such as calendar/events, are excellent for listing scheduled meetings (including recurring ones) but they can only show you a list of invitees, not who actually attended.

To achieve your goal, the best practice is to combine these APIs:

Use the calendar/events API to retrieve a list of all scheduled meetings within your specified duration.

Use a subscription on communications/callRecords to receive a notification for each completed meeting. Once you get a notification, you can then query the specific callRecord to get the rich details you need, including the participant list.

In summary, while there isn't a single API that provides this data in real-time, the combination above is the most robust and recommended architecture.

If your business requirements strictly demand real-time transcription, the path would be to explore a different architecture using Azure Communication Services (ACS). This is a more advanced solution for building custom communication experiences. To help you evaluate this option, here are the main considerations:

Advantages:

Real-time Transcription: You receive the transcript text almost instantly as the conversation happens.

High Flexibility: You gain complete control over the entire process, from how the bot behaves to how the transcript data is handled.

Considerations:

Increased Complexity: This requires significant development effort to build, deploy, and manage a custom application and its infrastructure.

Usage-Based Cost: Costs are incurred based on the active usage of both Azure Communication Services and the Azure AI Speech service, which may be higher than using the Graph API.

Unofficial Transcript: The transcript is generated by your application, not the official one created and stored by Microsoft Teams.

I hope this detailed explanation clarifies the available options. Please let me know if you have any more questions.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment”.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Sushil Dangi 0 Reputation points

2025-07-30T13:48:24.2+00:00

thanks Demi-N. there is one more query on this webhook. If we join without host then this webhook is not getting triggered. is it correct functionality or am i missing anything? With host in meeting, yes its getting triggered.
is there any other webhook which triggers even if host does not join and when callrecord/transcript info is ready? pls suggest.
Demi-N 20,075 Reputation points Microsoft External Staff Moderator

2025-07-30T14:57:43.4633333+00:00
Hello @Sushil Dangi

You are correct. The behavior you are observing, where the callRecords webhook does not trigger if a host never joins the meeting. This is indeed the expected functionality of the Microsoft Graph API and the underlying Teams platform. This is not an error in your configuration.

In Microsoft Teams, a meeting session only officially starts when the host or an authenticated user from the organizing tenant joins. If no host joins, participants remain in a "lobby" state, and the meeting is considered never started. As a result, no callRecord is generated, and the webhook tied to callRecords does not trigger.

Currently, there’s no alternative webhook that can detect meetings where the host is absent. The callRecords webhook is designed to reflect officially started sessions only.

To address this, we recommend:

Enforcing a business rule that a host or delegate must join any meeting requiring data capture.

Implementing fallback logic in your app to flag meetings without callRecords for manual review or automated handling.

I realize this might not be the answer you were hoping for, as it confirms a platform limitation. However, I hope this detailed explanation provides the clarity you need to design a resilient architecture for your application.

Your in-depth questions are incredibly valuable. Please let me know if you have any further architectural considerations you'd like to discuss.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment”.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Sushil Dangi 0 Reputation points

2025-07-30T16:30:58.82+00:00

Hi @Demi-N but i could see the callrecord for meeting i attended without host in this api
communications/callRecords. from here using joinweburl i fetched meeting details also. only webhook is not triggered.

anything which notifies when transcript is ready with callrecordid and joinweburl information? or any other webhook after the call with these details please?
Demi-N 20,075 Reputation points Microsoft External Staff Moderator

2025-07-31T10:58:12.6066667+00:00
Hello @Sushil Dangi

You are right. A callRecord can indeed be generated even if a host does not join the meeting, but the change notification webhook for its creation does not get triggered. My previous explanation was based on the more common behavior, and I appreciate you bringing this specific edge case to my attention.

The process that generates the callRecord after a session ends and the process that fires the created event for the webhook have different activation triggers. The webhook is likely tied to the "official" meeting start event (which requires a host to join), while the callRecord itself is generated if any participant activity occurs, regardless of the host's presence. This appears to be a limitation of the current webhook implementation for this specific scenario.

Unfortunately, there is no alternative webhook provided by Microsoft Graph that specifically notifies you when callRecords are created from host-less meetings.

However, you can build a robust solution by implementing a hybrid architecture to handle all cases reliably. Since you cannot rely 100% on webhooks to cover this edge case, we recommend combining webhooks with a scheduled fallback mechanism.

1. Primary Method: Use Webhooks (For Most Cases): Continue using your existing change notification subscription on /communications/callRecords. This remains the most efficient method and will successfully cover the majority of your meetings (i.e., all meetings where a host or authenticated delegate joins).

2. Fallback Method – Scheduled Polling:

Use the calendar/events API to list meetings that ended recently.

Compare with webhook notifications received.

For meetings without notifications, query callRecords directly using joinWebUrl.

In summary, this hybrid model gives you the best of both worlds: the real-time efficiency of webhooks for most meetings, and the reliability of a scheduled check to ensure you capture the data from the host-less edge case.

Thanks again for your detailed investigation. Let me know if you'd like help designing the polling logic or exploring other architectural options.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment”.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.