UltraCart HTTP 403 Error Troubleshooting Guide
Introduction
An HTTP 403 occurs when a server understands the request but refuses to authorize it. In UltraCart environments they fall into four groups:
- StoreFront and checkout customer issues
- Merchant Portal access issues
- API and integration errors
- Firewall and Web Application Firewall (WAF) blocks, including automation and AI tools
Application-level 403 errors and firewall blocks have different causes and different fixes. Classify which one you have before you start troubleshooting.
Quick-reference troubleshooting matrices
Find the row matching your symptom, then read across for the cause and the fix.
Customer-facing: StoreFront and checkout
| Symptom / Error Message | Most Likely Cause | Immediate Customer Fix | Merchant Prevention / Fix |
|---|---|---|---|
| “This site can’t be reached” during custom domain setup | DNS/SSL mismatch | Use temporary ultrastore domain | Complete SSL setup and allow propagation |
| “Access Denied” mid-checkout | Checkout session timeout | Refresh and restart checkout | Add session timeout UX guidance |
| “HTTP/1.1 403 - Your customer profile does not have permission” | Missing pricing tier | Log in with correct account | Assign proper pricing tier |
| “HTTP/1.1 403 Permission Denied” or “403 Forbidden” on every storefront page, in any browser, after browsing or searching quickly | Storefront rate limit exceeded for the shopper’s IP address; the block is temporary | Wait a while, then continue at a normal pace. Restarting the browser or computer does not clear it. | Send UltraCart support the shopper’s public IP address and the approximate time of the block. Support can confirm which rule triggered it and clear it if it is still active. |
Merchant-facing: portal and integrations
| Symptom / Error Message | Most Likely Cause | Immediate Fix | Prevention / Best Practice |
|---|---|---|---|
| Intermittent 403 resolved in incognito | Cached session or extensions | Clear cache; disable extensions | Reduce reliance on browser extensions |
| 403 on embedded checkout / mixed domain | Host/origin validation failure | Use primary domain | Avoid mixed-domain embeds |
| 403 after repeated attempts | Rate limiting / bot protection | Wait and retry | Implement CAPTCHA / reduce retries |
| “Permission denied” when uploading a file, then 403 Forbidden on every page, even after closing the browser or clearing cookies | The file name contains a character the firewall rejects (=, ;, ", or \), and your IP address is temporarily blocked | Wait for the block to clear, rename the file using only letters, numbers, hyphens, and underscores, and upload it again | Follow the file naming guidance before uploading |
Automation and bot detection
| Symptom / Behavior | Most Likely Cause | Immediate Fix | Prevention / Best Practice |
|---|---|---|---|
| Temporary lockout after multiple requests | Rate limit exceeded | Wait for block to clear | Reduce request frequency |
| 403 across all pages for several minutes | IP temporarily blocked | Wait and retry | Space out automated requests |
| Works in browser, fails in automation tool | Non-browser client | Run the task in a real browser | Drive an actual browser session rather than a scripted client |
| Works after a few minutes | Temporary block expired | Retry later | Stay within rate limits |
| Only fails from one IP | IP flagged | Change network or wait | Reduce request volume from a single address |
| Triggered after using a non-browser automation client | Raw HTTP, Python, or headless client rather than a real browser session | Switch to a browser-based automation tool | Use a tool that drives an actual browser instead of a raw HTTP client or headless script |
| Triggered immediately on script execution | Known non-browser client signature | Switch to browser-based automation | Do not point raw HTTP clients or header-spoofed headless scripts at the merchant UI |
FAQ
Why do customers get a 403 during checkout?
Usually a session timeout, an account restriction, or stale checkout state. Have the customer refresh and restart checkout, then confirm their account has the pricing tier the items require.
Why is a customer blocked from my whole store?
If a shopper gets a 403 on every page of the storefront, in more than one browser, the most likely cause is the storefront rate limit. It applies to all traffic from an IP address and trips when that address loads a large number of pages in a few minutes (by default, 100 pages in 5 minutes). It protects the store from bot and attack traffic, and a shopper who opens or searches many pages quickly can trip it too. The block is temporary and clears on its own.
There is no allowlist that exempts individual shoppers from the rate limit.
Send UltraCart support:
- The shopper’s public IP address. The shopper can find it by searching “what is my IP” in a browser on the same network.
- The approximate date and time of the block, with time zone.
- The page or search they were on when it started, if known.
When you reply to the shopper, tell them their access was paused after a lot of fast page loads and will work again shortly. Screenshots are not needed.
Why did uploading a file lock me out of UltraCart?
UltraCart’s firewall rejects uploads whose file name contains an equals sign, semicolon, double quote, or backslash, because those characters can be used to tamper with how an upload is read. When it rejects one, it also blocks your IP address for a short time, so every page returns 403 Forbidden until the block clears. Clearing cookies or restarting the browser does not help.
Rename the file using only letters, numbers, hyphens, and underscores, then upload it again. The file contents do not need to change. See Naming your upload file.
If the 403 continues after renaming, send UltraCart support your public IP address (search “what is my IP” on the same network), the time of the upload with time zone, the file name, and which upload tool you used.
Why am I getting 401 or 403 API errors?
Usually missing permissions or invalid API credentials. Confirm the API key is current and that its permissions cover the endpoint you are calling.
Why does my automation tool get blocked?
Two separate controls can block it, and they have different fixes.
The first identifies clients that are not real browsers, such as generic HTTP libraries and headless scripts, and blocks them. The second applies rate limits to all traffic. A tool can pass the first and still trip the second.
What triggers an automation block?
- Raw HTTP clients
- Headless instances that do not present as a standard browser
- Non-browser user agents
- Request rates above the limit, whatever the client
How do I fix an automation block?
- Use a browser-based automation tool that drives an actual browser, such as Claude in Chrome or another tool operating through a real Chrome or Chromium session, instead of scripting raw HTTP requests or a headless client with spoofed headers.
- Slow down request frequency. A real browser session is still subject to rate limits, so an automation tool that drives Chrome can earn a temporary block by exceeding them.
- Prefer the UltraCart REST API for programmatic integrations. Reserve browser automation for tasks that require the merchant UI itself.
What is the correct approach for automation?
Use:
- The UltraCart REST API for programmatic and integration work. It is the supported path and is not subject to the non-browser client block.
- A genuine browser-based automation tool when the task requires operating the merchant UI itself, kept within rate limits.
Avoid:
- Raw HTTP or Python clients, and headless scripts that spoof headers to impersonate a browser.
- Scraping the merchant portal UI outside a real browser session.
Conclusion
UltraCart HTTP 403 errors fall into four categories:
- Customer session and eligibility issues
- Merchant permissions and authentication
- Integration and configuration issues
- Firewall and bot detection, including automation and AI tools
Classifying the error first is what makes the rest of the troubleshooting fast.