Hosted QuickBooks on Rightworks: Connecting Without Installing Anything

Quick answers

Can I integrate with QuickBooks Desktop running on a hosted desktop like Rightworks? Yes — through QuickBooks Web Connector, which ships with QuickBooks and is already installed on the hosted machine.

Do I have to install software on the hosted server? No. The customer imports a .qwc configuration file into the Web Connector; there is no agent, service, or executable to install.

Do I need inbound firewall rules or a static IP? No. The Web Connector makes outbound HTTPS calls to the gateway and polls for work; nothing connects inward to the hosted desktop.

How fast is it? Per the Web Connector guide, typical request latency is roughly 2–6 seconds at a 1-second poll interval, and up to the poll interval plus processing time at longer intervals.

Does QuickBooks have to stay open? Yes — keep QuickBooks running on the hosted desktop with the pinned company file open, signed in as the user whose session the Web Connector runs under.

---

The problem with hosted QuickBooks

A meaningful share of QuickBooks Desktop and Enterprise customers don't run the software on a machine they control. They run it on a hosted Windows desktop — Rightworks (formerly Right Networks), a generic RDS farm, Citrix, or a regional hosting provider. The customer logs in over RDP, QuickBooks is already there, and the file lives on the host's storage.

For an integration team, that setup breaks the standard playbook immediately. The usual approach to Desktop — install a small agent or connector service on the machine that has the company file — runs into a policy wall. Hosting providers generally do not let tenants install arbitrary executables or register Windows services. That's not an oversight; it's the product. They're running a managed, audited, multi-tenant Windows environment, and "customer installs an unknown binary that talks to the internet" is exactly what their change control exists to prevent.

So you get the support ticket that goes:

We'd love to use your integration but our QuickBooks is hosted and our provider won't approve the installer.

You can escalate it. Some providers will whitelist well-known vendors through a formal review process, which takes weeks and has to be redone per provider. Or you can use the one piece of software that is already approved, already installed, and already running on every QuickBooks Desktop machine: QuickBooks Web Connector.

Why the Web Connector is the right lever

QuickBooks Web Connector (QBWC) is an Intuit-shipped application that bundles with QuickBooks Desktop. Its entire job is to let a remote web service exchange qbXML with a local company file. It has been part of the Desktop ecosystem for roughly two decades, hosting providers know it, and because it ships with QuickBooks it is already inside their approved software inventory.

The mechanics matter for the firewall conversation:

• The Web Connector is a polling client. On a schedule, it calls out to a SOAP endpoint you specify and asks "do you have work for me?"
• All traffic is outbound HTTPS on 443 from the hosted desktop to the gateway.
• Nothing dials in. There is no listening port on the hosted machine, no inbound NAT rule, no VPN, no static IP requirement.

That is usually the end of the security review. "Software that already ships with QuickBooks makes an outbound HTTPS call to a vendor endpoint" is a dramatically easier sentence for a hosting support rep to approve than "please install this .exe and open a port."

The trade-off is real and worth stating up front: polling is not a persistent socket. You inherit the poll interval as a latency floor, and the connection only exists while QuickBooks is open and the Web Connector is running in that Windows session. More on both below.

How TenkeyBridge uses it

TenkeyBridge is a QuickBooks Online–compatible REST API that sits in front of a Desktop company file. Your application keeps speaking the QBO REST dialect — same OAuth2, same /v3/company/{realmId}/... paths, same query syntax — and the gateway translates to qbXML on the other side.

On a hosted desktop, the last mile of that translation is the Web Connector. Your POST /v3/company/{realmId}/invoice arrives at the gateway, gets queued as a qbXML request for that company, and the Web Connector picks it up on its next poll, hands it to QuickBooks through the SDK, and posts the response back. Your HTTP request stays open until the response comes home.

The important part from your side: the request/response shape is identical to every other TenkeyBridge connection mode. You don't write a hosted-specific code path. If you've already read the checklist for pointing a QBO integration at Desktop, nothing on it changes because the customer is hosted.

The four setup steps

From the Rightworks guide, the customer-side setup is four steps. Someone with RDP access to the hosted desktop and admin rights in the company file has to do them — you can't do them for the customer, which is worth planning your onboarding flow around.

1. Create the connection and download the .qwc file

In the TenkeyBridge console, create a connection for the company. You get back a .qwc file — a small XML configuration document that tells the Web Connector which endpoint to call, what the application is named, and the unique identifier for this connection. Along with it you get a password for that connection.

The .qwc file is per-connection. Do not reuse one across companies.

2. Get the file onto the hosted desktop

This is the step people trip on, because hosted desktops are deliberately awkward about file transfer. Options, in rough order of how often they work:

• Copy/paste or drag-and-drop through the RDP session if the provider allows redirected drives.
• Email it to the account that's logged into the hosted desktop and save it from there.
• Upload through the provider's own file transfer portal.

It's a few kilobytes of XML, not an executable — which also helps if someone asks what it is.

3. Import it into the Web Connector

On the hosted desktop, open QuickBooks and sign in to the company file. Then launch QuickBooks Web Connector (it's in the Start menu, or under File → Update Web Services in QuickBooks) and choose Add an Application. Point it at the .qwc file.

QuickBooks will prompt for authorization. Grant access — including the "allow access even if QuickBooks is not running" option if offered, which avoids some re-prompting — and paste the connection password into the Web Connector's password field when asked. Save it when prompted.

4. Set the poll interval and run it once

Check the Auto-Run box for the application and set Every __ Min to the interval you want. Click Update Selected once to confirm the round trip works. The console shows the connection as healthy once the first poll lands.

The minimum interval the Web Connector UI exposes is one minute. TenkeyBridge's guide documents a mechanism for a faster effective poll — see the guide's latency section — but plan your UX around the possibility that a given install is on a one-minute cadence.

Latency: what to actually expect

The Web Connector guide states it plainly, and I'll state only what it states:

• At a 1-second poll interval, typical end-to-end request latency is about 2–6 seconds.
• At longer poll intervals, worst-case latency is roughly the poll interval plus processing time — a request that arrives just after a poll waits for the next one.

Design accordingly:

• Make calls asynchronous in your UI. Don't block a user-facing form submit on a Desktop write. Queue it, show pending, reconcile when the response lands.
• Batch where you can. Ten line items in one invoice costs roughly one round trip. Ten separate single-line invoices costs ten.
• Set client timeouts generously. A 5-second HTTP timeout will fail requests that were going to succeed. Minutes, not seconds, for the hosted path.
• Don't poll the gateway in a tight loop hoping to make the Web Connector go faster. It won't.

If your product depends on sub-second writes to the ledger, hosted Desktop over Web Connector is not the right fit, and it is better to find that out at architecture time than during a customer pilot.

QuickBooks has to be open

This is the single largest source of hosted-connection support tickets, so be explicit with customers about it.

The Web Connector talks to QuickBooks through the Desktop SDK, in the Windows session where QuickBooks is running. That means:

• QuickBooks must be running on the hosted desktop, with the pinned company file open.
• The hosted session must be alive. If the customer logs out of RDP rather than disconnecting, the session may terminate and take QuickBooks and the Web Connector with it. Most providers distinguish between "disconnect" (session persists) and "log off" (session ends). Customers need to disconnect.
• Company file switching breaks things. If someone opens a different company file in that QuickBooks instance, requests for the pinned file will fail until it's switched back. TenkeyBridge pins the connection to a specific company file precisely so this surfaces as a clear error rather than writing transactions into the wrong book.

Some providers idle-timeout sessions aggressively. That's a conversation to have with hosting support before go-live, not after.

Multiple company files

A customer with three company files needs three connections: three .qwc files, three applications in the Web Connector, three realmIds on your side.

The constraint is QuickBooks itself — one instance of QuickBooks Desktop has one company file open at a time. So three simultaneously active connections means either three separate hosted desktops (one QuickBooks instance each) or accepting that only the currently-open file is reachable and the others return errors.

The Web Connector handles multiple registered applications in one list fine; it polls each on its own schedule. The bottleneck is strictly which file QuickBooks has open. For the broader multi-user and hosted picture — concurrent users in the file, RDS farms, and what actually contends with what — the deeper write-up on multi-user and hosted Desktop goes further than I will here.

What to tell hosting support

When the customer opens a ticket with their hosting provider, the ticket usually resolves faster if it's framed correctly. Suggested wording for the customer to send:

We want to enable QuickBooks Web Connector on our hosted desktop to connect QuickBooks to a third-party web service. Web Connector is already installed as part of QuickBooks. We are not installing any new software — we are importing a .qwc configuration file. The Web Connector makes outbound HTTPS requests on port 443 to api.tenkeybridge.com. No inbound connections or firewall changes are required. Please confirm outbound HTTPS to that host is permitted and that our session will not be terminated on idle while QuickBooks is open.

Three things that make this land:

1. Lead with "already installed." The reviewer's main question is whether new binaries are entering the environment. The answer is no.
2. Name the direction of traffic. Outbound-only is the magic phrase.
3. Ask about idle session policy in the same ticket. It's the thing that breaks a week after setup, and it's cheaper to resolve now.

If your provider requires a formal application review even for Web Connector configurations, the Rightworks guide has the current details on what information to supply.

Troubleshooting

The failure modes are finite and mostly diagnosable from the Web Connector's own status column.

"QuickBooks was not running" / connection errors. QuickBooks is closed, or the wrong company file is open, or the hosted session ended. Check all three in that order.

Authentication failure on the first poll. Nearly always the connection password. Re-enter it in the Web Connector's password field for that application and save when prompted.

The application shows in the list but never polls. Auto-Run is unchecked, or the Web Connector itself isn't running. The Web Connector is an ordinary Windows application, not a service — if nobody started it in the session, it isn't polling. Have the customer add it to startup for the hosted session.

Requests time out but the Web Connector looks healthy. Check the poll interval. At a 15-minute interval, a request can legitimately sit for 15 minutes before pickup; that isn't a fault, it's arithmetic.

Access revoked after a QuickBooks update or file move. The SDK authorization is per-company-file. Re-grant it in Edit → Preferences → Integrated Applications in QuickBooks.

A request returns an error you don't recognize. The gateway maps Desktop status codes into QBO-shaped fault objects, but the underlying cause is still a qbXML condition. The guide to decoding Desktop errors covers how those map and what the common codes actually mean.

Full troubleshooting detail — including the specific Web Connector status strings — is in the Web Connector guide.

Where this leaves you

Supporting hosted QuickBooks customers doesn't require a different integration. It requires a different last mile — one that respects the fact that you will never be allowed to put code on that machine.

The honest summary of the trade: you give up low latency and you take on a customer-side setup that someone with RDP access has to perform once. You get, in exchange, a connection path that hosting providers already permit, no inbound network surface, and the same REST API you were already calling.

Before you commit, check which objects and fields you actually need against the Desktop parity matrix — the gaps between QBO and Desktop are independent of how you connect, but they're the other half of the feasibility question.