Security overview

From Xero we read your contact list and each contact’s outstanding and overdue balance. That is the whole of it. We ask Xero only for the read-only contacts scope, so we cannot see individual invoices, bank transactions, payroll, or anything else in your ledger — not because we choose not to look, but because the access we hold does not permit it.

We never write to your ledger. The connection is read-only in both directions of that sentence: we cannot create, edit or delete anything in Xero.

We also hold the email addresses of the people you invite, and the insolvency notices we match against — the latter is public information from the New Zealand Gazette and the Companies Register.

In transit. Every connection carrying your data requires TLS 1.2 or better — your browser to Canari, Canari to Xero, and Canari to its database. TLS 1.0 and 1.1 are refused by every one of those endpoints. The site is HTTPS-only and sends HSTS with a two-year lifetime, so after a first visit your browser will not attempt plain HTTP at all.

At rest. The Xero access and refresh tokens — the credentials that would let someone read your ledger — are encrypted with AES-256-GCM before they are written to the database, using a key held only in the deployment environment and never in our source code. Anyone reading the database directly sees ciphertext, not tokens.

The database itself is hosted on Supabase, whose managed Postgres runs on encrypted storage as a platform default. That last point is a platform guarantee we rely on rather than one we operate — the token encryption above is ours, applied on top of it, and is what protects the credentials even from someone holding a copy of the database.

Canari has no passwords. You sign in with a one-time link sent to your email address, and the database is configured so that a password cannot be set on an account even by mistake. There is therefore nothing to guess, reuse across sites, or leak in someone else’s breach.

Access is invite-only: an address that has not been added to an organisation cannot request a sign-in link. Two-factor authentication via an authenticator app is supported for accounts that want it.

Between organisations, separation is enforced by the database itself through row-level security, not only by application code — so a bug in a page cannot expose another organisation’s customers.

Reads and writes of your Xero-sourced customer data are recorded to an append-only audit log: who, what, when, how many records, and whether it succeeded. Entries cannot be altered or deleted through the application, and you can be shown your own organisation’s trail on request.

Repeated failed sign-in attempts from one source raise an alert to the operator automatically.

If you believe you have found a vulnerability in Canari, or you think an account has been misused, email canari@verionventures.com with “security” in the subject line. Your report goes straight to the people who maintain Canari rather than into a general support queue, and you will get a reply from a person.

Please give us enough to reproduce the problem, and please do not access, modify or retain anyone else’s data while investigating. We will not pursue action against anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before publishing.

If we suffer a breach that poses a risk of serious harm, we will notify you and the Office of the Privacy Commissioner as the Privacy Act 2020 requires. Where Xero-sourced data is involved we will also notify Xero immediately at api@xero.com.

You can cut off our access at any time: from Settings in Canari, which revokes it at Xero in the same step, or from inside Xero under connected apps — that route takes effect immediately and does not require anything from us. See the privacy policy for retention and deletion, and for the full list of service providers who process data on our behalf.