Best Practices: Naming Conventions in Zixi

zixi component names including channels, inputs, outputs, targets, adaptive groups, and zen master resources, are used internally in configuration files, api calls, log entries, and url based endpoints using special characters in these names can cause unexpected failures that are difficult to diagnose, particularly in automation workflows, rest api integrations, and scripted monitoring pipelines use only alphanumeric characters, hyphens, underscores and periods for naming conventions what to avoid avoid all characters outside the safe set described above common problem characters include character example why it's problematic spaces my channel breaks url parsing; must be percent encoded as %20, which causes issues in api calls and log searches forward slash bbc/hd interpreted as a path separator in urls and file systems backslash bbc\hd causes parsing failures in json and config files ampersand sport\&news reserved in urls; interpreted as a query string delimiter hash channel#1 interpreted as a url fragment identifier; truncates api requests question mark test?hd interpreted as the start of a url query string percent 50%feed triggers percent encoding interpretation in urls at sign feed\@site confused with authentication syntax in urls brackets \[hd]feed can break shell scripts, json parsing, and regex based log filters parentheses feed(backup) can interfere with scripting, cli tools, and api parsing quotes "primary" breaks json serialization and command line argument handling colons bbc\ hd reserved in uris and can interfere with host\ port parsing commas ch1,ch2 often used as delimiters in api parameters; can split values unexpectedly safe characters character type allowed notes letters a–z, a–z both upper and lower case numbers 0–9 hyphen good for word separation bbc hd primary underscore good for grouping segments bbc hd primary period useful for versioning or hierarchy bbc hd primary recommended naming patterns use a consistent naming convention across your deployment a structured pattern makes names predictable, searchable and automation friendly suggested format \<site/customer> \<source/service> \<resolution/profile> \<role> examples nyc espn hd primarynyc espn hd failover lon bbc1 sd input aws eu sport24 1080p output keep names concise and machine readable renaming existing components if you have existing resources with non compliant names, plan renames carefully audit first check your lists in zen master or broadcaster and identify all non compliant names check dependencies before renaming, verify whether the resource name is referenced in api integrations, monitoring scripts, or external systems (encoders, decoders, automation) rename during a maintenance window renaming an active channel or output will interrupt the stream always rename during scheduled downtime