update_usage_type_m Sample Call and Response
This example shows a client updating an existing usage type, “API Call Volume,” to revise its description and the value of one supplemental object field. It is based on the update_usage_type_m method as defined in methods_m_r73.yml, Admin Tools API.
This example covers every required field, plus a client-defined code, a display string, and one supplemental object field. It does not attempt to show every optional field the method accepts.
Sample call
{
"rest_call": "update_usage_type_m",
"output_format": "json",
"client_no": 700123,
"auth_key": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6",
"usage_type_no": 3456,
"usage_type_name": "API Call Volume",
"usage_type_desc": "Tracks the number of API calls consumed by the account during the billing period, including calls made through partner integrations.",
"usage_unit_type_no": 12,
"usage_type_code": "API-CALLS",
"usage_type_display_string": "API Calls",
"supplemental_obj_field": [
{
"field_no": 91024,
"field_value": ["Premium"]
}
]
}
The rest_call and output_format fields are not part of the method’s own documented arguments. The REST layer adds them to every call: rest_call names the method being invoked, and output_format requests a JSON response rather than the default WDDX format. Within the method’s own arguments, client_no and auth_key identify and authenticate the client making the call. The usage_type_no and usage_type_code fields are alternatives to each other; this example identifies the usage type by its Aria-assigned numeric usage_type_no rather than the client-defined usage_type_code, though usage_type_code is still supplied here as an ordinary optional field to keep it current. usage_type_name, usage_type_desc, and usage_unit_type_no are all required alongside usage_type_no; this example keeps the name the same but revises the description to mention partner integrations, and keeps usage_unit_type_no pointed at the same unit of measure. usage_type_display_string supplies the label shown to the account holder. The supplemental_obj_field entry identifies one supplemental object field by its Aria-assigned field_no rather than the alternative field_name, and supplies its value as a single-element array, since field_value itself accepts more than one value per field; here the value is changed from “Standard” to “Premium.” A call with more supplemental fields would repeat this pattern with additional entries in the array.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"usage_type_no": 3456
}
An error_code of zero, paired with an error_msg of “OK,” indicates that Aria updated the usage type successfully. The usage_type_no field echoes back the Aria-assigned identifier of the usage type that was updated. The method’s returns block consists only of these three fields, so there is no additional output to show.