The order's money figures, in the order's currency. Only subtotal is required by validation, but send every figure: 0 means zero, and a figure left out is read as not sent, never as zero. These six are the only keys accepted: any other, such as shipping, tax, discount or total, is refused with 422 VALIDATION_ERROR.

The figures fit together like this:

• Each line's line_total = its unit_price × quantity, less the line's own discount.
• subtotal = the lines' line_totals, less any order-wide discount. It includes tax only when prices include tax.
• discount_total = every line's unit_price × quantity, less subtotal.
• grand_total = subtotal + shipping_total + protection_cost, plus tax_total only when prices exclude tax.

When the order is stored, Get Plus checks every figure against the others. An order whose figures don't agree, or that leaves one out, is flagged, and staff see why before they approve a claim on it.

After a partial cancellation don't take the cancelled units out of these figures: the cancellation is recorded on its own, with POST /orders/{order_number}/cancel. Get Plus keeps the order's discount as it stood at its first partial cancellation: what the lines' line_totals come to above subtotal, or their unit_price × quantity when they carry no line_total. A request that moves subtotal without the lines, lowering it by the cancelled units included, gets the order flagged, and it stays flagged on every later write until the discount is as it was. Adding, removing or re-pricing an item that nothing was cancelled on, sending a figure for the first time, and refunding shipping sent as shipping_total are not flagged when the lines and subtotal move together. On a subtotal that has the shipping in it and lines with no line_total, a shipping refund lowers subtotal alone and is flagged. The discount is kept as an amount or as a share of the items, so a percentage off the whole order keeps its share as items are added, removed or re-priced, and is not flagged. An order partially cancelled before Get Plus began keeping the figures has none kept: only the request that changes them is flagged, and the same figures sent again are not.

Claim payouts. When every figure is sent and they all agree, a claim pays what was paid for the claimed items: each line's line_total, less its share of any order-wide discount. On a flagged order, a claim pays the claimed items' share of subtotal instead, never more than their list price. The Claims guide explains both under How a claim payout is priced.

Every discount on the order, one entry per code or discount, each with its amount and applies_to. A line entry is a discount on particular lines, already taken off their line_total; an order entry is an order-wide discount, which is on no line. The line entries add up to the lines' own discounts, and the order entries to what the line totals come to above amounts.subtotal.

Claim payouts never use them to pay a claim. They must agree with the other figures, or the order is flagged: a line discount listed here but left off its line gets the order flagged.

Customer's per-channel opt-in for order/tracking notifications. Get Plus sends a tracking email only when email is true and an SMS only when sms is true; omit a channel (or send false) to suppress it. Persisted on the order so notification delivery can honour the customer's preference. PUT /orders is a FULL REPLACE — resend order_notifications on every request to keep it; omitting it clears the stored opt-in.

Shipments to register for this order. Each entry is registered with the carrier and drives the customer tracking page + notifications — the same pipeline as POST /shipments, so no separate call is needed. Registration is idempotent per (store, tracking_number, order_number). Include more than one entry for a split order (shipped in several packages, even across carriers); each tracking number is tracked independently and shows only its own items.

PPLUS-4743 — the store the order originated from, for B2B platform accounts (same "source" family as source_channel / source_payload: it names the partner's own system, not ours).

Who must send it. Required on every POST /orders and PUT /orders/{order_number} for a store configured as a B2B platform; omitting it is rejected with 422 SOURCE_STORE_REQUIRED. Every other store must NOT send it — a body containing it is rejected with 422 SOURCE_STORE_NOT_ALLOWED. The store's configuration is read server-side on every request; there is no request field or token claim that selects the behaviour.

It is a label, never a key. id is an opaque string YOU choose and manage. Get Plus never resolves it to a Get Plus store, merchant, API key or login — it is stored beside the order and shown on your dashboard. Source stores have no account, no credentials and no portal.

Order numbers stay globally unique across your source stores. Orders are addressed by (your store, order_number) everywhere in this API — replay, PUT, GET, cancel, the customer tracking page — and source_store does not form part of that key. Two source stores reusing one order number are the SAME order to Get Plus.

Immutable after the first write. A replay or PUT that names a different id or a different name for an order that already exists is rejected with 409 SOURCE_STORE_CONFLICT; sending the identical value is the normal idempotent path. Omit the whole object and the stored value is kept unchanged. Not accepted in the POST /orders/{order_number}/cancel body (422).

Not shown to shoppers. It never appears on tracking pages, notification emails or SMS.

The order's tax, one entry per tax. When amounts.tax_total is sent, it is the order's tax; when it is not, the tax is these entries' amounts added up.