create_coupon_m Sample Call and Response

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

This example shows a call that creates a single, individual coupon and links it to an already-existing recurring credit template, based on the create_coupon_m method defined in methods_m_r73.yml, Admin Tools API, release seventy-three.

This example covers every required field, plus a representative set of optional fields that describe the coupon itself — its code, its usage limits, its active date range, and the credit definition it draws from. It does not cover building a brand-new discount rule or discount bundle inline, attaching the coupon to more than one credit template, or the separate create_coupon_group_m method, which defines a batch of coupons rather than one individual coupon.

Sample call

{
  "rest_call": "create_coupon_m",
  "output_format": "json",
  "client_no": 100024,
  "auth_key": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6",
  "coupon_cd": "SUMMER26",
  "coupon_desc": "Summer 2026 promotional discount coupon",
  "coupon_msg": "Thank you for using coupon SUMMER26. Enjoy your discount!",
  "status_ind": 1,
  "no_of_uses": 500,
  "start_date": "2026-07-24",
  "end_date": "2026-09-30",
  "existing_template": [
    {
      "template_no": 30122
    }
  ],
  "coupon_scope": 1
}

The rest_call and output_format fields are not part of the method’s own documented arguments in the yml. The REST layer that fronts every Aria Admin Tools API method adds these two fields, so they appear as the first two keys of every call, requesting the create_coupon_m method and a JSON-formatted response.

Client_no and auth_key are both required identification fields, resolved from the shared param_defaults block rather than declared individually under create_coupon_m. Coupon_cd is the only other field the method marks as strictly required (nullable: false); it is the client-assigned code that identifies this coupon.

Every coupon must be tied to a credit definition through one of several alternative fields: template, discount_rule, discount_bundle, existing_template, existing_discount_rule, or existing_discount_bundle. Building a new template, discount rule, or discount bundle from scratch inside this call would pull in a large, separate set of fields that belong to those other structures rather than to the coupon itself, so this example instead uses existing_template to reference a recurring credit template that a prior call to create_credit_template_m already created (template number thirty thousand one hundred twenty-two). The yml documents existing_template using a REST array notation (existing_template[0][template_no]=1243&existing_template[1][template_no]=1002), so it is represented here as a JSON array, even though this example supplies only one entry. Within that entry, template_no (the Aria-assigned numeric identifier) is used instead of its alternative, template_id (the client-defined identifier), since the numeric identifier is the more direct reference once the template has already been created.

Status_ind is an enum with two values: one means active and zero means inactive; this example uses one to make the coupon active immediately. Coupon_scope is an enum with four values describing where the coupon can be applied; this example uses one, meaning the coupon can be applied to the account only, noting that the other values (master plan instance stack only, account and master plan instance stack, or individual plan instances) apply to other scenarios. Start_date and end_date both use the "yyyy-mm-dd" format and define the window during which the coupon is valid, and no_of_uses limits how many times it can be redeemed before it expires.

Sample response

{
  "error_code": 0,
  "error_msg": "OK",
  "coupon_cd": "SUMMER26"
}

Error_code of zero and error_msg of "OK" together indicate that Aria created the coupon successfully. Coupon_cd echoes back the code that now identifies the newly created coupon, confirming that the SUMMER26 code from the sample call was accepted.

This response does not include every field the method could return in a more complex scenario, but create_coupon_m’s own returns block is limited to these three fields regardless. Left out of this example entirely, on the request side, are the alternative credit-definition paths not chosen (template, discount_rule, discount_bundle, existing_discount_rule, and existing_discount_bundle), the client-defined identifier alternatives (template_id in place of template_no), and any inline construction of a brand-new discount rule or bundle, since this example’s story is about attaching an individual coupon to a credit definition that already exists, not about defining that credit logic from scratch.