Transaction data

There are two ways to get us your transaction data; we will agree on one before the Pilot starts.

The most important rule, whichever option you choose: every transaction must use the same transaction ID across your data and the video, and all times must be accurate to the second. This is what lets us match each transaction to its video.

Option A: Export your data as CSV

Please convert your POS data into the two CSV files below: one row per transaction and one row per scanned item, linked by transaction_id. Using this standard format lets us load your data directly, without building a custom parser for each POS system.

General rules

• CSV, UTF-8, with the header row exactly as named below.
• All times in local store time, to the second. Preferred: ISO 8601 with the UTC offset, e.g. 2026-11-01T09:36:00-04:00, which stays unambiguous when daylight saving time changes. If your POS cannot produce the offset, YYYY-MM-DD HH:MM:SS in local time is accepted, and each store's time zone must be listed in Store and SCO information.
• transaction_id is unique within a store and identical in both files.
• Keep voided items and voided or suspended transactions; do not delete them.
• No merged cells, subtotal rows or extra sheets.

File naming

Send one pair of files per store per business day, with all SCOs of that store in the same files. Do not split files by SCO.

{store_code}/{YYYY-MM-DD}/{store_code}_{YYYY-MM-DD}_transactions.csv
{store_code}/{YYYY-MM-DD}/{store_code}_{YYYY-MM-DD}_items.csv

For example: STR1/2026-11-01/STR1_2026-11-01_items.csv.

• The date is the local business date of the transactions inside the file, not the export date.
• To resend a file, add a version suffix (STR1_2026-11-01_items_v2.csv) instead of overwriting the original.

File 1: transactions.csv (one row per transaction)

Column	Required	Format	Example	Notes
transaction_id	Yes	Text	STR1-20261101-000456	Same value in items.csv
store_code	Yes	Text	STR1
sco_id	Yes	Text	A	Same ID as in Store and SCO information
transaction_start	Yes	YYYY-MM-DD HH:MM:SS	2026-11-01 09:36:06	First item scanned, or session start if logged
transaction_end	Yes	YYYY-MM-DD HH:MM:SS	2026-11-01 09:36:28	Payment completed (last payment if split)
status	Yes	completed / voided / suspended	completed
total_items	Recommended	Integer	1	Number of items paid for
amount_paid	Optional	Decimal	1.65

File 2: items.csv (one row per scan)

Column	Required	Format	Example	Notes
transaction_id	Yes	Text	STR1-20261101-000456
line_no	Yes	Integer	1	Order within the transaction
scan_time	Yes	YYYY-MM-DD HH:MM:SS	2026-11-01 09:36:06	Time this item was scanned or voided
item_code	Recommended	Text	012345	Your SKU or internal item code
barcode	Yes	Text	1234567890123	As scanned; for weighed or PLU items, the code used
item_name	Yes	Text	Mineral Water 1.5L
quantity	Yes	Whole number ≥ 1	1	Weighed or PLU items: 1
amount	Yes	Decimal	1.65	After discount
action	Yes	sale / void	sale	void = item removed or cancelled

How to fill the item columns

Each row in items.csv is one action at the checkout: an item added, or an item removed.

• quantity: number of units in this row, a whole number of at least 1. Scanning the same item three times can be three rows of 1 or one row of 3, if your POS records a multiplier. Weighed or PLU items always use 1 — their variable amount is captured in amount instead.
• amount: what was actually charged for this row after its discount, in local currency without a currency symbol. Use a positive number for void rows too; the action column shows the direction. This is what lets us estimate the dollar value of any discrepancy found, so please include it even if other item columns are missing.
• action: sale when an item is added. void when an item is removed during the transaction, by the customer or by staff: add a new row with the time of removal and keep the original sale row. A whole cancelled transaction does not use this column; set status to voided in transactions.csv instead.

Example of a weighed item: quantity=1, amount=4.05, action=sale.

If your system cannot produce a column, leave it out and tell us which ones are missing. We will confirm after the sample whether the data is usable.

Sending your files

Work in progress

How to share your files, the sample/format-check process, and the exact delivery schedule are still being finalized. In the meantime, contact your Angible representative.

Option B: Integrate the REST API directly

Instead of converting historical exports into the CSV files above, your POS can send transaction events to us live, as they happen — the same REST API used for the real integration later, just starting early. This skips the file-conversion and file-sending work entirely: no sample, no shared folder, nothing to send on a schedule.

These calls go to the AI Box already installed in your store for video (see Video stream) — the same box handles both, so there's nothing extra to install.

Required calls:

• POST /v1/events/{sco_id}/transaction-started
• POST /v1/events/{sco_id}/transaction-completed
• POST /v1/events/{sco_id}/scan-started
• POST /v1/events/{sco_id}/scan-completed
• POST /v1/events/{sco_id}/item-added

item-removed is optional for the Pilot — integrate it if your system already tracks it, otherwise it's fine to leave out.

Authentication works the same way as the full integration: see Authentication. See the Edge API reference for each call's full request and response.