API changelog
Track how the Vantr API has moved from the first tagged API release through the current developer API. Release notes on this page are the developer-facing notes published for each deployed release; releases with no developer-facing note are listed by tag only.Current API package
v5.30.0
Developer spec
v2 contract 2026-06-09
First API tag
v1.8.7 on 2026-01-27
API upgrade path
v1.x
v1.8.7 to v1.11.8. Release automation and API service foundation.
v2.x
v2.0.0 to v2.11.7. Contract alignment, catalog workflows, inventory, purchasing, and Square sync expansion.
v3.x
v3.0.0 to v3.1.23. Stability, deployment hardening, and operational API work.
v4.x
v4.0.0 to v4.5.0. Current API line with stronger release notes, public contracts, and developer documentation.
v5.x
v5.0.0 to v5.30.0. API release line updates.
Version history
API tag
vantr-api-v1.8.7 opened the tracked API release line.API tag
vantr-api-v1.8.8 was published in the API release line.API tag
vantr-api-v1.8.9 was published in the API release line.API tag
vantr-api-v1.8.10 was published in the API release line.API tag
vantr-api-v1.8.11 was published in the API release line.API tag
vantr-api-v1.8.12 was published in the API release line.API tag
vantr-api-v1.8.13 was published in the API release line.API tag
vantr-api-v1.9.0 was published in the API release line.API tag
vantr-api-v1.9.1 was published in the API release line.API tag
vantr-api-v1.9.2 was published in the API release line.API tag
vantr-api-v1.10.0 was published in the API release line.API tag
vantr-api-v1.10.1 was published in the API release line.API tag
vantr-api-v1.10.2 was published in the API release line.API tag
vantr-api-v1.11.0 was published in the API release line.API tag
vantr-api-v1.11.1 was published in the API release line.API tag
vantr-api-v1.11.2 was published in the API release line.API tag
vantr-api-v1.11.3 was published in the API release line.API tag
vantr-api-v1.11.4 was published in the API release line.API tag
vantr-api-v1.11.5 was published in the API release line.API tag
vantr-api-v1.11.6 was published in the API release line.API tag
vantr-api-v1.11.7 was published in the API release line.API tag
vantr-api-v1.11.8 was published in the API release line.API tag
vantr-api-v2.0.0 was published in the API release line.API tag
vantr-api-v2.0.1 was published in the API release line.API tag
vantr-api-v2.1.0 was published in the API release line.API tag
vantr-api-v2.1.1 was published in the API release line.API tag
vantr-api-v2.2.0 was published in the API release line.API tag
vantr-api-v2.3.0 was published in the API release line.API tag
vantr-api-v2.3.1 was published in the API release line.API tag
vantr-api-v2.3.2 was published in the API release line.API tag
vantr-api-v2.4.0 was published in the API release line.API tag
vantr-api-v2.4.1 was published in the API release line.API tag
vantr-api-v2.4.2 was published in the API release line.API tag
vantr-api-v2.4.3 was published in the API release line.API tag
vantr-api-v2.4.4 was published in the API release line.API tag
vantr-api-v2.5.0 was published in the API release line.API tag
vantr-api-v2.6.0 was published in the API release line.API tag
vantr-api-v2.7.0 was published in the API release line.API tag
vantr-api-v2.7.1 was published in the API release line.API tag
vantr-api-v2.7.2 was published in the API release line.API tag
vantr-api-v2.7.3 was published in the API release line.API tag
vantr-api-v2.7.4 was published in the API release line.API tag
vantr-api-v2.8.0 was published in the API release line.API tag
vantr-api-v2.8.1 was published in the API release line.API tag
vantr-api-v2.8.2 was published in the API release line.API tag
vantr-api-v2.9.0 was published in the API release line.API tag
vantr-api-v2.9.1 was published in the API release line.API tag
vantr-api-v2.10.0 was published in the API release line.API tag
vantr-api-v2.10.1 was published in the API release line.API tag
vantr-api-v2.10.2 was published in the API release line.API tag
vantr-api-v2.11.0 was published in the API release line.API tag
vantr-api-v2.11.1 was published in the API release line.API tag
vantr-api-v2.11.2 was published in the API release line.API tag
vantr-api-v2.11.3 was published in the API release line.API tag
vantr-api-v2.11.4 was published in the API release line.API tag
vantr-api-v2.11.5 was published in the API release line.API tag
vantr-api-v2.11.6 was published in the API release line.API tag
vantr-api-v2.11.7 was published in the API release line.API tag
vantr-api-v3.0.0 was published in the API release line.API tag
vantr-api-v3.0.1 was published in the API release line.API tag
vantr-api-v3.0.2 was published in the API release line.API tag
vantr-api-v3.0.3 was published in the API release line.API tag
vantr-api-v3.0.4 was published in the API release line.API tag
vantr-api-v3.0.5 was published in the API release line.API tag
vantr-api-v3.0.6 was published in the API release line.API tag
vantr-api-v3.0.7 was published in the API release line.API tag
vantr-api-v3.0.8 was published in the API release line.API tag
vantr-api-v3.1.0 was published in the API release line.API tag
vantr-api-v3.1.1 was published in the API release line.API tag
vantr-api-v3.1.2 was published in the API release line.API tag
vantr-api-v3.1.3 was published in the API release line.API tag
vantr-api-v3.1.4 was published in the API release line.API tag
vantr-api-v3.1.5 was published in the API release line.API tag
vantr-api-v3.1.6 was published in the API release line.API tag
vantr-api-v3.1.7 was published in the API release line.API tag
vantr-api-v3.1.8 was published in the API release line.API tag
vantr-api-v3.1.9 was published in the API release line.API tag
vantr-api-v3.1.10 was published in the API release line.API tag
vantr-api-v3.1.11 was published in the API release line.API tag
vantr-api-v3.1.12 was published in the API release line.API tag
vantr-api-v3.1.13 was published in the API release line.API tag
vantr-api-v3.1.14 was published in the API release line.API tag
vantr-api-v3.1.15 was published in the API release line.API tag
vantr-api-v3.1.16 was published in the API release line.API tag
vantr-api-v3.1.17 was published in the API release line.API tag
vantr-api-v3.1.18 was published in the API release line.API tag
vantr-api-v3.1.19 was published in the API release line.API tag
vantr-api-v3.1.20 was published in the API release line.API tag
vantr-api-v3.1.21 was published in the API release line.API tag
vantr-api-v3.1.22 was published in the API release line.API tag
vantr-api-v3.1.23 was published in the API release line.API tag
vantr-api-v4.0.0 was published in the API release line.API tag
vantr-api-v4.1.0 was published in the API release line.API tag
vantr-api-v4.2.0 was published in the API release line.API tag
vantr-api-v4.2.1 was published in the API release line.API tag
vantr-api-v4.2.2 was published in the API release line.API tag
vantr-api-v4.2.3 was published in the API release line.API tag
vantr-api-v4.2.4 was published in the API release line.API tag
vantr-api-v4.2.5 was published in the API release line.API tag
vantr-api-v4.2.6 was published in the API release line.API tag
vantr-api-v4.3.0 was published in the API release line.API tag
vantr-api-v4.4.0 was published in the API release line.API tag
vantr-api-v4.5.0 was published in the API release line.API tag
vantr-api-v5.0.0 was published in the API release line.API tag
vantr-api-v5.0.1 was published in the API release line.API tag
vantr-api-v5.1.0 was published in the API release line.API tag
vantr-api-v5.2.0 was published in the API release line.API tag
vantr-api-v5.3.0 was published in the API release line.API tag
vantr-api-v5.4.0 was published in the API release line.API tag
vantr-api-v5.4.1 was published in the API release line.API tag
vantr-api-v5.4.2 was published in the API release line.API tag
vantr-api-v5.4.3 was published in the API release line.API tag
vantr-api-v5.5.0 was published in the API release line.API tag
vantr-api-v5.6.0 was published in the API release line.API tag
vantr-api-v5.6.1 was published in the API release line.API tag
vantr-api-v5.6.2 was published in the API release line.API tag
vantr-api-v5.6.3 was published in the API release line.API tag
vantr-api-v5.6.4 was published in the API release line.API tag
vantr-api-v5.7.0 was published in the API release line.- GET /purchasing/catalog no longer discards an
urgencyfilter when the matching set is small: the Typesense drift check compared a post-filter count against a Postgres count that cannot apply urgency, so narrow buckets fell back to the unfiltered SQL path.
API tag
vantr-api-v5.7.2 was published in the API release line.API tag
vantr-api-v5.7.3 was published in the API release line.API tag
vantr-api-v5.8.0 was published in the API release line.API tag
vantr-api-v5.8.1 was published in the API release line.- GET /v1/changelog now returns published release notes grouped by release, each with the version and the date it reached production. The response is {success, channel, releases} and the legacy audience parameter is ignored.
- Action required: Read release notes from releases[].notes instead of the previous flat entries array; each release carries releaseEventId, version, and deployedAt.
API tag
vantr-api-v5.10.1 was published in the API release line.API tag
vantr-api-v5.10.2 was published in the API release line.API tag
vantr-api-v5.11.0 was published in the API release line.API tag
vantr-api-v5.12.0 was published in the API release line.API tag
vantr-api-v5.12.1 was published in the API release line.API tag
vantr-api-v5.13.0 was published in the API release line.API tag
vantr-api-v5.14.0 was published in the API release line.- Purchase order status gains partially_received and is now derived from receipt totals. A new POST /purchasing/purchase-orders/:id/close-short records that an undelivered remainder is written off; it requires a reason and applies only to a partially received order.
- PATCH /v1/bills/:billId no longer fails when a bill is submitted again after being sent back from review. Lines whose stock was already received on an earlier submit are skipped rather than re-applied, so re-submitting does not double inventory and does not error.
- A bill can now be linked directly to the goods receipts it is charging for, including deliveries that arrived with no purchase order. Submitting the bill no longer posts inventory for product variations those receipts already recorded. Manage the links with GET, POST and DELETE on /v1/purchasing/bills/{bill_id}/goods-receipts, or record one when receiving by passing invoice_id to POST /v1/purchasing/goods-receipts.
- GET /v1/purchasing/bills/{bill_id}/receipt-variance returns ordered, received and billed per product in base units, with a per-line status (matched, short, over, not_received, not_billed), price variance and the amount at stake. Received comes from goods receipts confirmed against the bill. Read-only.
- Submitting a bill no longer posts inventory for product variations a confirmed goods receipt has already recorded against the matched purchase order. Lines the receipt did not cover are still posted by the bill, and bills with no confirmed match are unaffected.
- With bills.require_receipt_match enabled, approving a bill now checks each line against confirmed goods receipts (in base units, using accepted quantity). A line billed for more than was received is refused with RECEIPT_MATCH_REQUIRED unless an active return, a confirmed match, or a receiving missing-reason covers it, and a line with no confirmed receipt at all is refused. Previously the setting could not block any bill.
- POST /purchasing/goods-receipts posts a receipt for a delivery with no purchase order behind it, taking a vendor, a location and lines identified by product variation, with the same rejection, lot and cost capture as an order-based receipt. Repeating a command_id replays the original receipt rather than posting the stock again.
- The PIN endpoints (POST /v1/pos/auth/pin, POST /v1/pos/timeclock/clock-in, POST /v1/employees/pin/verify and the manager-override PIN on returns) share one budget of 10 attempts per minute per device and answer 429 with Retry-After when it is exceeded, including a manager PIN entered for an override. POST /v1/employees/{id}/pin shares that budget per caller, and additionally answers 400 for a predictable PIN (repeats, runs) and 409 when another team member in the tenant already holds that PIN. Every PIN stored before this release is invalidated and must be set again before a register will accept it.
- Action required: Set a new PIN for every employee who uses a register, before their next shift. In the web app: People -> Staff -> open the person -> Set POS PIN. A profile showing “POS PIN: Not set” is one that still needs doing. PINs must now be unique within your business and cannot be repeats or runs such as 1111 or 1234.
- Register sales now post to the right accounts. Cash stays in a till account until you actually deposit it, instead of being added to your bank balance the moment the sale rang up — which had been counting the same money twice on cash-basis reports. SNAP/EBT, WIC, gift cards and cheques each get their own account rather than being lumped in with card settlements, so you can reconcile each one against the party that actually pays it, on its own timeline. Gift card redemptions now correctly reduce your outstanding gift card balance instead of looking like a card payment. Refunds go back to the same account the sale came from.
- A bill paid through your Ramp connection is now recorded once rather than kept as two separate records that had to be reconciled against each other. Bills paid through Ramp now follow exactly the same approval path as every other bill, so they appear consistently everywhere in your books.
- Closing a month now correctly stops if you still have draft invoices in it. Previously that check looked at the wrong place and could never fire, so a period could be closed with unissued invoices left unaccounted for.
- If your bank drops a transaction that had already been categorized or matched to a bill, the accounting entry it created is now reversed rather than left behind. Previously your books could keep a categorization for a transaction that no longer existed. Transactions inside a completed reconciliation are left untouched and flagged instead, so a signed-off period is never changed behind your back.
- A sale rung up on the register and then synced from Square is no longer counted twice in your books. Previously the two could be recorded as separate sales, overstating revenue and making the day’s totals disagree with Square’s own settlement report.
- Damaged, expired and stolen stock now reliably reaches your books. Previously, if your chart of accounts was missing the account these write-offs post to, they were recorded against your inventory but never appeared as a cost - so your balance sheet inventory drifted from what was actually on the shelf. The missing accounts are now created automatically.
- Rotating the security credentials on a bank connection can no longer break it. Previously, if anything went wrong at the moment the new credential was issued, the connection was left unusable and the bank had to be reconnected from scratch. Vantr now verifies everything it can before starting, retries the save if the database hiccups, and - if it truly cannot recover - tells you straight away that the connection needs reconnecting instead of leaving you to find out later.
- Vantr now catches a common and expensive mistake in the bank feed. When a card, SNAP or WIC payout lands in your account, that money was already recorded as revenue when the sale rang up at the register - so filing the deposit as income counts it twice and overstates your sales. Vantr now recognises those payouts and tells you which account to use instead, naming the processor it spotted. You can still override it if you know better, and ordinary deposits are untouched.
- The encryption key protecting accounting notes and descriptions can now be replaced on a routine schedule without any downtime and without losing access to anything already stored.
- An entry dated on a daylight-saving changeover day is now always recorded on the day you intended. In certain time zones it could previously be recorded a day early, which at the end of a month meant it landed in the wrong accounting period.
- A closed accounting period can no longer be quietly returned to open through the unlock action. Reopening a closed period now has to go through the reopen action, which clears the close properly and records who did it.
- A bill, line, return, comment or chat id that is not a UUID now answers 404 instead of 500. Malformed values in location_id, itemIds, source_upload_id and source_group_id answer 400 with a code rather than failing as a server error.
- PATCH /v1/bills/:billId now distinguishes why a submit failed instead of always answering 500. A write conflict with another submission is retried automatically, and answers 409 BILL_SUBMIT_CONTENTION if it persists. A bill whose location is missing, or a line matched to a deleted product, answers 409 with a specific code and the offending bill line id in the response details. Only an unexpected fault is still a 500.
- POST /v1/bills/:billId/items, …/returns, …/returns/batch, …/comments and …/reprocess now honour an Idempotency-Key header. Sending the same key replays the original response instead of creating a second record; requests without the header behave exactly as before.
- Bill endpoints now retry through transient database connection faults instead of failing the request, so a failover no longer surfaces as an error. When the connection pool is saturated the API answers 503 with a DB_POOL_TIMEOUT code rather than a generic 500, which is safe to retry after a short backoff.
- Correcting a bill line while the bill is sent back from review now reaches inventory. Re-submitting posts compensating movements for any line whose received quantity or unit cost has changed, so on-hand and weighted-average cost follow the correction; an unchanged line is still applied exactly once.
- POST /purchasing/purchase-orders/:id/receive/manual accepts lot_number, expiration_date and lot_unknown_reason per line, and stores them on the receipt line. A line supplying none records lot_unknown_reason ‘not_recorded’ rather than being refused; ‘no_lot_code’ states that the carton carries none. Supplying both a lot number and a reason is refused with LOT_CAPTURE_CONFLICT.
- New: GET /v1/timeclock/approvals (timeclock:read), POST /v1/timeclock/approvals and POST /v1/timeclock/approvals/{id}/reopen (both timeclock:manage). An open approval covering a punch’s location and date now makes PUT /v1/timeclock/entries/{id}, DELETE /v1/timeclock/entries/{id} and POST /v1/timeclock/entries/manual answer 409 with the period named in the error details; reopen the period to correct them. Period containment is evaluated in the location’s timezone, not UTC.
- GET /v1/purchasing/goods-receipts lists goods receipts, filtered by vendor_id, location_id, received_from, received_to and unlinked_only, each carrying its line count, accepted units and the bills claiming it.
- GET /v1/purchasing/bills/{bill_id}/goods-receipt-candidates scores this vendor’s unsettled deliveries against the bill and records each proposal above the confidence floor as a suggested link. Suggested links never suppress inventory. GET /v1/purchasing/bills/{bill_id}/goods-receipts now returns confirmed links only.
- GET /v1/purchasing/goods-receipts/latest returns a vendor’s most recent counted delivery with its lines, optionally scoped to a location. Attestations are skipped because they carry no lines.
- POST /v1/purchasing/goods-receipts accepts capture_grade: ‘attestation’ with no items, recording a receipt that moves no stock. ‘verification’ (the default) is the counted receipt and still requires items. An attestation carrying items, or a verification carrying none, is refused.
- New endpoint GET /app/products/{productId}/pricing-policies returns every variation-level pricing policy for a product in one request. The per-variation endpoint is unchanged.
API tag
vantr-api-v5.16.1 was published in the API release line.API tag
vantr-api-v5.16.2 was published in the API release line.API tag
vantr-api-v5.17.0 was published in the API release line.API tag
vantr-api-v5.17.1 was published in the API release line.API tag
vantr-api-v5.17.2 was published in the API release line.API tag
vantr-api-v5.18.0 was published in the API release line.API tag
vantr-api-v5.19.0 was published in the API release line.API tag
vantr-api-v5.20.0 was published in the API release line.API tag
vantr-api-v5.20.1 was published in the API release line.API tag
vantr-api-v5.20.2 was published in the API release line.- Count approval returns 409 with COUNT_RECOUNT_REQUIRED when another overlapping count correction occurred after capture. Recount the target before approving; retries of an already approved session remain idempotent.
API tag
vantr-api-v5.21.0 was published in the API release line.API tag
vantr-api-v5.21.1 was published in the API release line.API tag
vantr-api-v5.21.2 was published in the API release line.API tag
vantr-api-v5.21.3 was published in the API release line.API tag
vantr-api-v5.21.4 was published in the API release line.API tag
vantr-api-v5.22.0 was published in the API release line.API tag
vantr-api-v5.22.1 was published in the API release line.- Invoices whose continuation pages disagree on the invoice number now require identity review, with the original page numbers and invoice references preserved. Separate invoices are not automatically combined.
- Invoice extraction no longer duplicates products when an OCR table is read through both table cells and Markdown. Review checks also recognize the printed Net Invoice total independently of extracted line totals.
- Scanner warehouse responses now advertise shelf-area deletion support. The authenticated deletion endpoint retires unused areas with confirmation, scoped idempotency, and protection for assignments, stock, count records and stock-routing rules.
API tag
vantr-api-v5.24.0 was published in the API release line.API tag
vantr-api-v5.24.1 was published in the API release line.API tag
vantr-api-v5.24.2 was published in the API release line.API tag
vantr-api-v5.25.0 was published in the API release line.API tag
vantr-api-v5.25.1 was published in the API release line.API tag
vantr-api-v5.25.2 was published in the API release line.API tag
vantr-api-v5.26.0 was published in the API release line.API tag
vantr-api-v5.26.1 was published in the API release line.API tag
vantr-api-v5.26.2 was published in the API release line.API tag
vantr-api-v5.26.3 was published in the API release line.API tag
vantr-api-v5.26.4 was published in the API release line.API tag
vantr-api-v5.27.0 was published in the API release line.API tag
vantr-api-v5.28.0 was published in the API release line.- New customer endpoints: GET /customers/{id}/overview, GET /customers/balances and GET /customers/duplicates. GET /customers accepts type, linked, source, sort and include=metrics, and customers carry given_name, family_name, company_name, customer_type, source and email and SMS marketing consent.
- New GET /v1/integrations/square/sync-overview (domain cards, 14/30-day performance series, import history, review counts) with POST /v1/integrations/square/sync-overview/jobs/{jobId}/resume and /rerun, and GET /v1/orders/custom-amounts, which groups Square custom-amount lines by note over the same filters as GET /v1/orders. All are documented in the OpenAPI contract.
- GET /reports/daily-sales (per day) and GET /reports/sales-summary now return
lines, the ten Sales Summary lines in a shared SalesSummaryLines schema, including the newrefunds_by_amountandtotal_sales. Net Sales is items plus service charges, less pre-tax returns and discounts. The per-field figures are deprecated aliases of these lines. On daily sales,salesnow equals Net Sales, and money fields are JSON numbers.- Action required: If you read
salesfrom GET /reports/daily-sales as item sales before discounts, readlines.items - lines.returnsinstead. Move other reads tolinesbefore the deprecated fields are removed.
- Action required: If you read
- GET /reports/top-products items now carry units, units_returned, gross_sales, returns, discounts, net_sales and product_id, counted on each order’s store day.
revenue(now net sales after returns) andquantity(units sold) are deprecated aliases. GET /reports/location-performance locations now carrylines(SalesSummaryLines) andorder_count, and the response addstotal, the all-locations figure. Theirsales,net_sales,discountsandtaxare deprecated aliases of single lines;salesis Total Sales.- Action required: Read top products from net_sales and units, and location performance from
linesandtotal, instead of summing locations, before the deprecated fields are removed.
- Action required: Read top products from net_sales and units, and location performance from