modify_acct_supp_fields_m Sample Call and Response
This example shows an account having two supplemental fields updated in a single call, based on the modify_acct_supp_fields_m method defined in plsql_m_r73.yml.
This example includes every required field and shows the pipe-delimited, parallel-array structure used to update more than one supplemental field at once. It does not cover removing supplemental fields or replacing every value of a multi-value supplemental field.
Sample call
{
"rest_call": "modify_acct_supp_fields_m",
"output_format": "json",
"client_no": 32409,
"auth_key": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
"acct_no": 5008842,
"acct_supp_fields": {
"supp_field_name": "TAX_EXEMPT_NUM|VAT_ID",
"supp_field_value": "TX-9988-EXEMPT|GB123456789",
"supp_field_directive": "2|1"
}
}
The field acct_no is used to identify the account rather than its alternative, client_acct_id, since acct_no is the Aria-assigned numeric identifier. The acct_supp_fields field is a single wrapper object, not an array of objects, because its three sub-fields, supp_field_name, supp_field_value, and supp_field_directive, are each documented as a pipe-delimited array of values within one string; the first value of each sub-field corresponds to the first value of the other sub-fields, the second to the second, and so on. In this example, the first pipe-delimited position updates the TAX_EXEMPT_NUM supplemental field with directive 2, replacing all existing instances of that field with the new value, and the second position adds the VAT_ID supplemental field with directive 1, adding the field and value to the account. Other valid directive values are 3, which removes the supplemental field and value while leaving other values of that field untouched, and 4, which removes all instances of the supplemental field regardless of the value supplied. The fields rest_call and output_format are envelope fields added by the REST layer and are not part of the method's own documented arguments.
Sample response
{
"error_code": 0,
"error_msg": "OK"
}
The error_code value of 0 and the error_msg value of "OK" indicate that both supplemental field updates completed without error. This example leaves out the error_details field entirely, since that field is marked nonpublic in the yml and is not populated in responses to client callers.