get_family_trans_history_m Sample Call and Response
This example retrieves the invoice transaction history across a parent account and its child accounts for a fiscal quarter, based on the plsql_m_r73.yml definition file for Aria release 73.
This example includes every required field and a representative set of commonly used optional fields, not every field the method accepts. The sample call filters the results to invoice transactions only, and the sample response shows transactions belonging to both the parent account and one child account in the family hierarchy.
Sample call
{
"rest_call": "get_family_trans_history_m",
"output_format": "json",
"client_no": 100234,
"auth_key": "8f3d9c2e1b7a4f6d9e0c1a2b3d4e5f60",
"parent_acct_no": 300118842,
"do_multi_level": "true",
"trans_type": 1,
"start_date": "2026-04-01",
"end_date": "2026-06-30",
"record_limit": 50,
"include_void_transactions": "false"
}
The rest_call and output_format fields are envelope fields added by the REST layer; they are not part of the method's own documented arguments. For the parent account identifier, this example uses parent_acct_no rather than its alternative, client_acct_id. Setting do_multi_level to true tells Aria to include every level of the account hierarchy under the parent account, not just its immediate children. The trans_type value of 1 filters the results to invoice transactions only; other allowable values identify checks, electronic payments, balance transfers, write-offs, credits, and their voided counterparts. Setting include_void_transactions to false excludes voided transactions from the results. The optional master_plan_instance_no and client_master_plan_instance_id fields, which would further filter results to a single master subscription plan instance, are left out of this example.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"fam_transactions": [
{
"acct_no": 300118842,
"master_plan_instance_no": 550219,
"client_master_plan_instance_id": "MPI-ACME-0447",
"transaction_id": 9042001,
"transaction_type": 1,
"transaction_desc": "Invoice generated",
"transaction_amt": 245.00,
"transaction_applied_amt": 245.00,
"transaction_currency": "USD",
"transaction_create_date": "2026-05-01 03:00:12",
"transaction_stmt_no": 771122,
"transaction_seq_stmt_id": "2026-05-STMT-000771122",
"invoice_no": 8820441
},
{
"acct_no": 300118855,
"master_plan_instance_no": 550311,
"client_master_plan_instance_id": "MPI-ACME-CHILD-02",
"transaction_id": 9042083,
"transaction_type": 1,
"transaction_desc": "Invoice generated",
"transaction_amt": 89.50,
"transaction_applied_amt": 89.50,
"transaction_currency": "USD",
"transaction_create_date": "2026-05-01 03:04:47",
"transaction_stmt_no": 771145,
"transaction_seq_stmt_id": "2026-05-STMT-000771145",
"invoice_no": 8820502
}
]
}
An error_code value of 0 and an error_msg value of “OK” indicate the call succeeded. The fam_transactions array would contain one entry for every transaction found across the account family within the requested date range, up to the record_limit; this example shows two entries, one from the parent account and one from a child account, to illustrate that the array spans the whole family hierarchy. Because the sample call filters on trans_type 1, every entry shown is an invoice transaction; a call without that filter would also return other transaction types, such as payments, credits, and write-offs. This example leaves out the nullable transaction_void_date, transaction_void_reason, client_receipt_id, transaction_comments, transaction_source_id, transaction_ref_code, credit_reason_code_description, and csr_comments fields on each transaction, since none of them apply to a straightforward invoice transaction. The nonpublic error_details field is also left out.