Hi dev team,

I’d like to propose an API enhancement that would extend the StartRecording function to accept a dynamic filename argument.

The intent is to allow external automation systems to pass a variable (e.g. from scheduling, control, or metadata layers) into vMix at runtime to define the output filename before recording starts.

Current limitation

The StartRecording API function currently triggers recording using the globally defined “Filename Format” under Settings → Recording.
While the global template works for fixed naming patterns, there’s no exposed mechanism to override or inject a custom filename dynamically per recording session.

As a result, integrators must:

Rely on file-system watchers or post-record rename scripts (which introduce race conditions with locked files), or

Use global filename patterns that can’t reflect session-specific metadata such as booking IDs, client codes, or timestamps.

Proposed implementation

Extend StartRecording to accept a Filename argument
Example:

Function=StartRecording&Filename=MyCustomFile_20251008_0930.mp4


If Filename is provided, vMix should use this value for the active recording session only.

If omitted, the system should default to the existing Filename Format behaviour (for backward compatibility).

Alternative: dedicated setter function

Function=SetRecordingFilename&Value=MyCustomFile_20251008_0930.mp4


This could be called before StartRecording.

The next recording session would use this custom name, then revert to default after completion.

Optional support for tokens and substitution

Allow token syntax, e.g. {Date}, {Time}, {InputName} for partial dynamic generation.

Allow external automation to pre-fill these variables through the API or scripting interface.

Rationale

For broadcast and enterprise workflows where vMix is controlled remotely (via REST, PowerShell, or custom UIs), the ability to inject a filename from external context is essential for:

Asset tracking and integration with playout systems

Aligning recorded assets with automation metadata (e.g. campaign, job ID, reporter, timestamp)

Avoiding post-record rename scripts or file-system watchers

Reducing latency and potential naming conflicts in concurrent recording environments

Example API sequence
GET /api/?Function=SetRecordingFilename&Value=Toyota_BreakfastShow_20251008_0900.mp4
GET /api/?Function=StartRecording


or inline:

GET /api/?Function=StartRecording&Filename=Toyota_BreakfastShow_20251008_0900.mp4


Expected behaviour:

vMix starts recording immediately using the provided filename in the configured record path.

The parameter affects only that session and resets afterward.

Backward compatibility maintained for existing integrations.

Implementation notes

Should respect global recording folder path and format (container, codec).

Input sanitisation for filename (valid characters, length).

Optional confirmation in the XML API status return:

<recording active="True" filename="Toyota_BreakfastShow_20251008_0900.mp4" />


Ideally usable through both HTTP API and scripting (API.Function("StartRecording", "Filename=...")).

Summary

This feature would significantly improve automation workflows and make vMix more integration-friendly for enterprise and broadcast users.
It’s a low-risk, backward-compatible enhancement that would eliminate the need for fragile post-record rename workarounds.


Thanks for considering it,
Mick Paul