Skip to main content
POST
Integrating for the first time? Start with the Basket Lifecycle & Troubleshooting guide for behavioral context and common-mistake coverage.
Need to surface only the rewards that would apply to the current basket (e.g. an offers carousel before checkout)? Use Qualifying Rewards for a Basket — a read-only dry-run that shares this endpoint’s applicability check without redeeming anything.
A basket can be in one of the following states:
Only a single reward, points product, or promo code can be applied per order. Supplying a promo code together with a reward or points product returns a 400.
For more on the difference between locked rewards and points-product rewards when an order is voided or refunded, see Loyalty Best Practices — Rewards vs Points Products.

HTTP Request

Parameters

string
Basket unique ID. Partner-generated: your system creates this value and reuses it across every state transition for the same basket.
Required for all states other than checkout. A checkout request may omit the ID; every subsequent state (placed, billed, completed, voided, refunded) must send the same ID the basket was created with.
enum
required
Basket state (checkout, placed, billed, completed, voided, refunded)
string
required
When the order is wanted in (ISO 8601 in UTC). If this timestamp is not provided, Thanx assumes the order is wanted ASAP.Providing this timestamp allows Thanx to determine if a reward will be valid in the future (for example, for a weekend only promotion where the user orders in advance).
string
required
Thanx Location UID Providing this information allows Thanx to apply reward location restrictions.A mapping of Thanx location identifiers can be provided by the Thanx developer support team or fetched from the following endpoints depending on your integration type:
array(string)
Reward IDs to apply to the basket.These IDs must be obtained from the rewards field at the Get Account API response.If you are integrating with reward codes, provide the reward code here instead.
Currently only a single reward or points product can be applied to a basket. The request will 400 if multiple rewards or points products are specified in the request.
array(string)
Points Product IDs to apply to the basket.These IDs must be obtained from the points_products field at the Get Account API response.
Currently only a single reward or points product can be applied to a basket. The request will 400 if multiple rewards or points products are specified in the request.
string
Universal Promo Code support is being rolled out and must be enabled for your account by Thanx before it can be used. Contact your Thanx representative to request access.
A Universal Promo Code to apply to the basket, as a 1–64 character string.A promo code follows the same lifecycle as a reward:
  • checkout — the code is validated and the resulting discount is returned as a preview; nothing is redeemed yet.
  • placed / billed / completed — the discount is applied and the redemption is recorded (once per basket).
  • voided / refunded — any recorded redemption is released.
A promo code cannot be combined with a reward or points product. Supplying both returns a 400 — apply one or the other, not both.
A basket id is required when applying a promo code, and must be reused across every state update for the basket. The id keys the redemption and makes retries idempotent, so resending the same basket will not redeem twice.
A member is not required to apply a promo code. If the basket is associated with a member, the order still accrues loyalty as usual; if it is not, the discount is applied and the redemption is recorded, but the order does not accrue loyalty (there is no member to credit).
string
When to hold the applied reward until for this order, as an ISO 8601 timestamp with an explicit offset (Z or +hh:mm), for example 2026-12-24T18:00:00Z. Use it for orders placed well before they are billed, such as catering or scheduled orders. See Holding a reward for scheduled orders.Default: when omitted, a reward on a placed basket is released back to the user’s wallet about 2 days after the basket was placed (the release job runs every 2 hours, so in practice 2 days to roughly 2 days 2 hours), whether or not the order has been billed or voided.Validated on the checkout and placed states, so you learn before placing an order that a hold can’t be honored. Later states ignore the field. The value must be:
  • in the future, and at least 2 days from now
  • no more than 365 days from now
  • before the reward’s expiration (including a points product’s projected reward expiration). A hold_until equal to the expiration is rejected.
Re-sending placed with a later hold_until extends the hold; an earlier one never shortens it. Re-sending a hold_until the reward is already held through is accepted unchanged, even when it is under 2 days away. Omitting it on a re-send leaves the existing hold alone.
array(hash)
Array of payment methods
Currently only a single object is supported. If multiple entries are provided, only the first will be validated and the rest will be ignored.
array(hash)
required
Array of items
decimal
required
The subtotal of the basket in USD (before taxes & tips)
string
Currently either instore or online, defaults to online. This is used to adjust which configured product IDs are returned in the applicable reward and points product entities.

Response

string
Response ID
enum
Basket state (checkout, placed, billed, completed, voided, refunded)
string
Discount to apply

Holding a Reward for Scheduled Orders

By default, a reward on a placed basket is released back to the user about 2 days after the basket was placed. For orders placed well ahead of the day they are billed, send hold_until so the reward stays reserved for the order until then.
  1. checkout: send the event or fulfillment time as hold_until. If the reward would expire before that time, the request returns a 400 so you can ask the user to choose a different reward.
  2. placed: send the same hold_until. The reward is held until that time.
  3. billed: send the order as usual. Billing re-checks reward eligibility against the order_timestamp you send, so use the same fulfillment time throughout.
The hold ends at hold_until, when the reward is released back to the user’s wallet. Billing, voiding, or otherwise releasing the reward before then also clears the hold.
Placed with hold_until
If a reward expires before it can be billed, billed returns 400 This reward will expire before the order is fulfilled.

hold_until Errors

Each failure returns HTTP 400 with {"code": 400, "message": ...}.