get_revrec_profile_details_m Sample Call and Response
This example shows a client retrieving the full configuration of one specific revenue recognition (revrec) profile, identified by its Aria-assigned profile_id. It is based on the get_revrec_profile_details_m definition in the methods_m_r73.yml Admin Tools API definition file, where the method belongs to release Aria7.
This example includes both required identifying fields, client_no and auth_key, plus the one identifier the method needs to select a single profile, and it shows every field that this method's returns block defines, including the three recognition-timing indicators that get_revrec_profiles_m does not return. This example does not show the alternative form of the call that identifies the profile by client_profile_id instead of profile_id, and it does not show a failure case.
Sample call
{
"rest_call": "get_revrec_profile_details_m",
"output_format": "json",
"client_no": 400219,
"auth_key": "8f3ac9d2e1b74c6a9f0d3e8b21a7c455",
"profile_id": 5001
}
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 that owns the profile, and auth_key is the Aria-assigned key that authenticates the caller. The profile itself is identified by profile_id, the Aria-assigned numeric identifier for the profile. The yml lists profile_id and client_profile_id as an alt_required_field pair, meaning a caller supplies exactly one of the two, not both; this example uses profile_id, the Aria-assigned numeric identifier, rather than client_profile_id, the client-defined identifier, since the numeric identifier is the more direct and unambiguous way to select one record.
Sample response
{
"error_code": 0,
"error_msg": "OK",
"profile_id": 5001,
"profile_name": "Standard Monthly Recognition",
"client_profile_id": "STANDARD_REVREC",
"profile_desc": "Recognizes revenue evenly across the plan payment schedule for standard subscription plans.",
"on_plan_payment_date": 1,
"on_order_payment_date": 0,
"on_order_fulfill_date": 0
}
An error_code of zero, together with an error_msg of “OK,” indicates that the call succeeded. The response echoes the profile_id and client_profile_id that identify the profile, along with its profile_name and profile_desc. The remaining three fields are the recognition-timing indicators the yml associates only with this method: on_plan_payment_date, on_order_payment_date, and on_order_fulfill_date are each an integer flag with a valid value of zero or one, where one indicates that revenue recognition for this profile is triggered by that particular date type, and zero indicates that it is not. In this example, on_plan_payment_date is set to one and the other two flags are set to zero, meaning this particular profile recognizes revenue on plan payment dates rather than on order payment dates or on order fulfillment dates. Unlike the response of get_revrec_profiles_m, which returns an array covering every profile belonging to a client, this response describes exactly one profile and is not an array, since get_revrec_profile_details_m is a single-record lookup.