Python ↔ JavaScript Naming Map

Python uses snake_case, JavaScript uses camelCase. Parameter order is identical
across the two SDKs; only the casing differs.

Op	Python method	JavaScript method
get	`get_asset(asset_id)`	`getAsset(ASSET_ID)`
list children	`get_asset_child_nodes(asset_id, folder_id, sort_column, is_desc, page_index, page_size)`	`getAssetChildNodes(ASSET_ID, FOLDER_ID, SORT_COLUMN, IS_DESC, PAGE_INDEX, PAGE_SIZE)`
create folder	`create_folder_asset(parent_id, display_name)`	`createFolderAsset(PARENT_ID, DISPLAY_NAME)`
upload	`upload_asset(name, existing_asset_id, related_content_id, upload_overwrite_option, file, parent_id, language_id, upload_replace_options)`	`uploadAsset(NAME, EXISTING_ASSET_ID, RELATED_CONTENT_ID, UPLOAD_OVERWRITE_OPTION, FILE, PARENT_ID, LANGUAGE_ID, UPLOAD_REPLACE_OPTIONS)`
move	`move_asset(asset_id, destination_folder_id, name, batch_action, content_definition_id, schema_name, resolver_exempt)`	`moveAsset(ASSET_ID, DESTINATION_FOLDER_ID, NAME, BATCH_ACTION, CONTENT_DEFINITION_ID, SCHEMA_NAME, RESOLVER_EXEMPT)`
delete	`delete_asset(asset_id)`	`deleteAsset(ASSET_ID)`
search	`search(query, offset, size, filters, sort_fields, search_result_fields,...)`	`search(QUERY, OFFSET, SIZE, FILTERS, SORT_FIELDS, SEARCH_RESULT_FIELDS,...)`

Required-vs-optional notes

get_asset_child_nodes: all six args are positional/required. For "list children of
one folder", pass the folder id for both asset_id and folder_id, e.g.
get_asset_child_nodes(folder_id, folder_id, "name", False, 0, 500).
upload_asset: parent_id, language_id, upload_replace_options have defaults
(None) in Python and may be omitted in JS. For a plain new upload, pass
name=None, existing_asset_id=None, related_content_id=None, upload_overwrite_option="replace".
move_asset: name, batch_action, content_definition_id are required positional
with no defaults - pass None for a plain move: move_asset(asset_id, dest, None, None, None).
search: every param is keyword/optional. Common keywords: query, offset, size,
filters, sort_fields, search_result_fields, filter_binder.

Live channels (admin-only)

Same casing rule (snake_case ↔ camelCase), identical parameter order.

Op	Python method	JavaScript method
list channels	`get_live_channels`	`getLiveChannels`
get channel	`get_live_channel(live_channel_id)`	`getLiveChannel(LIVE_CHANNEL_ID)`
start channel	`start_live_channel(live_channel_id, wait_for_start)`	`startLiveChannel(LIVE_CHANNEL_ID, WAIT_FOR_START)`
stop channel	`stop_live_channel(live_channel_id, wait_for_stop)`	`stopLiveChannel(LIVE_CHANNEL_ID, WAIT_FOR_STOP)`
refresh all	`live_channel_refresh`	`liveChannelRefresh`
list inputs	`get_live_inputs`	`getLiveInputs`
get input	`get_live_input(live_input_id)`	`getLiveInput(LIVE_INPUT_ID)`
list operators	`get_live_operators`	`getLiveOperators`
get operator	`get_live_operator(live_operator_id)`	`getLiveOperator(LIVE_OPERATOR_ID)`

status verb: Python has no public status method - read
get_live_channel(...)["status"]["description"]. JS adds public
getLiveChannelStatus(LIVE_CHANNEL_ID), getLiveChannelStatusMessage(...),
getLiveChannelInputsIds(...), getLiveChannelScheduleEvents(...) with no Python peer.
start_live_channel/stop_live_channel: the wait flag defaults to None in Python
(omittable) - pass True to block until Running/Idle.

Collections / content groups (portal-only)

A UI collection is a content group at the API layer (the contentGroup REST
endpoints). Same casing rule (snake_case ↔ camelCase), identical parameter
order. Every op below is portal-apiType only.

Op	Python method	JavaScript method
create	`create_content_group(name)`	`createContentGroup(NAME)`
get	`get_content_group(content_group_id)`	`getContentGroup(CONTENT_GROUP_ID)`
list (caller's)	`get_content_groups`	`getContentGroups`
add contents	`add_contents_to_content_group(content_group_id, content_ids)`	`addContentsToContentGroup(CONTENT_GROUP_ID, CONTENT_IDS)`
remove contents	`remove_contents_from_content_group(content_group_id, content_ids)`	`removeContentsFromContentGroup(CONTENT_GROUP_ID, CONTENTS)`
rename	`rename_content_group(content_group_id, name)`	`renameContentGroup(CONTENT_GROUP_ID, NAME)`
delete	`delete_content_group(content_group_id)`	`deleteContentGroup(CONTENT_GROUP_ID)`
share w/ users	`share_content_group_with_users(content_group_id, user_ids)`	`shareContentGroupWithUsers(CONTENT_GROUP_ID, USER_IDS)`
stop sharing	`stop_sharing_content_group_with_users(content_group_id, user_ids)`	`stopSharingContentGroupWithUsers(CONTENT_GROUP_ID, USER_IDS)`
portal buckets	`get_portal_groups(portal_groups)`	`getPortalGroups(PORTAL_GROUPS)`

share verb is PLURAL (_with_users / WithUsers) on both SDKs - the singular form does
not exist on the SDK.
content vs asset: add_contents_to_content_group takes a list of content/asset ids
(maps to POST /contentGroup/add|remove/{id}).

Content routes (admin-only, generic entity CRUD)

The generic read/write surface over any entity (content definition). Same casing rule
(snake_case ↔ camelCase), identical parameter order. content_definition_id is the entity id
from schema.md; properties keys are that entity's field names. See
recipes/content-update.md.

Op	Python method	JavaScript method
get content	`get_content(content_id, content_definition_id, is_revision)`	`getContent(CONTENT_ID, CONTENT_DEFINITION_ID, IS_REVISION)`
update content	`update_content(content_id, content_definition_id, properties, language_id)`	`updateContent(CONTENT_ID, CONTENT_DEFINITION_ID, PROPERTIES, LANGUAGE_ID)`
create content	`create_content(content_definition_id, language_id)`	`createContent(CONTENT_DEFINITION_ID, LANGUAGE_ID)`
delete content	`delete_content(content_id, content_definition_id)`	`deleteContent(CONTENT_ID, CONTENT_DEFINITION_ID)`

update_content is read-modify-write: it GETs the live record, deep-merges your
properties, then PUTs the whole body - pass only the fields you change. List fields are
truncated to the length you send (append by sending existing + new).
is_revision/language_id are optional (pass None/null for the current version /
default language variant).

Content definitions & event scheduler (admin-only)

Discovery + event-scheduler surface used by the bulk-import recipe
(recipes/bulk-import-events-from-spreadsheet.md).
Same casing rule (snake_case ↔ camelCase), identical parameter order. All admin apiType.

Op	Python method	JavaScript method
get content definition	`get_content_definition(content_definition_id)`	`getContentDefinition(CONTENT_DEFINITION_ID)`
list content definitions	`get_content_definitions(content_management_type, sort_column, is_desc, page_index, page_size)`	`getContentDefinitions(CONTENT_MANAGEMENT_TYPE, SORT_COLUMN, IS_DESC, PAGE_INDEX, PAGE_SIZE)`
create/update event	`create_and_update_event(content_id, content_definition_id, name, start_datetime, end_datetime, event_type, series, is_disabled, override_series_properties, series_properties)`	`createAndUpdateEvent(CONTENT_ID, CONTENT_DEFINITION_ID, NAME, START_DATETIME, END_DATETIME, EVENT_TYPE, SERIES, IS_DISABLED, OVERRIDE_SERIES_PROPERTIES, SERIES_PROPERTIES)`
add live schedule	`add_live_schedule_to_event(event_id, slate_video, preroll_video, postroll_video, is_secure_output, archive_folder, primary_live_input, backup_live_input, primary_livestream_input_url, backup_livestream_input_url, external_output_profiles, status, status_message, live_channel, override_settings, output_profile_group)`	`addLiveScheduleToEvent(EVENT_ID, SLATE_VIDEO, PREROLL_VIDEO, POSTROLL_VIDEO, IS_SECURE_OUTPUT, ARCHIVE_FOLDER, PRIMARY_LIVE_INPUT, BACKUP_LIVE_INPUT, PRIMARY_LIVESTREAM_INPUT_URL, BACKUP_LIVESTREAM_INPUT_URL, EXTERNAL_OUTPUT_PROFILES, STATUS, STATUS_MESSAGE, LIVE_CHANNEL, OVERRIDE_SETTINGS, OUTPUT_PROFILE_GROUP)`
get live schedule	`get_live_schedule(event_id)`	`getLiveSchedule(EVENT_ID)`
delete event	`delete_event(content_id, content_definition_id)`	`deleteEvent(CONTENT_ID, CONTENT_DEFINITION_ID)`

get_content_definitions args are all optional - pass nothing for the default listing.
Prefer the curated Entities table in schema.md when you already know the id.
Do not write events with create_and_update_event - it is broken three ways (no-op update
path, misspelled startDatetime/endDatetime, swallowed required-event_type 409;). Write events the contract way instead: create_content(EVENT_CD) then a properties-only
update_content (with the required eventType ref). update_content returns None even
on success, so keep the contentId from create_content.
add_live_schedule_to_event args after event_id are all optional - pass only what you
have. Reference fields (slate_video, archive_folder, primary_live_input, …) take a
{id, description} shape; external_output_profiles is a list of those refs. It requires
a postroll_video (else 409,) and returns None on success and failure - verify with get_live_schedule.
get_live_schedule(event_id) reads back a SEPARATE object (GET /admin/liveSchedule/ content/{eventId}), not part of the event content - it is the only way to verify write 3.
event_type/series are {id, description} dicts, not bare GUIDs.