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).