Create Transaction Event

The Create Transaction Event function allows the Device to report the product
the user purchased to the Tiliter Recognition API.
This is used to close the loop on the transaction and record when the Device
was used to follow through and purchase a product.
This also eliminates irrelevant data from reports that may result from
incomplete transactions.
Every recognition requires a transaction report; if no transaction occurs,
that can also be reported.

Transaction events are reported per recognition, using the recognition_id
returned by the recognition request. There is no single report for the
whole transaction.
Each event must be reported within 30 minutes of its recognition. After that
the recognition can no longer be found and the request returns 404.
Events can be reported as they happen, or together once the transaction is
completed and paid using the Create Transaction Events In Batch function,
as long as each event is within 30 minutes of its recognition.

When loss is reported, use the following event types:
loss_actioned: store staff checked and it was loss, and the product was
removed from the cart.
purchased: store staff checked and it was not loss, and the product was
purchased. This tells us the loss report was incorrect and is used to
improve recognition.
loss_acknowledged: the shopper was asked to confirm (e.g. "are you sure?")
and proceeded anyway.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
uuid
required
Body Params
string
enum
required

Represents the various states and outcomes of a transaction. These states encapsulate all steps and outcomes, including successful completion, cancellation, and instances of loss. The enumeration includes intermediate states, like when a transaction is incomplete or a label is printed but the purchase is not yet concluded. These states are useful for tracking transactions in in-store scales or non-POS devices. Loss tracking states mark instances of theft or loss, and indicate whether action has been taken or just acknowledged. Finally, final stages of a transaction are included, such as the successful completion of a purchase or the cancellation. These states conclude a transaction from a POS device view.

purchased: the product was purchased, including when loss was reported but store staff checked and it was not loss.
loss_actioned: loss was reported, store staff checked and it was loss, and the product was removed.
loss_acknowledged: loss was reported, the shopper was asked to confirm and proceeded anyway.
transaction_cancelled: the transaction was cancelled.
transaction_incomplete: for in-store scales or other non-POS devices, the transaction was not completed.
label_printed: for in-store scales or other non-POS devices, a label was printed but the transaction was not completed.

Allowed:
date-time
required

The date and time at which the transaction event occurred

string
meta_data
object
Responses

429

Request Throttled - reduce request rate and retry

Language
Credentials
Header
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json