# What does Price mean in a Rekaz reservation webhook?

Source: https://help.rekaz.io/en/articles/16961308-what-does-price-mean-in-a-rekaz-reservation-webhook
Updated: 2026-09-15

For reservation events, Data.Price is the reservation line total after discount, including tax. It corresponds to Data.Order.Item.TotalAmount. It is not the unit price before tax, the amount collected from the customer or the net bank payout. Data.Order.TotalAmount represents the entire order and can differ when the order includes other lines or fees.

The pictured example is a 50 SAR reservation. Its order line shows 43.48 before tax, 6.52 tax and a tax-inclusive total of 50. Paid Amount is zero and Remaining Amount is 50. These amounts serve different purposes: seeing 43.48 in the dashboard Price column does not mean the webhook Price field excludes tax.

<https://player.vimeo.com/video/1226972313>

## Before you start

Have the reservation and order numbers from the event data ready, then open Orders in Rekaz.

-   Use a reservation-family event, such as ReservationConfirmedEvent. Subscription, transaction and gift events have different contracts; do not assume their Price fields have the same meaning.
    
-   Match Data.Number to the reservation number and Data.Order.SequentialNumber to the order number. The outer Id identifies the delivered event, not the order number shown in the dashboard.
    
-   Compare the same reservation and order, considering the event time and any later changes. Keep sensitive integration data within your designated systems.
    

## 1\. Open the matching order

Under Orders, search using Data.Order.SequentialNumber and open the matching Order Number. Do not confuse it with an invoice number or reservation number.

  

![Open the matching order — Order Number matched to the webhook order](https://downloads.intercomcdn.com/i/o/aahcqj2g/2672210714/57c10056e884c5f6537286492076/exjkeb.png)

  

## 2\. Match the reservation to the line

Under Order details, open the service row’s details. Compare the displayed reservation number with Data.Number and review the service and time. Select Close to return to the order.

  

![Match the reservation to the line — Linked reservation number](https://downloads.intercomcdn.com/i/o/aahcqj2g/2672210717/f5901943cd2f578035b695a5e5d7/slh1k6.png)

  

## 3\. Read the tax-inclusive line total

Review Quantity, Price, Discount, Vat amount and Total price including Vat. Scroll the table horizontally if needed. The last amount corresponds to Data.Price and Data.Order.Item.TotalAmount. Do not add tax or deduct the discount again.

  

![Read the tax-inclusive line total — Line price before tax and total including VAT](https://downloads.intercomcdn.com/i/o/aahcqj2g/2672210702/464207bdd4a44f948a860511beda/56706z.png)

  

## 4\. Separate order totals from collection

Scroll to Order totals and Payment. Compare the full total with Data.Order.TotalAmount, and Paid Amount and Remaining Amount with their Order fields. In this example, total is 50, paid is zero and remaining is 50. You do not need to pay or edit the order just to compare it.

  

![Separate order totals from collection — Order totals compared with payment and remaining amount](https://downloads.intercomcdn.com/i/o/aahcqj2g/2672210698/0b890d62d965cb83841aae4b90a4/5pybe4.png)

  

## Result

You identify the tax-inclusive reservation line amount and distinguish it from the full order total and payment collection.

Data.Price is the reservation line total after discount and including tax. Do not add tax again or subtract Data.Discount from it a second time. A difference from the service’s current catalogue price does not by itself prove a new discount; compare the saved order line.

Data.Items\[\].Price also represents the reservation line amount. Do not add it to Data.Price as though they were separate charges, or multiply the line total by quantity again.

Data.Order.Item contains the related line breakdown: Quantity, UnitPrice, Subtotal, DiscountAmount, TaxAmount and TotalAmount. Item is singular here and is different from the reservation’s Items array.

Data.Order.TotalAmount represents the full order. With multiple services or order fees, it need not equal one reservation’s Price. Use the related Item for the reservation and Order for the full sale.

Data.Order.PaidAmount is the amount paid, Data.Order.RemainingAmount is the balance, and Data.Order.Currency identifies the currency. Price does not prove payment and is not a payment-gateway commission or the net amount transferred to your bank.

In the pictured example, both line and order total are 50, Paid Amount is 0 and Remaining Amount is 50. A confirmed reservation or ReservationConfirmedEvent does not replace checking PaymentStatus and payment amounts when your task requires proof of payment.

The dashboard Price column shows the pre-tax price in this example. Compare Data.Price with Total price including Vat, then use Discount and Vat amount to understand the breakdown. Similar field names do not guarantee the same meaning.

The dashboard may show two decimal places while webhook amounts retain up to four. Use decimal money calculations and consistent display rounding. A small rounding difference is not automatically a fee or discount.

If an older sample contains 43.4783 instead of 50, do not apply a fixed tax multiplier to every incoming message. Check a recent event and its Order.Item fields against the same order. If a mismatch remains, prepare the reservation number, order number, event time and relevant amounts for support without sharing integration secrets.

Webhook field names use the displayed casing: the envelope contains Id, EventName, CreatedAt and Data, and nested fields include Price and Order. Do not automatically copy REST response field names into a webhook parser; shape and casing can differ.

A reservation may produce multiple lifecycle events, and a delivery may be retried. Do not add the full order total to revenue for every related reservation event. Distinguish delivery, reservation and order identifiers when deduplicating and updating your integration.

Keep reservation state separate from payment state. When an action depends on current status, review the current record as needed: an earlier event does not guarantee that the order has remained unchanged.