RealSiteWorth

Docs

Troubleshooting

Sign-in link failures, degraded or stuck valuations, quota errors, billing questions, and how to reach support.

The fastest way through most problems is to read the reason field on the response, not the HTTP status. Every error payload also carries a request_id — include it if you contact support, because it lets us find your exact request in the logs.

"Account sign-up isn’t open yet." Sign-in sits behind a server-side launch flag that is checked before anything else on a sign-in-link request. While it is closed, every request for a link returns this message and no email is sent — that includes existing account holders, not only people creating an account for the first time. If you already have an account and see this, nothing is wrong with your account; the flag is closed. The anonymous valuation path keeps working without an account.

"Too many sign-in attempts. Please try again in a few minutes." Sign-in requests are rate limited per IP address, because each accepted request sends a real email. Wait for the window shown in the Retry-After header and try once more. Repeating the request faster does not help.

"Bot check failed. Please refresh and try again." The login form runs a bot check before any email is sent. Refresh the page so the check reloads, then submit again. Blocking third-party scripts or running an aggressive privacy extension can keep the check from completing.

"That sign-in link could not be completed. Start again on this device." Sign-in links are device-bound. A link opened on a different device or browser than the one that requested it fails. Request a fresh link from the device you actually want to sign in on, and do not forward links between devices.

No email arrived. Check spam, then request a fresh link. Each new request invalidates nothing on your account, so retrying is safe once the rate-limit window passes.

Valuation problems

The run failed with a 502. The reason tells you which of three distinct failures happened:

ReasonWhat happenedWhat to do
blockedThe target site refused our requestNothing on your side is wrong; try later or value the bare domain
unreachableThe target could not be reached at allCheck the URL resolves publicly; retry
too-thinNo measurable traffic on a paid runThere is not enough data for a business valuation; run it as a domain

On a free run, a site with no measurable traffic does not error — it falls back to a bare-domain (Mode C) valuation instead.

A social or creator page shows "needs verified signals" instead of a number. No provider in the chain resolved public signals for that handle, so the run came back fully degraded. A degraded run is refunded — it does not cost quota. Check the handle spelling, then try again later. For TikTok, Instagram, X, and Facebook you can also supply the numbers yourself through the overrides field described in What you can value.

The band is very wide, or confidence reads LOW. Confidence measures how many signals were actually collected, and each missing signal widens the band. The two levers, in order: sign in (a signed-in free run pulls more data sources than an anonymous one), and read the "What we did not include" section of the Memo to see exactly what was missing. Also note the free display cap: free-run confidence is capped at LOW / 35% before display, so a paid run can legitimately show the same asset with higher confidence. Details in Reading your report.

The Memo and Roadmap came back empty. The number never depends on the narration provider. If narration fails, the range still returns with empty memo and roadmap sections; a 504 appears only when narration was required on a paid run and failed. Re-run once the narration provider recovers.

I expected a business valuation and got a domain valuation. The usual cause is that no traffic figure came back, which routes a free run to bare-domain treatment. See "Modes" in What you can value.

My saved report is flagged stale. Cached valuations live for 14 days and are flagged stale in the last 3 days of that window. Re-run the valuation to refresh it.

Quota and rate-limit errors

Read reason first. The main walls:

ReasonStatusWallResets
rate-limited429Burst guard: 8 requests per IP per minuteWithin a minute
free_daily_ip_cap200Anonymous: 3 valuations per day00:00 UTC
free_signed_in_monthly_cap200Free account website runs per monthFirst of next month, UTC
tier_basic_cap403Paid monthly allowance used upFirst of next month, UTC
ecommerce_requires_basic403Store valuations need Basic or ProNot a quota — a tier gate

Two things trip people up:

  • On the main website surface (/api/value), quota denials return HTTP 200 with allowed: false in the body. Branch on allowed and reason, not the status code.
  • Every valuation response carries x-quota-limit, x-quota-remaining, and x-quota-reset headers. Read them to see the wall coming instead of hitting it.

A run that fails before producing a usable response, or that comes back fully degraded, refunds its quota reservation. Refunds are capped per day and per month, so forced failures cannot mint extra attempts.

If you got a 503 with AUTH_UNAVAILABLE, nothing is wrong with your quota or your plan — the account lookup itself failed transiently. Retry the request.

MCP and API errors

The MCP endpoint always answers HTTP 200; the outcome is in the body. The codes you are most likely to see:

CodeMeaningFix
-32001Key missing, malformed, revoked — or valid but not on a Pro accountCreate a key on a Pro account and send it as Authorization: Bearer
-32003Over 5 requests per secondHonour the retry-after header
-32004Monthly allowance for that run kind is used upWait for the UTC month to reset
-32005The valuation failed upstream, or you asked for youtube / twitch on value_socialRetry, or use a served platform

The full method-by-method contract is in MCP and agent access.

Billing and upgrades

I paid, but my account still shows Free. Your tier is stamped when Stripe confirms payment, and the return trip to /account claims the checkout session and re-renders on the new plan immediately. If you closed the tab right after paying, just open /account again — the webhook has already stamped the tier. If it still shows Free after a reload, contact support with the approximate payment time.

My card payment failed. A failed retry (past_due) keeps your paid tier during the dunning grace window. Fix the payment method in the Stripe Customer Portal at /account/billing and the subscription continues; a subscription that ends drops the account to Free.

/account/billing returns a 404. That route only works for accounts with a Stripe subscription record. If you have never subscribed there is nothing to manage there.

Cancelling. Cancel from the Stripe Customer Portal at /account/billing. When the subscription status changes to canceled, the account drops to Free.

Refunds. Refunds are governed by § 9 of the Terms of Service, which is the authority — this page does not restate or summarise that section. Send refund enquiries through the contact form, referencing the original purchase and the reason.

Contacting support

Use the contact form for privacy requests, accessibility issues, refund requests, and product feedback. Most requests are acknowledged within two business days.

Two things support will not do, so you do not wait on them: individualized financial, legal, or investment advice, and manual valuations on request. The estimate you see is the estimate the engine computed.

When you write in about a failed request, include the request_id from the error payload and the approximate time. That is the difference between "found it in one query" and "please describe everything again".