Does LiveKit support to get multiple participants for livekit server sdk?

Thanks for reaching out, Jasmeet. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

but listParticipants give me all particpant of room which cause overhead for me i want to get only specific list by providing list of identity

Thanks — I’m responding to your point about avoiding the overhead of

listParticipants()

and instead returning only a specific set of participants by providing a list of identities. Short answer: There is no server-side API to fetch multiple participants by passing a list of identities in one call.

listParticipants()

returns all participants for a room, and filtering by identity must be done on the application side. What you can do instead (options): • Use

getParticipant()

for individual lookups ◦ If you need a small number of identities, call

getParticipant()

per identity. This avoids retrieving the full list but does require one request per identity. • Retrieve all participants once and filter client-side ◦ Call

listParticipants()

and filter the returned list to the identities you need. This is simple but can be heavy for very large rooms. • Maintain a server-side cache keyed by identity and update via events/webhooks ◦ Subscribe to room events (participant_joined / participant_left) and keep a cache of participants you care about. Then lookups are cheap and you avoid repeated full

listParticipants()

calls. • Combination approach for efficiency a. On room start, call

listParticipants()

to prime your cache. b. Use webhooks/events to keep the cache current. c. Use

getParticipant()

for occasional checks when cache misses occur. If you tell me: • which server SDK/language you’re using (Go, Python, Node, Ruby, etc.), and • whether your use case is a few identities per request or large batches (hundreds), I’ll give a concrete code example and a recommended pattern (e.g., batching

getParticipant()

calls, cache design, or webhook wiring) tailored to your setup. Sources: server-sdk-ruby | livekit/livekit_composite | DeepWiki | server-sdk-js | livekit/livekit_composite | DeepWiki | SIP Lifecycle Management Agent | LiveKit Documentation, with interactive elements

i am using node server sdk if the list of participant is more than 1000 then it make unnecessary load on my backend server. which is not a good approach

Thanks — I see you're using the Node Server SDK and are worried about the cost of calling

listParticipants()

in rooms with 1,000+ participants. You’re right to avoid fetching the entire list repeatedly; that will cause unnecessary load. Quick facts: • The Node Server SDK does not support a single API call to fetch multiple participants by a list of identities. • You can fetch a single participant with

getParticipant()

, but that is one request per identity. • For very large rooms, LiveKit can run in Livestream Mode where clients only see publishers; the server still has the full participant list. Recommended, scalable approaches (choose one or combine): 1) Maintain a server-side cache updated by room events/webhooks (best for high scale) • On startup or when joining a room, prime the cache once (you may call

listParticipants()

one time). • Subscribe to participant events (webhooks or server events) like

participant_joined

and

participant_left

to keep the cache up to date. • For each request, look up the specific identities in your cache (fast, no repeated full-list calls). • Occasionally reconcile the cache (periodic full

listParticipants()

or background sync) to recover from missed events. 2) Use

getParticipant()

for small batches (good when you only need a few identities per request) • If most requests ask for a handful of identities (e.g., < 10), call

getParticipant()

per identity in parallel. • Add a short in-memory TTL cache to reduce repeated lookups for the same identities. 3) Hybrid: cached index + on-demand

getParticipant()

for misses • Keep a lightweight cache of active identity → participant mapping. • On cache miss, call

getParticipant()

and update the cache. • Periodically refresh or reconcile to avoid stale data. 4) Leverage Livestream Mode if applicable • If your use case involves many passive viewers, enabling Livestream Mode reduces what clients receive. However, you still need server-side access to the full list — so combine Livestream Mode with a server cache. Node.js-specific example patterns A) Event-driven cache sketch (webhook or RT server events) • Use an in-memory map or Redis keyed by room + identity. • On

participant_joined

event: add/update cache entry. • On

participant_left

event: remove entry. • For requests: read from cache; fallback to

getParticipant()

if missing. B) Parallel getParticipant calls with short TTL cache • Use Promise.all to parallelize

getParticipant()

for the identities requested. • Wrap results in a short-lived cache (e.g., 30s–1m) to avoid hammering the server. Next question so I can give exact code: • Do you already receive room events/webhooks, or would you be able to enable them? • Typical request pattern: how many identities are you fetching per request (e.g., 1–5, 10–50, or hundreds)? Tell me those two details and I’ll provide a concrete Node.js code example (cache+webhook or parallel

getParticipant()

with caching) tailored to your traffic pattern. , with interactive elements