Angible Edge API (20261027-6c2ff19)

Exchange a device client_id / client_secret for a session token. On success returns an access_token valid for 24 hours; each call issues a fresh token and prunes the caller's expired sessions. Set the returned token as the token header on all subsequent requests.

Recommended: handle token refresh. Every other request is authenticated and will return 403 ("Authorization error") when the token is missing, invalid, or expired. If a previously succeeding (200) session starts receiving 403, the token has almost certainly expired: call this endpoint again to obtain a fresh access_token, then retry the failed request.

Records that an item was added to the cart for the given transaction. The transaction must already exist and still be open — calls against a missing or already-finalized transaction are rejected.

Records that a previously added item was removed from the cart, identified by item_id. The transaction must already exist and still be open — calls against a missing or already-finalized transaction are rejected.

Updates the price of items already in the cart, each matched by item_id. The response reports how many items matched (modified) and any item_ids that were not found in the transaction or supplied with no price to set (unmatched_item_ids). The transaction must already exist and still be open.

To set final checkout prices, integrate either this endpoint or Finalized item prices (PUT /v1/{sco_id}/transactions/{transaction_id}/item-prices) — not both. Prefer this endpoint: because it matches per item_id, two units of the same barcode can take different prices (e.g. item1: $100, item2: $0).

Applies the final per-item prices (after promotions/discounts) to the transaction. Prices are matched to items by barcode; quantity sets how many units each price applies to, assigned in the order the items were added. Only items still in the cart (added and not since removed) receive a price, so it should be called once the cart contents are final (all item additions and removals settled).

To set final checkout prices, integrate either this endpoint or Update items (PATCH /v1/events/{sco_id}/items) — not both. Prefer Update items unless the SCO system cannot express prices as per-item lines and must aggregate by barcode instead.

Call this when a customer begins a checkout session on the SCO — typically when they tap Start or touch the screen.

Call this to discard a transaction that was started but will not be completed, so its transaction_id can be used again. Everything held locally for that transaction is deleted and nothing is sent to the cloud. A transaction can be reset whether or not items were scanned — the only requirement is that it has not been completed.

Call this to close the transaction — typically when payment is made or the receipt is printed. Every opened transaction must be closed. If the customer leaves the SCO idle partway through, close it with status=checkout_abandoned and open a new transaction for the next session rather than reusing the idle one.

Call this when the customer enters the scanning page — typically when the cart list appears on the screen.

Call this when the customer leaves the scanning page — typically when they tap Pay to move to the payment page.

Retrieve the record collected for a transaction — scan events, scanned items, states, alerts, and totals — for a given transaction_id on the SCO. Use it to confirm the submitted events were received.

Update how an AI alert was resolved. Prefer per-item results: give each entry in issue_items its own managed_result, so different items can carry different outcomes. A single whole-alert managed_result is the legacy pattern, used when every issue item shares the same outcome.

Test-only endpoint that switches the AI box between live AI processing and alert simulations for lab integration.

An alert only fires while an active transaction_id exists — sending a "scan start" signal alone will not trigger the simulation events. You can call this again with a different event_type at any time to switch simulations.

For item_left, each simulated alert varies its issue_items count (e.g. 1, then 2) to exercise UI testing.

Retrieve whether this AI box is currently in AI test mode and, if so, which event_type it is simulating.

Serves the image file referenced by issue_items[].image_path in the MQTT alert payload — use it to display the issue-item image for an alert.