Skip to content

Get Batch Voucher movement

/api/v1.0/LoyaltyVault/Reporting/Vouchers

The API returns the movement mutations for a specific customer and loyalty program based on the time range provided in the API request.

Request parameters

For the loyalty mutations API call, there are additional parameters to specify the ‘from’ and ‘to’ date time.

  • LoyaltyPointDefinitionID The loyalty program ID is a compulsory parameter as the point history is returned for the specific loyalty program.
  • From Date range from
  • From Date range to

Response

[
  {
    "accountNumber": "string",
    "loyaltyPrograms": [
      {
        "loyaltyPointDefinitionId": "string",
        "transactions": [
          {
            "serialId": "string",
            "voucherId": "string",
            "type": "Create",
            "shopId": "string",
            "posId": "string",
            "receiptNr": "string",
            "dateTime": "2024-12-10T09:52:39.849Z"
          }
        ]
      }
    ]
  }
]
  • Accountnumber The customer ‘CRM’ account number.
  • ShopId The POS store ID where the transaction took place. For the web store, this depends on the ‘shopID’ that was received from the web store. The value can also be ‘Null’ for example when the points are deducted when a voucher is bought.
  • PosId The POS terminal ID where the transaction was created.
  • ReceiptNr The sales receipt number / Online order number the transaction is related to.
  • Operator ID The POS operator. For the web store, this could be blank.

  • DateTime Date and time when the loyalty mutation occurred.

  • Value The number of points for the specific mutation, for example,

    • The number of points earned (on a ‘load’ transaction)
    • The number of points converted, for example when points are used to buy a voucher or a voucher is automatically generated. In these situations, the points will have a negative value. When ‘convert’ is used to generate the new balance (e.g. after a voucher was bought), it can be positive if the customer has points left.
    • The number of points redeemed (will have a negative value)
    • The number of points that expired (will have a negative value)

  • ExpiresAt

    • The ‘expiresAt’ value displays the date when the loyalty points earned on the specific transaction will expire.
    • This field will only be populated if the loyalty program expiry type is configured to expire loyalty points based on ‘date earned’.
    • If the program is configured that the total balance will expire, then this field will be omitted.

  • Comment Additional information for the movement, for example, that the voucher was ‘Auto converted’ or ‘Auto expired’.

  • TransactionType The type of movement, e.g., load, convert, redeem or expire.

Example

In the example below, the customer earned 138 points (load transaction type), thereafter, a voucher was automatically issued to the customer (as the loyalty program is configured to issue a voucher when 100 points are reached) and the remaining 38 points are the new balance of the customer. The ‘expiresAt’ field is ‘null’ since the loyalty program is configured to expire the entire point balance and not expire points based on the date earned.

alt text

In the example below the customer is linked to a loyalty program where the points expire after 30 days. The customer purchased twice (transaction type ‘load’) and earned 154 and 3 points respectively. The customer purchased a voucher with a value of 130 points. The points used to buy the voucher are ‘converted’ individually (i.e. per original load), and the remaining points are converted to be the opening balance, i.e. the ‘convert’ example of 27 points.

alt text