QoS Data Empty Most of the Time

The https://api.zoom.us/v2/videosdk/sessions/{sessionId}/users/qos endpoint seems to be returning data very inconsistently. We are attempting to use this during live sessions. Most of the time, the data looks like this:

        {
          "date_time": "2026-03-24T20:00:00Z",
          "audio_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": ""
          },
          "audio_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": ""
          },
          "video_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "video_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "as_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "as_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "cpu_usage": {},
          "cpu_pressure_level": {},
          "wifi_rssi": {}
        }

Sometimes, a few of the fields will return data.

I’ve seen previous threads where it was mentioned that this data does not return in the first minute of a session. This is happening long after the first minute. We also do have 2 users in the session, both with mic and camera on.

Is there any way to increase the quality of the quality of service data?

Hi @Jon-L
Thanks for reaching out to us .
I am happy to escalate this so our Engineering team can take a closer look.
Would you be able to share a tracking ID found in the response headers of your request

Thanks Elisa,

Here is a session with the issue: aF5NbxtaR2mnQ3G0BPgBzA==

Here is a tracking ID for one of the calls: v=2.0;clid=aw1;rid=WEB_97771c8f1601ec1a4e9d3bf917c0138d

Thanks @Jon-L
I escalated this to our Engineering team and will get back to you once I have an update
( ZSEE-198809 internal ticket number for reference)

Hi Elisa,

Is there any word on what we’re seeing here?

Thanks.

Hi @Jon-L
I just heard back from the team and they mentioned that there is a 1-2 minute delay in writing QOS data to the database. Consequently, if you call the API while data is still being processed, you may receive empty results.

Please retry their API calls after a 2-minute interval to ensure data retrieval.

Hello again Elisa,

Apologies for the slow reply. My team had other priorities that needed to be addressed. We’re back to working on this.

I ran this session for over 10 minutes: Bvi6mmVWQaizcosJ8FTVwg==

Again two participants were in the session and both cameras and mics were on. Yet I’m still often receiving QoS data responses that looks like this:

{
          "date_time": "2026-04-30T20:59:00Z",
          "audio_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": ""
          },
          "audio_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": ""
          },
          "video_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "video_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "as_input": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "as_output": {
            "bitrate": "",
            "latency": "",
            "jitter": "",
            "avg_loss": "",
            "max_loss": "",
            "resolution": "",
            "frame_rate": ""
          },
          "cpu_usage": {},
          "cpu_pressure_level": {
            "system_min_cpu_pressure_level": "normal",
            "system_avg_cpu_pressure_level": "normal",
            "system_max_cpu_pressure_level": "normal"
          },
          "wifi_rssi": {}
        }

Here is the ID associated with that last response: v=2.0;clid=aw1;rid=WEB_3fbf6920f48c6f4543abb80a148728e0

This was happening well over 2 minutes, can the team please look into this further?

Just following up. Can we please get assistance with this?

@elisa.zoom

I wanted to provide additional detail because we’re still consistently reproducing this issue.

We are calling the /videosdk/sessions/{sessionId}/users/qos endpoint more than 10 minutes after session start, with:

  • 2 active participants

  • both cameras enabled

  • both microphones enabled

  • active audio/video transmission throughout the session

However, the response frequently still contains mostly empty QoS fields.

The “1 - 2 minute processing delay” explanation does not appear to match what we are observing.

Could engineering help clarify:

  1. Which specific QoS fields are expected to populate during an active live session?

  2. Are there known limitations for live-session QoS retrieval?

  3. Are there account settings, SDK versions, session types, or regional infrastructure factors that affect QoS availability?

  4. Is there anything else we should be aware of trying to use this feature?

We can provide any other information as needed to help diagnose what’s going on here.