Plans, quotas & billing

RealSiteWorth has three plans: Free, Basic, and Pro. Every number on this page comes from a constant in the codebase, not from marketing copy. Where a value is configurable, this page says so.

What the three valuation depths are called

Three depths of run exist. The names on the left are what you see everywhere you are choosing or buying — the pricing page, your plan card, this page's prose. The names on the right are what the dashboard's Run Valuation selector, the quota counters and the API reason codes still use, so this page keeps them beside the product name rather than hiding them: you need them to find the control and to read an error.

Free carries no Full-valuation or Full Diligence allowance, so every Free run is a Quick valuation. The tables below are labelled with the run-type column so they line up with what the app shows you.

Prices

Annual savings are computed from the monthly price, not typed in. The shared toggle label is Save ~15–16%. There are two marketing promo codes, RSW10 (Basic) and RSW20 (Pro). They are never auto-applied at checkout.

Only four Stripe prices can be bought. The checkout API rejects anything else outright: rsw_basic_monthly, rsw_basic_annual, rsw_pro_monthly, rsw_pro_annual.

What each plan includes

This table follows the feature matrix in the code, with the free monthly allowance resolved to its configured default. It is deliberately narrower than the roadmap. A feature appears here only when its tier placement is real and enforced.

The four allowance rows keep the run-type names the app itself uses, so they line up with the dashboard selector and the quota counters. Read them against the vocabulary table above: Lite valuations are Quick valuations, Core / Expanded Standard are the Core and Expanded Full valuation, and Website & SEO Deep is the Full Diligence Valuation — 3 a month on Basic, 25 on Pro, and the same run either way.

Nine notes on that table.

One shared paid Quick pool, plus surface-specific Full-valuation counters (final launch package, 2026-08-26). Paid Quick valuations come from ONE shared monthly pool — a Quick pull on a website, a domain, or a social profile draws from the same 1,000 (Basic) or 2,500 (Pro) allowance. Full valuations stay surface-specific: website, domain-only and social are three independent counters, and the Full Diligence Valuation has its own. Exhausting one never blocks a different surface — running out of social Full valuations still leaves your website allowance untouched. Free's Quick limits remain surface-specific launch protections (they are abuse caps, not a pool). TIER_QUOTAS in src/lib/billing/limits.ts is the enforced source for every number here.

A Quick valuation is a fixed contract, not a lower tier of one. It is the exact same streamlined public-signal check on every plan — Free, Basic, and Pro all get byte-identical Quick evidence. Paid plans get more of them per month, never a different bundle.

Package and run depth are two different things. Free, Basic and Pro are packages. Quick, Full and Full Diligence are run depths. Free carries no Full or Full Diligence allowance and can only ever run Quick valuations. Both paid packages include Full Diligence: Basic includes 3 Full Diligence Valuations per month, Pro includes 25. It is the same run on either package — the count is the difference.

Those 3 and 25 are each metered on their own monthly counter, separate from the Full-valuation counters, at no extra charge — choose Deep next to Run Valuation in the dashboard, then submit. Both paid packages get that option in the selector.

A Full Diligence Valuation is identical on Basic and Pro. Same evidence, same operations, same answer-engine coverage, same report content — including the bounded referring-domain sample and the new/lost link-trend window, which are collected on both. The packages differ on how many you get each month and on the surrounding workflow, never on the quality of one. It applies to website and domain assets only — social, newsletter and store valuations always run as Full valuations, so a Full Diligence allowance cannot be spent on them.

The Full valuation is the one depth that genuinely differs by package, not just by count. Basic's Core Full valuation collects the primary website, search, authority, backlink, demand and confidence evidence needed for a complete paid report. Pro's Expanded Full valuation collects that same evidence with broader answer-engine coverage. That difference is website-valuation-only, and it does not extend upward: the deeper search, referring-domain and link-trend evidence belongs to the Full Diligence Valuation, which is the same run on both packages.

Full Diligence adds the deepest website evidence. It adds the deeper rank and ranked-keyword pull, the referring-domain sample and the link-trend window. It is the same evidence bundle on Basic and Pro; the packages differ only in monthly allowance.

Domain Appraisal is paused. The domain-only surface (/domain-appraisal) is temporarily unavailable while we verify its evidence and accuracy against comparable sales, and it carries no quota allowance while paused. Value a domain through Website & SEO valuation instead — submit it through the Website/SEO input, where it consumes the website allowances. A domain purchased for its backlinks, traffic, or content belongs on that surface even once Domain Appraisal resumes, because Domain Appraisal structurally never prices traffic, backlinks, rankings, content, or revenue.

RSW Auth and Trust are included from Basic. A free run collects only domain age and page authority — not the traffic, backlink, and search-trend evidence Basic and Pro add — so a free report labels both Not measured rather than inventing a score from a partial pull.

Social and creator valuations are the same report on Basic and Pro. Unlike the website Full valuation, the social Full valuation does not differ by package — the paid packages differ on monthly allowance only, not on social depth, so Pro is not sold as a deeper social pull.

Watchlist refreshes are on-demand at every tier, including Free. The daily refresh ceiling is 5 on Free, 5 on Basic and 20 on Pro, so the paid difference is the number of tracked slots and the Pro refresh ceiling — not the ability to refresh.

Three counters, not one

Your ability to run a valuation is governed by three independent counters. You have to pass all of them.

1. Burst limit. 8 requests per IP per minute, on every valuation surface. This is checked first, before anything else. Exceeding it returns 429 and consumes no quota.

2. Daily or monthly bucket. Which bucket you land in depends on who you are.

3. Tier quota. The monthly allowance for your plan, counted per UTC calendar month.

Anonymous (not signed in)

You get 3 website valuations per UTC day, shared across every valuation surface. It is one combined bucket, not three per surface.

Two buckets enforce this together. One is keyed to your IP. The other is keyed to an rsw_anon_quota cookie (HttpOnly, SameSite=Lax, one-year max age). Clearing cookies still hits the IP bucket. Rotating IPs still hits the cookie bucket. The response reports whichever of the two has less left, so the remaining count is never overstated.

The bucket resets at 00:00 UTC.

Signed-in Free account

You get 15 Quick website valuations per UTC calendar month by default. This value is configurable via the FREE_MONTHLY_QUOTA environment variable and falls back to 15 when unset.

Free accounts also get 5 social/creator valuations per UTC day, 25 per UTC calendar month, and 5 watchlist slots (2026-08-26: both caps apply together — whichever you hit first in the month blocks the next run).

The monthly window is the UTC calendar month. It resets at the first instant of the next month, and the API tells you the exact timestamp in x-quota-reset.

Free's real ceilings are the two numbers above — 15/month website, 25/month (5/day) social, all Quick valuations — read straight from TIER_QUOTAS.free.lite_web_domain and .lite_social. The prior free tier basicPerMonth: 90 / signed-in "quota override of 50" combined-website-and-social ceiling was retired in the 2026-08-26 overhaul: it was an undocumented leftover from before the two surfaces had their own counters, and nothing about it was a deliberate product decision. Anonymous callers never reach a monthly check at all — the daily IP cap returns first.

Basic and Pro

Paid tiers skip the daily bucket entirely. Your cap is the monthly tier quotas, each counted per UTC calendar month:

• Basic: 1,000/mo shared Quick valuations (websites · domains · social), 100/mo Core Full website valuations, 50/mo Full Social valuations, 3/mo Full Diligence Valuations. Domain Appraisal is paused and carries no allowance.
• Pro: 2,500/mo shared Quick valuations, 250/mo Expanded Full website valuations, 100/mo Full Social valuations, 25/mo Full Diligence Valuations. Domain Appraisal is paused and carries no allowance.

Exhausting one Full-valuation counter never blocks a run on a different surface; exhausting the shared Quick pool blocks Quick runs on every surface at once (it is one pool by design).

Because the daily bucket does not apply, x-quota-limit carries a non-numeric sentinel rather than a count on paid accounts. That describes the daily bucket only. Your real cap is the monthly quota in the table above.

When any meter reaches 80% of its monthly limit, the account page shows a soft warning. The hard stop is at 100%.

What counts as a run

A unit is reserved before the engine starts, and it is charged only if the run produces something usable.

Charged:

• Any valuation that returns a result.

Not charged:

• Requests rejected by the burst limiter. The limiter runs before any reservation.
• Requests rejected by a tier gate. On the store/business surface the tier check fires before the body is even parsed, specifically so a denied caller never consumes a unit.
• Requests rejected by the quota wall itself.
• Invalid input (400), oversized bodies (413).
• Runs that fail before producing a usable response. A 5xx or a thrown error refunds the reservation.
• Runs that come back fully degraded, meaning every core signal was null. Those refund too.

Refunds are bounded. A subject can reclaim at most 6 daily units per day and 15 monthly units per month. Past that cap the original charge stands. This exists so a caller who can reliably force failures cannot mint unbounded engine attempts, since each attempt can cost real vendor spend.

Refunds are idempotent and floor at zero. A duplicate or unmatched refund can never create quota.

Store and business valuations require Basic

Store and business (ecommerce) valuations are a paid feature. You need tier basic or higher.

Anonymous callers and signed-in free accounts get a 403:

{
  "error": {
    "code": "TIER_FORBIDDEN",
    "reason": "ecommerce_requires_basic",
    "tier": null,
    "message": "Store and business valuations are part of Basic ($39/mo). Sign in with a Basic or Pro account to run one.",
    "request_id": "a1b2c3d4e5f6a7b8"
  }
}

The gate sits after the burst limiter and before the body parse, so a denied request costs you nothing.

One exception matters. If the account lookup itself fails, for example a database blip, you get a retryable 503 instead of a tier denial:

{
  "error": {
    "code": "AUTH_UNAVAILABLE",
    "reason": "auth-lookup-failed",
    "message": "We could not verify your account just now. Please retry in a moment.",
    "request_id": "a1b2c3d4e5f6a7b8"
  }
}

A paying customer is never 403'd because of an infrastructure hiccup. Retry the request.

This surface takes financial inputs, not a URL. Monthly revenue is required and is never inferred.

curl -X POST https://realsiteworth.com/api/value-ecommerce \
  -H 'Content-Type: application/json' \
  -d '{"monthlyRevenue": 42000, "monthlyCogs": 18000, "platform": "shopify"}'

What you see at the wall

The denial shape differs by surface. Read the reason field, not the HTTP status.

Website valuations (/api/value)

curl -X POST https://realsiteworth.com/api/value \
  -H 'Content-Type: application/json' \
  -d '{"url": "example.com"}'

Quota walls on this surface return HTTP 200 with allowed: false in the body. Do not branch on the status code here. Branch on allowed and reason.

Anonymous daily cap:

{
  "allowed": false,
  "tier": "free",
  "kind": "lite",
  "reason": "free_daily_ip_cap",
  "message": "Anonymous use is capped at 3 valuations per day. Sign in free to keep report history.",
  "quota": { "limit": 3, "remaining": 0, "reset": "daily_utc", "subject": "anonymous" },
  "request_id": "a1b2c3d4e5f6a7b8"
}

Signed-in free monthly cap:

{
  "allowed": false,
  "tier": "free",
  "kind": "lite",
  "reason": "free_signed_in_monthly_cap",
  "message": "Free account monthly Lite website limit reached (15 valuations). Basic includes 100 Core Standard website valuations each month — or come back on 2026-09-01T00:00:00Z.",
  "quota": { "limit": 15, "remaining": 0, "reset": "2026-09-01T00:00:00Z", "subject": "user" },
  "request_id": "a1b2c3d4e5f6a7b8"
}

The two reasons are deliberately distinct so a client can pick the right prompt (sign up versus upgrade) without inspecting quota.subject.

Store valuations (/api/value-ecommerce)

Free and anonymous callers never reach a quota wall on this surface, because the 403 tier gate (ecommerce_requires_basic) fires first. The wall you can actually hit here is the paid monthly allowance, described next.

Monthly tier quota exhausted (Basic and Pro)

When a paid account burns through one of its monthly counters, the gate returns 429 with a reason naming which one. The reason codes carry the internal run-type names — tier_lite_cap (Quick), tier_standard_cap (Full), tier_deep_cap (Full Diligence) — so read them literally rather than translating.

You've used your monthly Core Standard allowance. Upgrade or wait until September 1.

(Basic's message above; Pro's says "Expanded Standard". tier_deep_cap fires on either paid package when the monthly Full Diligence allowance is exhausted — after 3 on Basic, after 25 on Pro. Only Pro's exhaustion path tries a $1.49 PAYG credit before it denies; PAYG credits are Pro-only and Basic has no credit-purchase access at all.)

A different pair of reasons — standard_requires_upgrade and deep_requires_upgrade — fire as 403 for a caller who explicitly asks for a Full or Full Diligence run their package does not carry at all: Free or anonymous. Those are a package gate, not a quota wall: no allowance exists to exhaust. A paid package that has an allowance and has spent it gets tier_deep_cap/429 instead.

Burst limit

Every surface, 429:

{
  "error": {
    "code": "RATE_LIMITED",
    "reason": "rate-limited",
    "message": "Too many requests. Try again in a minute.",
    "request_id": "a1b2c3d4e5f6a7b8"
  }
}

Quota headers

Every valuation response, allowed or denied, carries the same three headers:

x-quota-limit: 15
x-quota-remaining: 11
x-quota-reset: 2026-09-01T00:00:00Z

x-quota-reset is daily_utc for the anonymous bucket and an ISO timestamp for monthly buckets. Read these to show a remaining count before the user hits the wall, rather than discovering the wall by hitting it.

How upgrading takes effect

Checkout goes through Stripe. Your tier flips when Stripe tells us it did, not when you land back on the site.

1. You start checkout for one of the four allowed lookup keys. Anything else is rejected before a Stripe session is created.
2. Stripe processes payment and sends a webhook. The webhook verifies the Stripe signature and rejects anything unsigned or mismatched with 400. Events are deduplicated on the event ID.
3. On checkout.session.completed, the lookup key is mapped to a tier and stamped in two places: the Stripe customer's metadata, and your profiles.tier row.

That second write is the one that matters for your limits. It happens at payment time, not when you visit your account page. If you close the tab immediately after paying, your new limits are already live.

Plan changes and cancellations follow the same path:

• customer.subscription.updated re-stamps the new tier on both stores.
• A canceled status drops you to free immediately.
• past_due keeps your paid tier. That is deliberate dunning grace, so a failed card retry does not lock you out mid-cycle.
• customer.subscription.deleted drops you to free.

The gate reads tier from that stamped metadata. It never trusts a tier supplied by the client.

Where these numbers live

If you are reading the source, these are the files that own each value. Nothing else should hardcode them.