Every SellerMagnet API request costs exactly 1 credit, charged the moment the request is processed - whether it succeeds, returns a billed 'not found', or is a billed upstream error. To price a use case, turn it into a monthly request count (ASINs tracked times how often you check them, or a one-off batch size), then compare that against both a subscription plan's included requests and plain pay-as-you-go: the cheapest option depends on the volume, not just the headline per-request price.
Key Takeaways
- 1 request = 1 credit on success, on a billed 404, and on each billed 502/503 retry; requests rejected before processing (bad key, missing parameter, 429) are free, and a 500 is refunded.
- Turn your use case into a monthly request count first: ASINs tracked x checks per month, or a one-off batch size - the calculator below does the arithmetic once you have that number.
- Compare the cheapest covering subscription plan against pure pay-as-you-go; a subscription's included requests are a flat allowance, so a lighter month can make PAYG cheaper even at a higher per-1,000 rate.
- Retries are a separate line item: 502/503 are billed on every attempt, so measure your own retry rate instead of assuming one.
- Plan prices and included requests change - this post uses the live table from sellermagnet-api.com/pricing captured 2026-10-17; re-check before finalizing a budget.
Which requests actually cost a credit?
The order of checks matters for budgeting: a request is validated (API key, required parameters, rate limit) BEFORE a credit is deducted, so those rejections are free and don't count toward your plan's included requests. Once a credit is deducted, a 'not found' (404) is a real, billed answer - it is not a free miss. A 500 internal error is refunded automatically, so one retry after a 500 costs nothing extra. A 502 or 503 upstream error, on the other hand, is billed on every attempt, so a batch that retries those errors pays once per try, not once per ASIN.
| Outcome | Billed? | Notes |
|---|---|---|
| Invalid/missing key, bad parameter, rate limit (429) | No | caught before the request is processed |
| 200 success | Yes | 1 credit |
| 404 not found | Yes | a real answer, still costs a credit |
| 500 internal error | No, refunded | retry costs nothing extra |
| 502 / 503 upstream error | Yes, per attempt | a retried batch pays once per try |
How much does my use case cost per month?
The calculator below takes a monthly request count you supply (your own estimate, including any retried billed calls) and checks it against the live plan table: the cheapest subscription that covers the volume outright, or the top plan plus a pay-as-you-go top-up for the rest. It also prices the same volume on pure pay-as-you-go and reports which option is actually cheaper - plans are a flat monthly allowance, so a use case that doesn't need the full allowance can cost less on PAYG even though its per-1,000 rate is higher.
cost_calculator.py - plan table and comparison logic
#!/usr/bin/env python3
"""cost_calculator.py - estimate monthly SellerMagnet credit/request needs and
pick the cheapest plan that covers them, from the real plan table on
https://sellermagnet-api.com/pricing (captured 2026-10-17; re-check before
relying on it, plan prices change).
Every request is 1 credit, charged the moment it is processed: requests
rejected before processing (bad key, missing/invalid parameters, rate limit)
are free, HTTP 500 is refunded, and 404/502/503 ARE charged - a failed lookup
or a retried 502 still costs a credit per attempt. This calculator asks for
your OWN estimate of failed/retried calls per batch; it never assumes a
retry rate, because that number depends on your ASIN list and marketplace.
"""
from __future__ import annotations
from dataclasses import dataclass
# Captured from https://sellermagnet-api.com/pricing on 2026-10-17. Prices and
# included requests change - re-check the live page before a real budget.
PLANS = [
{"name": "Free", "price_eur": 0, "requests": 500},
{"name": "Micro", "price_eur": 29, "requests": 23_200},
{"name": "Starter", "price_eur": 79, "requests": 66_000},
{"name": "Professional", "price_eur": 199, "requests": 174_000},
{"name": "Business", "price_eur": 499, "requests": 499_000},
{"name": "Enterprise", "price_eur": 949, "requests": 999_000},
]
PAYG_EUR_PER_1K = 1.45 # pay-as-you-go, no subscription, credits never expire
@dataclass
class UseCase:
name: str
billed_requests_per_month: int # your own count, INCLUDING failed/retried billed calls
def cheapest_plan(monthly_requests: int) -> dict:
"""The lowest-priced plan whose included requests cover the month, or the
top plan plus a PAYG top-up for the requests it doesn't cover."""
for plan in PLANS:
if plan["requests"] >= monthly_requests:
return {"plan": plan["name"], "monthly_eur": plan["price_eur"], "topup_eur": 0.0,
"covers_all": True}
top = PLANS[-1]
overage = monthly_requests - top["requests"]
topup = round(overage / 1000 * PAYG_EUR_PER_1K, 2)
return {"plan": f"{top['name']} + PAYG top-up", "monthly_eur": top["price_eur"],
"topup_eur": topup, "covers_all": False}
def payg_only_cost(monthly_requests: int) -> float:
return round(monthly_requests / 1000 * PAYG_EUR_PER_1K, 2)
def plan_for(use_case: UseCase) -> dict:
sub = cheapest_plan(use_case.billed_requests_per_month)
payg = payg_only_cost(use_case.billed_requests_per_month)
total_sub = sub["monthly_eur"] + sub["topup_eur"]
cheaper = "subscription" if total_sub <= payg else "pay-as-you-go"
return {"use_case": use_case.name, "billed_requests": use_case.billed_requests_per_month,
"subscription": sub, "subscription_total_eur": round(total_sub, 2),
"payg_total_eur": payg, "cheaper": cheaper}
if __name__ == "__main__":
# Price tracker: 200 ASINs, checked every 30 minutes, all month (30 days).
price_tracker = UseCase("Price tracker (200 ASINs / 30 min)",
billed_requests_per_month=200 * (30 * 24 * 60 // 30))
# Catalog sync: 5,000 ASINs looked up once a day.
catalog_sync = UseCase("Catalog sync (5,000 ASINs / day)",
billed_requests_per_month=5_000 * 30)
# Research burst: a one-off 15,000-call keyword/competitor sweep, no recurring load.
research_burst = UseCase("One-off research sweep", billed_requests_per_month=15_000)
for uc in (price_tracker, catalog_sync, research_burst):
r = plan_for(uc)
print(f"{r['use_case']}: {r['billed_requests']:,} requests/mo")
print(f" cheapest plan: {r['subscription']['plan']} "
f"(EUR{r['subscription']['monthly_eur']}/mo"
+ (f" + EUR{r['subscription']['topup_eur']} top-up" if r['subscription']['topup_eur'] else "")
+ f") = EUR{r['subscription_total_eur']}/mo")
print(f" pay-as-you-go only: EUR{r['payg_total_eur']}/mo")
print(f" cheaper option: {r['cheaper']}")Three real use cases run through the calculator
Price tracker (200 ASINs / 30 min): 288,000 requests/mo
cheapest plan: Business (EUR499/mo) = EUR499.0/mo
pay-as-you-go only: EUR417.6/mo
cheaper option: pay-as-you-go
Catalog sync (5,000 ASINs / day): 150,000 requests/mo
cheapest plan: Professional (EUR199/mo) = EUR199.0/mo
pay-as-you-go only: EUR217.5/mo
cheaper option: subscription
One-off research sweep: 15,000 requests/mo
cheapest plan: Micro (EUR29/mo) = EUR29.0/mo
pay-as-you-go only: EUR21.75/mo
cheaper option: pay-as-you-goPicking a plan for a fourth use case (exact plan boundary)
from cost_calculator import UseCase, plan_for
# 66,000 requests/month sits exactly on Starter's included allowance.
boundary = UseCase("Right at Starter's limit", billed_requests_per_month=66_000)
print(plan_for(boundary))
# {'use_case': "Right at Starter's limit", 'billed_requests': 66000,
# 'subscription': {'plan': 'Starter', 'monthly_eur': 79, 'topup_eur': 0.0, 'covers_all': True},
# 'subscription_total_eur': 79.0, 'payg_total_eur': 95.7, 'cheaper': 'subscription'}
Why did pay-as-you-go beat a bigger plan in the price tracker example?
The 200-ASIN, 30-minute price tracker needs 288,000 requests a month - more than Professional's 174,000, so the calculator rolls it up to Business at €499 flat. Pure pay-as-you-go for the same 288,000 requests costs €417.60, because Business's 499,000 included requests go mostly unused at that volume; the flat allowance only pays for itself once you are actually using most of it. The catalog sync example lands the opposite way - its 150,000 requests slot just under Professional's 174,000 allowance, so the flat €199 beats €217.50 of PAYG for the same volume. There is no single rule beyond 'compare both for your own number'; see the Python quickstart for building the price tracker itself, and the rate limits and retries guide for the retry behaviour that feeds into your real monthly request count.
Frequently Asked Questions
Does a failed lookup (404) still cost a credit?
Yes. A 404 'not found' is a real, billed answer - the credit paid for the attempt, not the result, and the same is true of a 502/503 upstream error on every retried attempt. Only requests rejected before processing (bad key, missing parameter, rate limit) are free, and a 500 internal error is refunded; this is the behaviour in the code, which can differ from a simplified summary on a marketing page.
Should I budget for retries?
Yes, separately from your base request count. 502/503 are billed on every retried attempt, so a batch with a 2% retry rate costs roughly 2% more credits than the raw ASIN count; measure your own retry rate rather than guessing it, since it depends on your ASIN list and marketplace.
Is pay-as-you-go always cheaper for low volume?
Usually, but not always - compare both, because a subscription plan's included requests are a flat allowance regardless of how many you use. The 500 free monthly requests only exist on the Free plan; once you need more than that for a given month, run the numbers for your own volume.
What happens if I go over a plan's included requests?
This calculator assumes the overage is covered by pay-as-you-go credits at €1.45 per 1,000 requests on top of the subscription; confirm your plan's actual overage handling on the pricing page or with sales before committing to a number.
Do plan prices and included requests change?
Yes - this post states the numbers live on sellermagnet-api.com/pricing on 2026-10-17. Re-check the pricing page before finalizing a budget; a cost calculator is only as current as its last pull from that page.
Bottom line: turn your use case into a monthly request count, including retried billed calls, then price it against both the cheapest covering subscription plan and plain pay-as-you-go - don't assume a bigger plan is always cheaper per request. See Pricing for the current live plan table, API Documentation for the full billing rules per endpoint, and Code Examples for runnable request samples in more languages.
