Web player groups
Use Web player groups to give viewers one page for switching between approved language feeds, camera angles, or replay variants.
Choose this whenSeveral existing players need one viewer page for language, angle, or replay switching.
Use another module whenUse Web Players to create and verify each underlying playback endpoint first.
/api/vod-group/createBefore you start
All management methods require a valid x-access-token. Create and test the individual web players before adding their identifiers to a group.
What you can do
createandupdatedefine membership, default selection, access, branding, and event settings.getAll,getCount, andgetByIdinspect groups.startandstopcontrol group availability.removedeletes the group but leaves its member web players intact.
Example workflow
- Create and validate one web player for each language feed.
- Create a group containing those player identifiers.
- Select the primary language as the default.
- Apply the shared access and event settings.
- Start the group and publish its viewer URL or embed.
Common use cases
- Offer parallel language or commentary feeds on one event page.
- Publish a curated set of replay or episode variants.
- Apply one restricted or pay-per-view policy to several players.
Limits and troubleshooting
A group depends on valid, playable member resources. Removing or stopping a member can leave an unavailable option in the group until it is updated. Test the default selection, access flow, and every member before publishing.
Next steps
Open Web players to prepare each source, then embed or link the tested group in the viewer experience.
Create a pay-per-view event experience
Prepare the player or players first, group the approved feeds under one viewer page, and apply the pay-per-view and access settings on that group.
- Create the event playerPrepare each live or recorded feed that viewers may purchase.
POST /api/vod/create - Create the paid groupAttach the player entries and configure pay_per_view_settings, access, branding, and event metadata.
POST /api/vod-group/create - Open the viewer experienceStart the group only after purchase and playback checks pass.
POST /api/vod-group/start
A payment configuration is not a completed commerce test. Validate purchase, authorization, support contact, and playback with a test customer before the event.
See the pay-per-view productUse this method when several players should go live as one viewer-facing experience with shared switching, branding, event framing, or access policy.
It is the standard setup step for multi-language, multi-angle, or commentary groups, especially when password or pay-per-view rules must apply across the whole group. If operators trigger publication from production tools, the preset examples below include matching vMix Script requests.
Use this when several parallel web players represent language or commentary variants and one should be selected by default.
Use this when the grouped browser experience should switch between on-demand assets or prepared file-backed players.
Use this when the grouped playback should stay private behind a shared guest password.
Use this when a branded event page should wrap one or more players with PayPal-based access and event timing metadata.
Dashboard label: Group name.
Human-readable name of the grouped playback experience.
Dashboard label: Type.
Real product values include LANGUAGE_LIST and FILES_LIST.
List of linked player entries. Each item includes id, display name, and a selected flag used for the default choice.
Optional viewer authorization block. Real product modes include VOD_PASSWORD_DISABLED, VOD_USE_PASSWORD, and email-plus-password flows.
Optional pay-per-view block. The current dashboard exposes a PayPal-based mode in addition to the disabled default.
Optional branding fields for the grouped playback page.
Optional support contact shown alongside the event-style player experience.
Optional event timing metadata stored on the group.
Dashboard label: Enable once created.
Controls whether the group should be active right after provisioning.
Identifiers and the core group identity fields.
Stored player entries in the group, including default-selection state.
Authorization state plus any linked viewer users that belong to the group.
Stored pay-per-view configuration for the group.
Branding and event metadata returned with the group object.
Current running-state flag and backend-managed timestamps.
The model exposes success: true as a virtual field in successful responses.