The following section covers the basic data models relevant for VidiFlow API.


It is essential for users wishing to integrate against VidiFlow, that a comprehensive understanding of VidiFlow's specific URI concept be achieved. This becomes particularly relevant when it comes to naming and handling the input and output URI parameters for tasks.

DIAGRAM: ObjectUri Model

The highest level is occupied by the "ObjectUri". All other subsequent children URIs derive from the "ObjectUri".




Children URIs






Scheme: "vpms"
These are URIs from the Worker Based VPMS" (VPMS2).
Please note that the new VPMS URIs (VPMS3) are now featured with the scheme "pf" instead of "vpms"! This is done with purpose of separate the contexts and avoid conflicts by renaming Worker Based VPMS (VPMS2) URI scheme into something within VidiFlow.

Schemes: "smb", "ftpe", "file" or "ftp"

Scheme: "pf"
Please note that the "pf" scheme is the designated URI for addressing all objects in the VidiFlow /Vidispine world.

When naming a parameter for URI, it is important to consider the nature of the different URI before choosing.

  • VpmsUri: if this is a Worker Based VPMS URI (VPMS2).

  • PhysicalUri: if the input URI is only valid if it has one of the following schemes; "smb", "ftpe", "file", or "ftp".

  • PlatformUri: if the input URI identifies a VidiFlow /Vidispine object.

  • ObjectUri: if the allowed runtime content may be more than one of the children types.