QuickBooks Redirect URI: Why Localhost Gets Rejected
Quick Answer
QuickBooks rejects http://localhost as a redirect URI for production API keys because Intuit can't verify ownership of a local address. Localhost is allowed only with Development keys, which connect to sandbox test companies, never your real books. The fix is a small static page hosted on HTTPS, on a domain you actually own, that catches the OAuth callback and hands it to the script running on your own computer.
The first time we tried connecting our own agency's QuickBooks to an AI workflow, months before we got it working, this is exactly where it fell apart. Our script had a `.env` file pointed at `http://localhost:9090/callback`, which is standard practice for local OAuth development. It worked fine against the sandbox. The moment we switched the environment to production, Intuit rejected it outright.
Nothing was wrong with the code. The redirect URI rule is just different in production, and nobody tells you that until you hit it. Here's the rule, why it exists, and the page pattern that gets around it without standing up a real server.
Why localhost works in sandbox but not production
A redirect URI is where QuickBooks sends the browser back to after someone approves your app on the consent screen. It carries an authorization code in the URL, which your app then exchanges for an access token. Whoever controls that URL can potentially intercept that code, so Intuit needs some way to confirm the URL is a real, controlled destination.
For Development keys, which only ever touch fake sandbox data, Intuit trusts `http://localhost` because the worst case is someone poking around a test company. For Production keys, which touch a real business's real financial data, Intuit requires an HTTPS URL on a domain registered to you. No localhost, no bare IP address, no exceptions.
The fix: a small HTTPS callback page
You don't need a real backend server to satisfy this rule. A single static HTML page is enough, as long as it lives on a domain you own and loads over HTTPS. The page's only job is to read the `code` and `state` values QuickBooks appends to the URL and pass them along to the script actually running the connection on your computer.
In practice that means three small pages: a launch page (the link that starts the connection), a callback page (where QuickBooks sends the browser back), and a disconnect page. None of them store a secret. They're just static HTML, which means almost any host works, including a host you're already paying for.
How the hand-off actually works
- You click the launch link, which sends you to Intuit's consent screen.
- You approve access on your real QuickBooks company.
- QuickBooks redirects your browser to your HTTPS callback page, with the authorization code and a state value attached to the URL.
- The callback page tries to forward those values to a small listener your script opens on your own computer (typically `localhost:9090` or similar), closing the loop automatically.
- If that automatic hand-off can't reach your computer for any reason, a good callback page falls back to simply displaying the full URL on screen, so you can copy it and paste it into your script by hand.
That fallback step matters more than it sounds. Browser security settings, firewalls, and sleeping laptops all get in the way occasionally, and a callback page that just shows an error with nothing to do next will cost you more time than the manual paste ever does.
Where to host the callback page
Intuit requires a “host domain” and every URL has to live on it, so it needs to be a domain you actually own, not a free subdomain from a page-hosting service. Beyond that, almost anything works:
- Your existing website host. Upload the pages to a `/qbo/` folder and you're done.
- A free static host like Cloudflare Pages, GitHub Pages, or Netlify, pointed at a subdomain of a domain you already own.
- Builders like Squarespace, Wix, or Shopify generally can't host plain HTML files directly, so a subdomain on one of the free hosts above is the workaround.
Whichever you choose, check the exact URL in a browser before you enter it anywhere in the Intuit portal. The address has to match character for character, including `https` vs `http`, `www` vs no `www`, and any trailing slash.
Common mistakes
Adding the HTTPS URL to the wrong Redirect URI section
Development and Production each have their own Redirect URI list. Add your callback to Production and leave the sandbox localhost entry in Development.
A mismatch between the URL in your code and the URL in Intuit
Https vs http, a trailing slash, www vs no www, or a `.html` ending your host silently adds will all cause "invalid redirect_uri" even though the page loads fine in a browser.
No fallback when the local hand-off fails
If the callback page only tries to talk to your computer and shows nothing when that fails, you lose the authorization code entirely. Always display the full URL as a backup.
Assuming the page needs a real backend
It doesn’t. A static HTML file on any HTTPS host is enough, which means you don’t need to stand up or maintain a server just for this.
Already-built callback pages
The QuickBooks Agent for Claude Code ($29) includes the launch, callback, and disconnect pages already written, with the manual-paste fallback built in. Tell it your domain and it fills in the rest, then walks you through uploading them next to the production-keys step.
Get the QuickBooks Agent ($29)Frequently Asked Questions
Why does QuickBooks reject localhost as a redirect URI?▼
Because production redirect URIs must prove the request is going to a real, HTTPS-secured domain. Localhost only exists on your own machine, so Intuit can't verify it, and it allows it only for Development keys connecting to sandbox companies.
Can I use an IP address instead of localhost?▼
No. A bare IP address has the same problem as localhost: Intuit can't verify ownership of it. The redirect URI needs to be an HTTPS URL on a domain name you actually control.
Does the callback page need a server or a database?▼
No. It can be a single static HTML file. All it needs to do is read the authorization code and state that QuickBooks appends to the URL and hand them off to the script running on your own computer.
What if the automatic hand-off to my local script fails?▼
Build the callback page to show the full callback URL on screen as a fallback. You can then paste that URL into your local script manually and finish connecting that way.
Do Development and Production redirect URIs live in the same list?▼
No. Keys and Credentials has separate Redirect URI sections for Development and Production. Add your HTTPS callback to the Production section and leave your localhost entry in Development alone.
Related Reading
Written by
Sep Gaspari
Founder & Digital Marketing Strategist, Zio Advertising | Kelowna, BC
15+ years in digital marketing, Google Ads, and SEO. I've helped businesses across 12+ industries generate qualified leads and grow revenue through data-driven strategies. I don't just run campaigns, I obsess over results, test relentlessly, and treat your budget like it's my own.
Connect on LinkedIn→Based on our own QuickBooks connection setup, 2026. Sources: Intuit Developer help articles on redirect URI requirements and OAuth 2.0 integration tips.
