# Pricing This page is the plan and credit reference for the kwery API. If you're new to the account lifecycle — signing up, checking usage, running out — read [Self-serve](/guides/self-serve) first. [See plan pricing and credit costs →](https://kwery.co/pricing) ## Plans | Plan | Price / month | Included credits / month | Overage rate | At the cap | | --- | --- | --- | --- | --- | | `free` | €0 (no card required) | 1 000 *(one-time)* | — | hard-stop (`402`) | | `starter` | €79 (€63 annual) | 10 000 | €7.90 / 1 000 credits | overage (or budget cap) | | `growth-s` | €399 (€319 annual) | 100 000 | €3.99 / 1 000 credits | overage (or budget cap) | | `growth-m` | €699 (€559 annual) | 200 000 | €3.50 / 1 000 credits | overage (or budget cap) | | `growth-l` | €999 (€799 annual) | 400 000 | €2.50 / 1 000 credits | overage (or budget cap) | | `enterprise` | custom — annual contract | volume agreed | contact sales | no cap — invoiced | Every plan grants a fixed number of **included credits** each month. Paid plans keep running past the included amount at the overage rate; the free plan stops. Upgrades and downgrades are managed in the dashboard and take effect immediately. ## Credit weights by source Credits are consumed per **completed** result — a found product, or a freshly determined "not found". The base rate is **1 credit = 1 full data set** (search + product + offers, matched). On **Amazon, Walmart, and eBay, 1 credit returns 2 full data sets** — one shared half-credit rate across all three. `kaufland` costs 3 credits, reflecting its higher delivery cost: | Source | Credits per result | Data sets per credit | | --- | --- | --- | | `amazon` | 0.5 | **2** | | `walmart` | 0.5 | **2** | | `ebay` | 0.5 | **2** | | `idealo` | 1 | 1 | | `google` (Google Shopping) | 1 | 1 | | `otto` | 1 | 1 | | `billiger` | 1 | 1 | | `guenstiger` | 1 | 1 | | `lidl` | 1 | 1 | | `aliexpress` | 1 | 1 | | `rakuten` | 1 | 1 | | `kaufland` | 3 | ⅓ | ### How credits work: a quick example **One simple formula:** SKUs × credit rate × number of sources = credits needed That's it. Here's what it looks like with real numbers. **The scenario:** you track 10,000 SKUs and want daily pricing data from two sources — Amazon and Google Shopping. | Source | Formula | Credits | | --- | --- | --- | | Amazon | 10,000 SKUs × 0.5 credits/SKU | **5,000** | | Google Shopping | 10,000 SKUs × 1 credit/SKU | **10,000** | | **Total** | | **15,000 credits/day** | No hidden math, no per-source pricing tiers to look up — just SKUs × rate × sources. (Half-credit rates mean your balance and usage graph can show half-credit steps.) What counts, and what doesn't: - **Every freshly crawled successful result is billed** at the source's weight. - **Cache re-serves are free.** If your request can be answered from data younger than your [`max_age`](/guides/self-serve#cached-re-serves-and-freshness) window, the result is served from cache (`served_from: "cache"`) and debits **zero credits**. The cache is shared across all customers — any recent crawl of the same product can serve your request — so widening `max_age` directly lowers your bill. - **A freshly crawled "not found" is billed** at the source's weight — determining that a product has no listings is a completed lookup. A "not found" re-served from the not-found cache (within [`not_found_max_age`](/guides/self-serve#cached-re-serves-and-freshness)) is **free** — no crawl was made. - **Failed lookups are free** — blocked, timed-out, and lost results are never billed. - **Additional Google seller pages are billed per page.** With [`max_pages`](/sources/google-shopping#max-pages) above 1, each additional page that returned sellers costs Google's weight on top of the result itself. A result with 3 additional pages costs 4 credits. Failed pages are free. Credits are debited once per job, at completion, across the batch of values in that job. Weights are per source and may change if a source's delivery cost structurally changes — any change is announced in advance and never applies retroactively to a running period. ## Credit rollover and expiry - **Unused credits roll over and never expire.** Included credits you don't use in a billing period stay on your balance — they are not forfeited at the period boundary, and there is no expiry date on them. There is one kind of credit: the credits included in your plan. Usage beyond them is billed at your plan's overage rate (see [Overage](#overage)) — there are no separate credit packs to buy. Your credit period renews **monthly on the day of the month you subscribed** (your billing day), at 00:00 UTC — in step with your subscription's billing cycle. The `period_resets_at` field in the credits response gives the exact next boundary. Overage counters (`overage_units_this_period`, `overage_amount_cents`) start fresh each period. For example, if you subscribe on the 17th, your credits reset on the 17th of each following month. If you subscribe on the 31st, months with fewer days reset on the last day of that month. **Annual plans** work the same way: included credits are re-granted every month on your billing day, even though the plan itself is invoiced once a year. Overage is [billed on the same monthly cadence as on monthly plans](#overage-billing), regardless of your billing interval — you're never carrying a year's worth of unbilled usage. ## Overage When a paid plan (`starter` / `growth-s` / `growth-m` / `growth-l`) exhausts its credit balance, it does **not** stop. You continue seamlessly into **overage**, billed per 1 000 credits at your plan's overage rate (see [Plans](#plans)). The credits response tells you exactly what you've accrued: ```json { "included": 100000, "used": 112400, "balance": 0, "plan": "growth-s", "plan_kind": "paid", "period_resets_at": "2026-09-01T00:00:00.000Z", "overage_units_this_period": 12400, "overage_amount_cents": 4948, "budget_cap_cents": null, "budget_cap_reached": false } ``` The **free** plan behaves differently: it has no overage. Once `balance` reaches 0, job submission returns `HTTP 402`: ```json { "error": true, "message": "out of credits" } ``` Nothing is charged beyond the included 1 000 — you resume at the next monthly renewal or by upgrading. ## Choosing how overage behaves Paid plans choose one of **three overage modes** — set in Billing settings or via the API: ```bash curl -s -X PATCH https://api.kwery.co/v1/account/overage \ -H "Authorization: Bearer $DASHBOARD_SESSION_JWT" \ -H "Content-Type: application/json" \ -d '{ "mode": "cap_stop", "cap_cents": 5000 }' ``` - `mode: "bill"` — **the default.** Once included credits are used, overage accrues and is billed as it grows; nothing ever stops. An optional `cap_cents` acts as an **alert threshold**: you're emailed as you approach and cross it, but not blocked. - `mode: "cap_stop"` — a real spending ceiling: job submission returns `402` once accrued overage cost reaches `cap_cents` for the period (`cap_cents` is required in this mode). - `mode: "off"` — no overage at all: job submission returns `402` the moment your included credits are spent, like the free plan's hard stop. Use this if you never want a variable charge. > The earlier `PATCH /v1/account/budget-cap` endpoint keeps working: `hard_stop` with a cap behaves as `cap_stop`, `hard_stop` without a cap as `off`, and `notify` as `bill` with an alert threshold. New integrations should use `/v1/account/overage`. ## How overage is billed Overage increments and caps are two different controls, doing two different jobs — independent of each other: **What the cap number means depends on your mode**, so it is worth being explicit: - In `cap_stop` mode it is a real ceiling: new overage stops automatically the moment the cap is reached — regardless of whether your payment method is working perfectly. A cap being reached usually means everything worked exactly as intended: you chose to stop there for the cycle. - In `bill` mode — **the default** — the same number is only an email trigger. You are alerted as you approach and cross it, and nothing stops at your cap. One ceiling is always present though — see below. - In `off` mode there is no cap and no overage: the hard stop sits at your included credits. **One ceiling you cannot turn off.** Independently of your own cap, and in every mode, we pause new overage if the amount already delivered but not yet successfully billed grows too large. That is a solvency limit rather than a preference, which is why it is not configurable. It sits far above the per-plan increments, so on a working payment method you will never meet it — each increment settles long before it accumulates. The current figure is in the credits response as `overage_limit_cents`, alongside `overage_unbilled_cents` and `overage_limit_reached`, so the dashboard can always show you where you stand. Switch modes, or raise or remove the cap, any time in Billing settings (or via [`PATCH /v1/account/overage`](#budget-cap)). **The overage charge protects both sides.** Overage is charged in fixed per-plan increments as it accrues — **€10** on `starter`, **€20** on `growth-s`, **€35** on `growth-m`, **€50** on `growth-l` — not as one charge when you hit the cap. Each increment that succeeds confirms your payment method is healthy; if one fails, we pause **new overage immediately** rather than waiting to find out at the cap — your included credits keep working as normal, and the pause lifts automatically the moment a payment retry succeeds. You can watch overage build at any time in the credits response (`overage_units_this_period`, `overage_amount_cents`) and in the dashboard, so no charge is ever a surprise. **Annual plans are no exception.** Overage on an annual plan is charged in the same increments, on the same monthly cadence, as on a monthly plan — only the plan price itself is annual. Any remainder below one increment is settled at your monthly credit-period boundary, never accumulated toward the annual renewal. ## Enterprise `enterprise` is a **custom annual contract with an agreed volume** — millions of SKUs per month — on the same source-weighted credit model described above. There is no hard cap: usage is invoiced against the agreed volume at the end of each period. Enterprise adds custom source onboarding (new markets, new sources), a dedicated account manager, and audit-trail export for compliance. [Contact sales](https://kwery.co/contact) to set one up. ## Next steps - [Self-serve](/guides/self-serve) — the account lifecycle: signup, credits, running out, plans. - [Getting started](/guides/getting-started) — submit your first job. - [Confidence score](/guides/trust) — the confidence score on every result.