Changelog 2026-09-07

Sep 7, 2026 - 4 min read - 805 words

Your bank accounts are now in the API, metadata stops overwriting itself, and payloads we had started refusing are welcome again.

Banking, opened up

Bank accounts and their transactions are now part of the API.

Accounts:

GET /v1/BankAccounts and GET /v1/BankAccounts/{id}
POST /v1/BankAccounts to create one, PUT /v1/BankAccounts/{id} to update it
DELETE /v1/BankAccounts/{id}
POST /v1/BankAccounts/SetAsMain/{id} — moves the main-account designation from whichever account holds it, since exactly one account is main at a time

Transactions, read-only:

GET /v1/BankAccounts/{id}/Transactions — paged, with from, to, searchTerm, hideExcluded and hideReconciliated
GET /v1/BankTransactions/{id}
POST /v1/BankTransactions/Exclude/{id} and POST /v1/BankTransactions/Include/{id} — set a transaction aside so it stops being offered for reconciliation, or bring it back

Connected accounts are read-only

An account synchronized from a provider mirrors what that provider reports, so Altoviz is not its system of record and neither are you.

Every account carries a provider object — type, accountId, accountStatus, bankName — which is null on an account you keep by hand, and a connected flag that says the same thing. One null check tells you whether an account is yours to write to.

PUT and DELETE on a connected account return 400. Disconnect it in Altoviz first.
The provider fields are never writable, on any account. They are absent from the create and update bodies entirely.

Setting the main account and excluding or including a transaction still work on a connected account: those are Altoviz’s own bookkeeping, not something the provider owns.

Deleting is deliberately hard to do by accident. Beyond the connected check, DELETE returns 409 when the account holds any transaction already reconciled with a receipt or a payment, and 400 when the account is the main one. What gets through is an account created by mistake or never used — which is the only kind you should be deleting through an API, because deletion also removes the account’s accounting journal and every entry in it.

Metadata that stops fighting you

metadata is now available on customers and products. It was already stored and already used — the WooCommerce import writes woocommerce_product_id, Quickbooks writes qbo_id — you just could not read it back.

More importantly, metadata is now a patch everywhere the API carries one:

keys you send are added or updated
keys you leave out keep whatever they held
a key is removed only when you send it as null
"" stores an empty value, it does not remove anything
omitting the property entirely leaves the whole bag untouched

The bag is shared. Your integration is not the only thing writing to it, and replacing it wholesale meant sending your own single key silently dropped everyone else’s.

⚠️ Breaking change: if you relied on omitting a key to remove it, send that key as null instead. This affects invoices, quotes, credits, receipts, colleagues, MarkAsPaid and MarkAsRefunded, which previously replaced the whole bag.

Finding documents you didn’t create

Find accepted an internal id and nothing else — the one key a document created inside Altoviz never has. So documents made in the app were invisible to it.

GET /v1/SalesQuotes/Find, /v1/SalesInvoices/Find and /v1/SalesCredits/Find now take a number alongside internalId, matching customers and products. When both are given, internalId wins.

A draft carries a provisional number from its own sequence (000001) until finalization assigns the real one (FA001000), so a search by number can match either.

GetByInternalId also spread beyond the three resources that had it:

GET /v1/Products/GetByInternalId/{internalId}
GET /v1/Receipts/GetByInternalId/{internalId}
GET /v1/SalesQuotes/GetByInternalId/{internalId}, and the same for SalesInvoices and SalesCredits

Sales, with an s

Sale documents were the only place in the API spelled without one. /v1/Exports/SalesInvoices always had it; /v1/SaleInvoices did not.

The canonical routes are now /v1/SalesInvoices, /v1/SalesQuotes and /v1/SalesCredits.

Nothing breaks. Every /v1/Sale* route is still served, returns exactly the same result, and is simply flagged deprecated in the specification, naming the route that replaces it. Move when it suits you.

We stopped being picky

Some payloads that had worked for years started coming back 400. Loosely-typed clients send what they send, and we had quietly narrowed what we accept. That is fixed, and now guarded by a test that re-types every field of every published model and asserts we still accept whatever we used to.

Accepted again:

a number where a string is declared — "woocommerce_order_id": 3587755
"true", "1", "0" or "" where a boolean is expected
"" where an optional number, date or enum is expected

⚠️ One exception, on purpose: a quoted number carrying a group separator, like "1,5", is now refused with a 400 naming the field. It used to be read as 15 — a silent factor of ten, on money. "1.5", "1000" and 1000 are unaffected.