Privacy Policy
How the Integration Runtime Engine handles the data it holds on behalf of the products that use it and the customers who connect their accounting systems to it.
1. Who this policy is for
The Integration Runtime Engine (“the Service”) is infrastructure. It sits between software products and the external systems those products integrate with — today, QuickBooks Online. It has no user interface of its own that an end customer signs into.
That means two different people are affected by this policy, in different ways:
- Product operators — the businesses whose software calls the Service. They are our direct customers, and they decide what data is sent to us.
- Their customers — the businesses and people who use those products and who connect their own QuickBooks company. Their accounting connection is held by us, so this policy is written to be readable by them too.
In data-protection terms, the product operator determines what is collected and why; we process it on their instructions and for no other purpose. Where a product operator has its own privacy policy, that policy governs the relationship with their customers, and this one describes what the underlying infrastructure does.
2. Who we are, and how to reach us
The Service is operated by Ezeetel Inc. (“we”, “us”), a company incorporated in Canada, at Unit 214, 2250 Bovaird Drive East, Brampton, Ontario L6R 0W3, Canada.
For any question about this policy, about the data we hold, or to make a request under section 9, write to support@ezeetel.com. We aim to acknowledge within five business days.
3. What we hold, and why
These are the categories we hold. The table names in the right-hand column are the actual storage locations, so that this section can be checked rather than taken on trust — and section 7 says how long each is kept.
| What | Why we need it | Where it lives |
|---|---|---|
| Connection credentials — the OAuth access and refresh tokens issued when a customer connects their accounting company, and the identifier of that company | Without them we cannot make any request on the customer’s behalf. This is the core of what the Service does. | oauth_tokens (encrypted) |
| Connection metadata — the connected company’s name as the provider reports it, the permissions granted, the identifier of the person in the product who performed the connection, and connection health | To show which company is connected, to detect an expired or revoked grant, and to tell the product operator when a connection needs attention. | connections, connection_health |
| Operation records — for each attempted operation: which tenant, which connection, which operation, the identifier of the object in the product, the identifier of the object at the provider, timing, attempt count, and an error code if it failed; for an explicitly result-bearing operation, this also includes the bounded business result returned to the product | To avoid performing the same write twice, to let an operator diagnose a failure, to answer “what did this system do, and when”, and to let the product poll a completed job for its returned result. | sync_jobs, external_id_map, dead_letters |
| Connection attempts — for each attempt to connect an accounting company: the identifier of the person in the product who started it, where to return them afterwards, and the short-lived values that secure the exchange | So the authorisation handed back by the provider can be matched to the attempt that requested it, and so an attempt cannot be replayed or hijacked. | connect_sessions |
| Operation instructions — the request body a product sends us when it asks for an operation, stored in full | So a job can be retried without the product resending it, and so an operator can see exactly what was asked for. For a financial operation this is the content of the document to be created. | object storage |
| Provider notifications — the notification body an accounting provider sends us when something changes in a connected company | So we can tell which connection a change belongs to and act on it. For QuickBooks these are identifiers and change types, not document contents. | webhook_events |
| Notification records — for each outcome we report back to a product: the destination it was sent to, its encrypted signing secret, and the exact body that was delivered (identifiers and job status, never document contents) | So a product can be told what happened without polling us, and so a failed delivery can be retried with identical bytes and investigated. | outbound_webhook_endpoints, outbound_webhook_deliveries |
| Audit records — an append-only log of authenticated requests, credential lifecycle events, and operator actions | Security and accountability. These are the records that make it possible to investigate an incident. | audit_events |
We also process technical request data in the ordinary course of running a web service: the caller’s IP address, request timestamps, and request identifiers. The IP address is used to enforce optional per-customer address restrictions and to shed abusive traffic before authentication.
No IP address is written to a database record. But we should be precise rather than reassuring: when a request is refused by an address restriction or shed by the abuse limits, the address appears in our operational log stream, and that stream is exported to our own object storage. So a refused request does leave a record of where it came from. Nothing in the Service deletes those log files automatically; they are removed by an operator.
4. QuickBooks Online data
When a customer connects a QuickBooks company, Intuit issues us an access token and a refresh token scoped to the permissions the customer approved on Intuit’s own consent screen. We hold those tokens; no third party holds, brokers, or can read them.
What we read from QuickBooks:
- Company information and tax settings — to confirm the connection works, display which company is connected, and verify the company’s tax configuration before a qualified Invoice creation or update.
- Customer and item changes returned by QuickBooks — to reconcile QuickBooks identifiers already linked to product objects and identify stale or unmatched records.
- Selected Invoices, Payments, CreditMemos and RefundReceipts — read by their QuickBooks identifiers to verify requested changes, tax, balances and allocations. These verification and status reads do not import a copy of the customer’s ledger.
What we write to QuickBooks:
- Selected Invoice creation, sparse updates and voids, Payment records, CreditMemo creation and application, and RefundReceipt records, only when the current internal policy attestation and the exact global and tenant enablement gates qualify the request. Financial-document operations are disabled by default.
- The caller supplies existing QuickBooks CustomerRef and ItemRef values. The Invoice operation does not create or update Customer or Item records.
- Invoice updates retain the selected customer, existing sales lines and tax references and require an open unpaid sale without payment or credit activity. Invoice writes add no runtime marker or internal reference to Invoice fields. Payment and refund records are accounting entries; these operations do not move funds between bank accounts.
We do not pull a copy of a customer’s accounting ledger out of QuickBooks and keep it. What we read from QuickBooks is listed above, and it is used to complete the request rather than to build a store of our own.
Our use of QuickBooks data is limited to providing the integration the customer asked for. We do not use it for any other purpose, and we do not disclose it to anyone other than the product operator whose customer it is.
5. How we protect it
These are the measures actually implemented, described plainly enough to be verified against the Service’s behaviour.
- Credentials are encrypted at rest with AES-256-GCM. Encryption keys are themselves encrypted under a master key held as a platform secret and never written to the database.
- The identity of the owning product and customer is bound into the encryption itself. A stored credential decrypted in the wrong context does not produce the wrong answer — it fails to decrypt at all.
- Requests from product operators are authenticated with a signed message digest. The signature is verified before the Service writes anything, so an unsigned or wrongly-signed request cannot write to any database or alter any customer data. (It is still counted against the abuse-protection limits that run ahead of authentication — that is what makes them effective.)
- On the interface your product calls, every function that reads or writes customer data requires both the product identifier and the customer identifier — there is no optional filter to leave off, and an automated check refuses any new endpoint that has not been assessed against this rule. Our own operators have a small number of deliberate exceptions, so that a failed job can be triaged before anyone knows which customer it belongs to. Those paths are named individually in the code, are reachable only through our internal console behind single sign-on, and each one is recorded.
- Access tokens are read from encrypted storage for each individual call, never cached in memory between requests, and never written to logs.
- Log output passes through a redaction stage that removes credential-shaped values before anything is recorded.
- Operator access to the internal console is behind single-sign-on and is enforced by the Service itself, not only at the network edge.
6. Where it is stored, and who else processes it
The Service runs entirely on Cloudflare. Data is stored in Cloudflare’s distributed database and object storage. Two organisations are involved in processing, and only two:
| Who | What they do | What they receive |
|---|---|---|
| Cloudflare, Inc. | Hosting, compute, database, object storage, queueing, and access control for the operator console. This is the only infrastructure provider. | All data held by the Service, at rest and in transit. |
| Intuit Inc. | The connected accounting provider. Nothing reaches Intuit except by the customer’s own connection. | The OAuth grant, and the object data the product operator’s configuration sends — see section 4. |
That is the complete list. If it changes, section 12 describes how we will tell you.
Data may be stored and processed outside Canada, because Cloudflare operates a global network and Intuit operates from the United States. Where a customer is in a jurisdiction with cross-border transfer requirements, the product operator is responsible for making that disclosure to their own customers.
7. How long we keep it
| What | How long |
|---|---|
| Connection credentials | Until the connection is ended, and no automatic expiry applies — if nobody ends it, we hold them indefinitely. When a disconnect is processed the encrypted tokens are destroyed; section 8 explains how a disconnect happens today. |
| Connection and operation records | For as long as the product operator’s account is active. These are the records that make the integration idempotent and may include a bounded business result explicitly returned to the product; deleting them would risk creating duplicate objects in a customer’s accounting system. |
| Audit records (security and operator actions) | Kept indefinitely, and we would rather say so than quote a window we do not enforce. Two kinds of high-volume operational record — the log of authenticated requests, and a scheduled reconciliation heartbeat — are moved out of the live database after six months into compressed archive storage, which is verified before the original is removed. Every other audit record stays in the live database, and the archived copies are removed only when an operator removes them. |
| Operation request bodies | Stored when a product asks us to perform an operation, so the job can be retried and audited. No automatic deletion applies today — they are retained until someone removes them. |
| Notification records (what we sent back to a product) | Kept. No automatic deletion applies to the delivery records or to the destination configuration; a destination can be revoked, which stops delivery but does not remove the record. |
| Provider notifications (including the notification body) | 30 days after the notification reaches a final state. Notifications still under investigation are retained until they are resolved — at any age. |
| Coordination state | Kept for as long as the connection exists. Each connection has a small piece of working state holding the identifiers of operations in progress and the last error the provider returned; nothing removes it automatically. |
| Operational logs (including the IP address of a refused request) | Exported to our own object storage. No automatic deletion is configured in the Service; the files are removed by an operator. |
| Connection attempts | A connection attempt stops working 15 minutes after it starts. The record of the attempt is kept after that — expiry makes it unusable, it does not delete it — and we have no automatic deletion for these records today. Each holds the identifier of the person in the product who started the connection. |
We keep audit records because they are the only means of investigating a security incident after the fact, and because deleting them would remove the evidence that protects the very people whose data they concern. Our internal policy sets 24 months for platform-level records and 18 for product-level ones; today nothing enforces that as a deletion deadline, so the row above states what actually happens rather than what the policy aims for.
8. Ending a connection
A customer can end the connection between their QuickBooks company and a product at any time, from Intuit’s own app-management screen in QuickBooks Online. Doing so revokes our access immediately: our stored tokens stop working, and we cannot read or write anything in that company again unless the customer connects afresh.
When a disconnect is processed by us, we ask Intuit to revoke the grant and then destroy the stored access and refresh tokens. The record that the connection existed, and the audit trail of what was done through it, are retained under section 7 — those records no longer contain any credential.
9. Access, correction and deletion
Under Canadian federal privacy law, and comparable law elsewhere, a person may ask what personal information an organisation holds about them, ask for it to be corrected, and in defined circumstances ask for it to be deleted.
Because the Service is infrastructure, the right route depends on who is asking:
- If you are a customer of a product built on this Service, contact that product operator first. They hold the relationship with you, and they can ask us on your behalf. If you cannot reach them, write to us at support@ezeetel.com and we will help you identify the right party.
- If you are a product operator, write to support@ezeetel.com. We will confirm what is held for your account and act on a correction or deletion request.
Some records are not deletable on request. Audit records are retained for their stated period because they are security evidence, and mapping records may be retained where deleting them would cause duplicate documents to be created in a connected accounting system. Where we refuse a deletion, we will say which records and why.
10. Children
The Service is business software, sold to businesses. It is not directed at children and we do not knowingly process the personal information of anyone under 16. If you believe we have, write to support@ezeetel.com and we will remove it.
11. If something goes wrong
If we become aware of a security breach that creates a real risk of significant harm, we will notify affected product operators without undue delay, tell them what we know and what we are doing, and report to the relevant privacy authorities as required by law. Product operators are responsible for onward notification to their own customers.
To report a suspected vulnerability, write to support@ezeetel.com. We will not pursue legal action against anyone who reports a genuine issue to us in good faith, gives us reasonable time to fix it, and does not access or alter data belonging to anyone else.
12. Changes to this policy
We will update this policy when the Service changes. The effective date at the top always reflects the current version. For a change that materially widens what we collect, what we use it for, or who processes it, we will notify product operators directly at least 30 days before it takes effect.
13. Governing law
This policy is governed by the laws of the Province of Ontario and the federal laws of Canada that apply there.
A complaint about our handling of personal information can be made to us at support@ezeetel.com, and, if you are not satisfied with our response, to the Office of the Privacy Commissioner of Canada.