Security and data retention

Desktop Accounting API passes accounting data between your servers and your customers’ QuickBooks Desktop. This page describes what we store, for how long, and how credentials are protected. The security page summarizes our practices, the subprocessor list names every provider that processes data, and the Data Processing Agreement applies to every customer.

How data flows

1. Your server calls api.desktopaccountingapi.com over HTTPS with a secret key.
2. We queue the request for the end user’s connection.
3. The QuickBooks Web Connector on your customer’s computer polls qbwc.desktopaccountingapi.com over HTTPS (TLS 1.2 or newer), receives the request and returns QuickBooks’ response.
4. We return the response to your server.

Nothing connects into your customer’s network. The Web Connector only makes outbound HTTPS requests.

What we store

We do not keep a copy of your customers’ books. We store what is needed to run and troubleshoot requests:

Data	Kept for
Request metadata: operation, status, timeline, timings, error, native QuickBooks status	30 days
Request and response bodies	15 days, or 24 hours after completion when payload capture is off
Cached cursor pages, so a page can be fetched again after a network error	1 day
Idempotency keys and their stored responses	7 days
Webhook delivery attempts	30 days
Web Connector session records	30 days
End users and connection details (company name, QuickBooks product and version)	Until you delete the end user

Payload capture is on by default so the dashboard request log can show response bodies. A project can turn it off under Settings. With capture off, bodies are deleted 24 hours after the request completes, which leaves time for a retry to return the same result.

Deleting an end user removes its connection and Web Connector credentials immediately. Its stored request data is removed by a background deletion that retries until it completes, normally within 24 hours and never later than the 15-day body expiry.

The dashboard masks personal and payment fields when it shows bodies.

What we never receive

• Social Security numbers and full credit card numbers. Our connector tells QuickBooks it does not need personal data, so QuickBooks never sends those fields.
• QuickBooks passwords. Your customer signs in to QuickBooks on their own computer; we never see their QuickBooks login.

Credentials

Credential	Protection
Secret keys	Shown once. Stored only as a keyed hash; we cannot show a key again. Revocation takes effect within 30 seconds.
Web Connector passwords	Generated per installation, 32 random characters. Shown only during setup; afterwards stored only as a keyed hash.
Setup links	Single end user, time-limited (15 minutes to 7 days). The secret in the link becomes a secure cookie on first load and disappears from the address bar.
Webhook signing secrets	Encrypted at rest. Every delivery is signed (Standard Webhooks, HMAC-SHA256).
Dashboard accounts	Email verification, passwords of 12 or more characters, rate-limited sign-in, sessions revoked on password reset.

Our logs never contain authorization headers, Web Connector passwords, setup secrets, cookies or accounting bodies.

Isolation

• A secret key can reach only the end users in its own project. Requests for another project’s end user return 404, without revealing that it exists.
• Each connection’s queue and stored data are separated by project and connection.
• Test and production projects are fully separate, with different keys.

Your responsibilities

• Keep secret keys on your servers, in a secret manager, and rotate them when people leave or a key may have leaked.
• Send setup links only to the customer they are for.
• Verify webhook signatures and reject old timestamps.
• Show customers userFacingMessage, not message, which can contain IDs meant for you.

Reporting a vulnerability

Report security problems through our contact page, starting your message with “Security report”. Our vulnerability disclosure policy describes scope and safe harbor.