get_revrec_profiles_m Sample Call and Response
This example shows a client retrieving every revenue recognition (revrec) profile that is configured for its account. It is based on the get_revrec_profiles_m definition in the methods_m_r73.yml Admin Tools API definition file, where the method belongs to release Aria7.
The get_revrec_profile_details_m method, defined in the same file, accepts no filtering, sorting, or paging arguments at all, and the yml defines no such arguments for it: the method always returns the complete set of revrec profiles belonging to the client identified by client_no. This example therefore covers only the two arguments the method actually accepts, and it shows the abbreviated set of four fields returned for each profile in the list, which is smaller than the field set that get_revrec_profile_details_m returns for a single profile.
Sample call
{
"rest_call": "get_revrec_profiles_m",
"output_format": "json",
"client_no": 400219,
"auth_key": "8f3ac9d2e1b74c6a9f0d3e8b21a7c455"
}
The rest_call and output_format fields are not part of the method's own documented arguments; they are the standard envelope that the REST layer adds to every Admin Tools API call, identifying the method being invoked and requesting a JSON response. The client_no and auth_key fields are both required, since the yml marks each of them as nullable: false in the shared param_defaults block; client_no is the Aria-assigned identifier of the client whose profiles are being requested, and auth_key is the Aria-assigned key that authenticates the caller. This method takes no other input, so there is no way in a single call to filter the returned list to a subset of profiles by name or by identifier; that finer-grained lookup is available only through get_revrec_profile_details_m.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"profiles": [
{
"profile_id": 5001,
"client_profile_id": "STANDARD_REVREC",
"profile_name": "Standard Monthly Recognition",
"profile_desc": "Recognizes revenue evenly across the plan payment schedule for standard subscription plans."
},
{
"profile_id": 5002,
"client_profile_id": "USAGE_REVREC",
"profile_name": "Usage-Based Recognition",
"profile_desc": "Recognizes revenue at the point of order fulfillment for usage-based billing plans."
},
{
"profile_id": 5003,
"client_profile_id": null,
"profile_name": "Annual Prepay Recognition",
"profile_desc": null
}
]
}
An error_code of zero, together with an error_msg of “OK,” indicates that the call succeeded. Each entry in the profiles array carries four fields: profile_id, the Aria-assigned numeric identifier for the profile; client_profile_id, an optional client-defined identifier for the same profile; profile_name, the display name of the profile; and profile_desc, an optional free-text description of what the profile does. The third entry in the example, profile 5003, deliberately shows client_profile_id and profile_desc returned as null, since the yml marks both of those fields as nullable and a profile is not required to have either one populated. The profiles array shown here holds three representative entries; a client with additional revrec profiles configured would receive additional entries in the same array, and this example does not imply that three is the maximum or the total count. Because this method's own returns block defines only these four fields, this response does not include the on_plan_payment_date, on_order_payment_date, or on_order_fulfill_date recognition-timing indicators; those three fields appear only in the response of get_revrec_profile_details_m, which reports on one profile at a time.