1. The answer first: five multipliers between the quote and your unit

An Amazon data API pricing page gives you a unit price. The unit is a call, a result, a credit, a gigabyte, or a rate allowance. Your budget needs a total, and the unit is a record you can use. The distance between them is not one division. It is five multipliers:

All five multipliers consume budget. One of them appears on the pricing page. Of the rest, two hide in the contract (failure billing rules and how a result page is counted) and two hide in your own architecture (retry policy and polling cadence). That is why two companies on the same vendor and the same unit price can land on monthly bills a factor of two apart.

The unit in one sentence: stop asking what a thousand calls costs. Ask what you pay for a thousand records that pass your quality gate, and how much of that number is engineering hours nobody invoices you for.

2. What people searching this keyword are asking

The query reads like a price check. Three groups land on the same page looking for different things. Their situations differ, and the missing piece is the same: a way to convert a quote into their own invoice.

Group one: quotes in hand, budget to build

They have two quotes. One bills per call, one bills per result, and the prices look three times apart with no common denominator. They do not need to be told which vendor is cheaper. They need a formula they can fill in and get a comparable number. Give this group the formula and they leave satisfied.

Group two: invoice over forecast, cause unknown

Three months in, the bill went from a projected two thousand to five thousand, and request volume did not move. The cause sits in retry amplification and polling cadence: the client retried three times, the server retried once, and the failed attempts were billable. This group needs a triage checklist that walks the multipliers one at a time.

Group three: choosing a vendor for next year

No data yet, writing the evaluation doc. This group is the most exposed to entry pricing, because the entry price corresponds to the simplest endpoint, the lowest multiplier, one marketplace, no rendering. They need the list of contract terms a pricing page leaves out.

All three groups have the same gap. None of them lacks a price comparison table. This page covers the cost unit and nothing else; for the wider selection picture, our pillar page on Amazon data scraping starts further upstream. All of them lack the ability to turn a cell in that table into their own number. So this article does not compare vendor prices. Those tables go stale in three months, and without your failure rate and usable rate nobody can fill in the cell you need. This article gives you the conversion. You supply the parameters and reach your own conclusion.

3. Why some quotes look cheap and bill high: four layers of add-ons

Two quotes for the same job can sit a factor of two apart. The expensive one has no extra fields and no better service commitment. The gap is not in the unit price. It is in what the price includes. Split mandatory components into add-ons and the number on the pricing page drops, while every one of those lines still lands on the invoice.

Entry-point data is where teams hit this fork. Across the last few quarters, the large sellers we work with have started treating Alexa as a traffic entry on equal footing with keywords: they track placement, track which ASIN pages surface them, and track what that entry converts into. That data class touches all four layers below, and it is absent from many price lists. Our endpoint for it is the Amazon Alexa API.

3.1 Layer one: JavaScript rendering

A static request takes the bytes the server returns. Rendering executes the page in a headless browser and waits for the async calls to fill content before extraction. The cost structure behind it is CPU time and memory, not bandwidth, so it costs more.

You can look this one up in public. On the Oxylabs pricing page, one tier carries two prices side by side: Amazon results at $0.50 per thousand without JavaScript rendering and $1.35 per thousand with it, a multiplier of 2.7 (readings from September 2026; prices move with tier and contract). Two figures inside one package means rendering is a switch in their pricing, not part of the base price.

3.2 Layer two: IP grade

The gap between datacenter IPs and rotating residential IPs is visible in published proxy price lists, and it is measured in multiples rather than percentages. Amazon scores automated requests on IP quality, browser fingerprint, request cadence, and session continuity. Two outcomes follow when the score trips: you are blocked, or you receive a page with parts missing. The second outcome costs more. It returns 200, the fields look populated, and the top ad placements plus a couple of modules never loaded.

This layer does not sit in the request price. It settles on a separate product line, billed as residential proxies or rotating proxies, and you add it to your call cost yourself.

3.3 Layer three: login sessions and accounts

Some data is not served outside a session: parts of the Alexa modules, the full body of some review content. Keeping logged-in state means maintaining an account pool, absorbing risk controls, solving CAPTCHAs, and replacing accounts that die. That cost lands on an account maintenance fee or on the multiplier of the endpoint. Neither appears in a column labeled price per call.

3.4 Layer four: multipliers you cannot switch off per endpoint

After the first three, one question remains: can you enable rendering for the endpoints that need it. A global toggle turns this line into a constant instead of a variable you tune. Marketplace and postal-code multipliers work the same way. Section 9.5 covers how to test for it.

3.5 Three data classes side by side

Put all three into one plan of a million records a month. The pricing-page estimate lands on row one. The three add-ons sit on rows two and three and leave row one untouched. Low entry pricing carries no signal for a team that needs full Sponsored coverage or the Alexa modules, because nothing they must buy is inside that entry price.

3.6 Off every price list: one variable nobody quotes

Pay all three layers and one number is still missing: with rendering on and the same IP grade, do two vendors bring back the same thing. Sponsored placement coverage is the cleanest test. It is the hardest part of a search result to capture and close to the only part comparable as a number. We publish 91.4% coverage across 13 marketplaces, and most vendors commit to no number at all.

Here is why it belongs in a cost discussion. A result missing its placements still returns 200. When your quality gate does not check, the row lands in your warehouse as a usable record and pulls your apparent unit cost down. When the gate catches it and drops it, you paid for a call with no output. Under those two treatments the cheap quote and the expensive quote can trade places.

3.7 Bundled pricing: put mandatory items back in the default

The other design keeps them in one price. Rendering stays on, the IP grade sits where Sponsored coverage holds, and no separate product line exists for rendering or proxies. In quote form this reads as a high unit price, because the cost of rendering and of rotating IPs at that grade sits inside our per-endpoint multipliers. There is no rendering toggle on our pricing page.

For a buyer it means this: the number you see at comparison time is higher, and you spend the next two months discovering nothing new. The work left is filling in your five parameters. Whether that certainty earns a premium depends on how much of your data sits in rows two and three. A team pulling static fields nine parts in ten pays less on the unbundled quote.

4. Six billing units, and why they do not compare

Amazon data services bill in about six ways. These are not six prices. They are six definitions of what you are paying for. Normalize them to one denominator before you compare, or you are comparing six unrelated things.

4.1 Per attempt

Every request you send is billable, whatever comes back. This is the least favorable structure for you, because failed, timed-out, and blocked attempts are yours to absorb. The unit price sits at the low end, and that is the trade: the vendor moved the risk to you and compensated in price. To judge this kind of quote you need your own attempt success rate, then the amplification factor 1 / success rate. A 95% success rate is a 1.05x factor. At 80% it is 1.25x. At 60% it is 1.67x. The curve is convex: each point you lose costs more than the point before it.

4.2 Per successful request

Only responses that succeed are billed. That reads as a good deal for the buyer until you ask who defines success. Most billing systems record HTTP 200 as success, and a 200 carrying empty fields, a placeholder value, or a challenge page is a failure for you and revenue for them. Get two answers in writing: does a 200 with empty business fields count as success, and does a valid empty response, such as a delisted product, count as success. Those two answers move your invoice by 10% to 20%.

4.3 Per thousand results (CPM)

Billed on the number of results returned. Public ranges for e-commerce targets run from about $0.45 to $1.60 per thousand, depending on target difficulty and output format. The distortion lives in the word “result.” Is a result one page or one product row inside that page? Search endpoints bill by page, and rows per page follow your pagination parameters. If the docs say “up to N results per page” rather than “N results per page,” you convert using your measured average, not the ceiling.

4.4 Per credit

Each endpoint carries a multiplier, and harder work costs more: one credit for a static page, 5 to 25 credits for rendered pages, residential proxies, postal-code targeting, or domains with heavy protection. This model is flexible, and its transparency depends on documentation quality. Do three things: pull the multiplier table for every endpoint you will use; confirm whether multipliers can be switched off per endpoint, so rendering applies to search only while product detail stays static; and compute a weighted multiplier across your real endpoint mix rather than extrapolating from the endpoint behind the entry price.

4.5 Per gigabyte

Billed on bytes transferred, common among proxy products. The variable that matters is not the unit price but page weight. Public proxy cost analyses converge on two ranges: about 100 to 300 KB per page for optimized collection, and 1 to 3 MB per page for collection that runs a full browser render. Same data, an order of magnitude apart. If your vendor bills by traffic and your method depends on rendering, shrinking the payload beats negotiating the rate: block image and font loading, reuse connections, enable compression. Every one of those lands on the invoice.

4.6 Per rate allowance

You buy tokens per minute or concurrent connections. Tokens refill at a fixed rate and expire after a window. The trap is the gap between the monthly total and the instantaneous rate. One tier generates 892,800 tokens a month, which looks like enough, and refills at 20 tokens per minute with a bucket ceiling of 1,200. A nightly batch that needs 500,000 rows inside a two-hour window will not fit through that pipe, and you paid for the month.

4.7 One conversion table: six units to cost per thousand usable records

The table below lists what each unit still requires before it becomes the same denominator. Those parameters have no default. You measure them.

Sources: unit definitions and public ranges come from vendor pricing documentation and 2026 industry benchmark roundups. Page weight ranges come from published proxy cost analyses. This article names no vendor and quotes no vendor’s price.

4.8 Why the pricing page leaves these out

Not to hide anything. Those four parameters cannot be measured on the vendor side. Attempt success rate depends on your target set, your concurrency pattern, and your retry policy. Usable rate depends on your quality gate and your field list. Records per call depend on your pagination parameters and dedup rules. Wasted allowance depends on your scheduling window. All four live on your side of the line. What a vendor can give you is a recomputable unit price and a multiplier table, and that is what you should require on the pricing page.

So the order of operations is: confirm that unit price and multipliers are published and recomputable, measure the four parameters on your own system, then run the formula. Skip the second step and the ranking you get from the price table means nothing.

5. Five multipliers from one call to one usable record

This section takes the five multipliers apart, one at a time, with an arithmetic you can apply and the order of magnitude each one moves.

5.1 Multiplier one: attempt count

Let s be the success rate of a single attempt and assume you retry until success. The average number of attempts behind one success is 1/s. Whether the failed attempts reach your invoice is the coefficient β: β=0 means failures are not billed or are refunded, β=1 means failures bill at full price. The surcharge on your invoice is β·(1−s)/s.

The table below holds every other parameter constant (usable rate 0.9, wasted allowance 0.1, unit price $0.0015375 per credit, $1.5375 per thousand) and varies the failure billing rule:

The finding: failure billing is a footnote at high success rates and a decision-changer at low ones. Amazon sits among the most protected targets on the web, so your success rate is not in the 99% row. Count a week of your own logs. That is faster than arguing the clause.

5.2 Multiplier two: success on the invoice is not usable in your tables

This is the most expensive of the five multipliers and the one least likely to appear in a budget. The vendor’s billing system judges success by HTTP status and response shape. Your quality gate judges success by your business rules. The distance between the two is your usable rate, v.

Here is one concrete form. A product page returns a price field, and the value is a placeholder: the parent variant’s price rather than the selected variant’s. The type is valid, the format is correct, schema validation waves it through, and your warehouse gains a record with the wrong price. Or the review endpoint returns a 200 and a well-formed page of JSON whose reviews array is empty, because that ASIN was not collected that day. The billing system books a success.

The amplification is 1/v, and it is convex:

A solution with a usable rate under 0.70 does not win on cost, whatever its unit price. And the usable rate is a number that will never appear on a pricing page, because it is not the vendor’s obligation. It lives in your quality gate. How to measure it is in Amazon Data Pipelines: You Can Outsource Collection, Not Data Quality, in the section on the four quality gate numbers.

5.3 Multiplier three: one call is not one record

Product detail endpoints return one record per call. Search, bestseller, and review endpoints return pages, and three things erode the count. Pagination ceilings: the docs say “up to N per page” and the real number is often lower. Cross-page duplication: the same ASIN appears on two adjacent pages, and deduplication drops your net row count. Ad placements: paid slots occupy part of a search page, so if you want organic results only, fewer rows on that page are usable.

There is one conversion: run 200 real queries, count net rows written to your tables divided by calls made, and you have your measured r. Extrapolating from the documented ceiling is the most common error in a budget table and can be off by 1.5x.

5.4 Multiplier four: polling cadence against rate of change

You poll to detect change, and you pay for calls, not changes. The ratio between them is the redundancy factor ρ = daily polls ÷ daily changes.

This redundancy is not waste to be eliminated: if you stop polling, you stop knowing. What you can optimize is its distribution. Tiered polling puts P0 fields on a four-hour cycle, P1 on a daily cycle, and P2 on a weekly cycle. Change-driven collection replaces full rescans with endpoints that surface price drops and rank movement. The first concentrates high-frequency budget on the fields that are sensitive to time; the second moves the cost of detecting change from full volume to incremental volume. Together they remove more than half of the calls that carry no new information, without losing detection latency.

5.5 Multiplier five: allowance you buy and cannot spend

The waste coefficient w has three sources. Rate shaping: the monthly allowance is sufficient and the per-minute refill rate is not, so the batch window closes before the work is done. Expiry: tokens expire 60 minutes after generation, so allowance a nightly batch leaves on the table does not roll into daytime work. Concurrency ceilings: you bought a high-throughput tier and never raised client concurrency, so half the allowance goes unused.

All three produce the same signal: the invoice is billed on allowance, rows land on consumption, and the ratio stays above 1. Track this number once a month. It is the one multiplier where no party made an error and you lost money anyway, and the one most open to recovery through scheduling.

6. The full formula: six units into one number

Combine the five multipliers and you get one expression from quoted unit price to cost per thousand usable records.

6.1 Variables

6.2 The formula

Data cost per thousand usable records

    C = 1000 · p · m · [ 1 + β·(1 − s)/s ]
        ───────────────────────────────────
              r · v · (1 − w)

True unit cost including engineering

    C_tco = C + 1000 · E / U

    U = usable records needed per month

Of the seven parameters, p and m come from the pricing page. The other five come from your system. That is the reason a pricing page cannot answer “what will this cost”: it supplies two of seven. An unbundled vendor also asks you to fold the four add-ons from section 3 into m, because they are not part of p and turn up nowhere on the pricing page.

6.3 A calculator you can run

Save this as unit_cost.py and fill in your own parameters. It prints the data cost, the engineering cost, and the engineering share.

def cost_per_1k(p, m=1.0, s=1.0, v=1.0, r=1.0, beta=0.0, w=0.0):
    """Data cost per thousand usable records.
    p    quoted price per billing unit
    m    weighted endpoint multiplier
    s    success rate of one attempt
    v    usable share of successful responses
    r    net records per successful call
    beta billed share of failed attempts, 0 means not billed
    w    share of allowance bought and unspent
    """
    attempts = 1 + beta * (1 - s) / s          # amplification from retries
    usable_per_call = r * v * (1 - w)          # net usable records per call
    return 1000.0 * p * m * attempts / usable_per_call


def tco_per_1k(p, monthly_records, engineering_cost, **kw):
    """True unit cost including engineering."""
    c = cost_per_1k(p, **kw)
    return c + 1000.0 * engineering_cost / monthly_records


if __name__ == "__main__":
    # Pangolinfo published tier: Expert $369 / 240,000 credits
    P = 369 / 240_000                     # $0.0015375 per credit
    U = 500_000                           # 500K usable records per month
    E = 30 * 90                           # 30 engineering hours, $90 loaded

    ideal = cost_per_1k(P)
    real  = cost_per_1k(P, m=1.0, s=0.95, v=0.88, r=1.0, beta=1.0, w=0.12)
    tco   = tco_per_1k(P, U, E, m=1.0, s=0.95, v=0.88, r=1.0, beta=1.0, w=0.12)

    print("pricing page   $%.4f / 1K   monthly $%.2f" % (ideal, ideal * U / 1000))
    print("five multipliers $%.4f / 1K   monthly $%.2f" % (real, real * U / 1000))
    print("with engineering $%.4f / 1K   monthly $%.2f" % (tco, tco * U / 1000))
    print("engineering share %.0f%%" % (100 * E / (tco * U / 1000)))

Output:

pricing page      $1.5375 / 1K   monthly $768.75
five multipliers  $2.0899 / 1K   monthly $1044.95
with engineering  $7.4899 / 1K   monthly $3744.95
engineering share 72%

A factor of 4.9 separates the first and last line, and all three describe the same vendor, the same unit price, and the same month. Everything between them is unit conversion.

6.4 What each of the three lines is for

The first line, pricing page terms, is for shortlisting only. Before you have measured your parameters, use it to eliminate options in the wrong order of magnitude. Do not put it in a budget. The second line, after the five multipliers, is for budgeting and reconciliation. It is the expected value of next month’s invoice, and it should land within 15%. A wider gap means a parameter is wrong, most often v or w. The third line, with engineering, is for decisions. It is the only one that answers build versus buy or stay versus switch, because the first two compare invoices and a decision compares total cost.

Putting all three lines side by side in an evaluation doc has a second effect. It moves the review meeting from “is this vendor expensive” to “why is our usable rate 0.85,” and the second question has an answer.

7. Three volume scenarios: 50K, 500K, 5M records

The parameters below follow common Amazon data project shapes, not any vendor’s quote. The unit price is Pangolinfo’s published Expert tier ($369 for 240,000 credits, $0.0015375 per credit), so you can recompute every figure.

7.1 Scenario A: 50,000 records a month, one marketplace, one category

Shape: price and BSR monitoring for one category in one marketplace, one full pass per day. Parameters: r=1 (product detail, one record per call), m=1 (structured JSON), s=0.97, v=0.95, β=1, w=0.05, 8 engineering hours per month.

At this volume the data invoice is 11% of total cost and engineering is 89%. Spending three weeks negotiating the unit price has an upside of eleven dollars a month. Writing the retry policy and automating the quality gate is worth several hundred. At low volume, the thing to optimize is engineering hours, not unit price.

7.2 Scenario B: 500,000 records a month, five marketplaces

Shape: price and BSR monitoring across five marketplaces, twice a day. Parameters: r=1, m=1, s=0.95, v=0.88, β=1, w=0.12, 30 engineering hours per month.

The five multipliers raise the data cost by 36%, and engineering is still 72% of the total. Two actions pay best here: push w from 0.12 to 0.05 through scheduling and concurrency, worth $73 a month, and lift v from 0.88 to 0.95 by moving the quality gate forward, worth $78 a month. That is $151 a month, more than the spread between tiers at this volume.

7.3 Scenario C: 5,000,000 records a month, 13 marketplaces with reviews

Shape: 13 marketplaces, 60% product detail and 40% reviews, near-real-time monitoring. Weighted multiplier m = 0.6×1.0 + 0.4×(5/8) = 0.85, where a review page costs 5 credits and returns 8 rows. Parameters: s=0.94, v=0.85, β=1, w=0.18, 90 engineering hours per month.

Here the data cost overtakes engineering for the first time, so negotiating the unit price starts to matter. The order still holds: push w from 0.18 to 0.05 first, worth $1,365 a month, then negotiate. A discount applied to an optimized denominator is a discount you keep.

7.4 Comparing the three: where the leverage moves

The difference across the three is not the amount. It is where the leverage sits. In scenario A, negotiating the unit price caps out at eleven dollars a month while cutting engineering hours is worth hundreds. In scenario C, ten percent off the unit price and multipliers is close to a thousand dollars a month. Applying the scenario A playbook at scenario C scale, or the reverse, is pulling the wrong lever.

The engineering volumes (8, 30, and 90 hours per month) follow common project shapes, at a loaded rate of $90 an hour. Put in your own numbers and your conclusions may land in a different band, which is the reason to take the formula rather than the answers.

8. The cost that is not on the invoice: parsing, QA, and maintenance

Across the three scenarios, engineering is 45% to 89% of monthly total cost. No invoice carries it, and it decides whether the project survives.

8.1 Three engineering costs and how to estimate each

Initial integration and field mapping: mapping response fields onto your data model, handling nested structures, unit conversion, multi-byte characters, and variant relationships. This cost is one-time and scales with field count and schema stability. More fields and a looser contract mean a larger bill. Estimate in person-days per field, with a separate line for every field needing special handling: price, rank, review timestamps, variant dimensions.

Weekly maintenance and triage: target site changes, broken parsers, fields going null with no error, false alarms, and the operations team asking why a number moved. Published operations surveys put maintenance work for a mid-size collection footprint at 5 to 10 hours per week. To estimate, add up the hours spent on this over the past eight weeks, divide by eight for a weekly average, and multiply by 4.3 for the month. This is the number to compute before any cost conversation.

Quality gate and monitoring build: automated tracking of the four numbers, coverage, fill rate, freshness, and distribution drift, plus the runbook for what happens when one of them fires. See section 5 of Amazon Data Pipelines for the four numbers and threshold guidance.

8.2 Setting a loaded hourly rate

Do not divide base salary by 2,080. That understates the number by 25% to 40%. A loaded rate carries benefits and payroll tax, tooling and cloud allocation, management overhead, and amortized recruiting and onboarding. The common practice is a multiplier of 1.25 to 1.4 on direct salary. For internal comparison, one consistent factor is enough; precision past that adds nothing.

8.3 A test for when to stop optimizing unit price

Multiply monthly engineering hours by the loaded rate to get E, and call the data invoice S. When E > S, your optimization target this quarter is hours, not price: taking maintenance from ten hours a week to three is worth more than any tier discount. When S > 2E, you have reached the volume band where negotiation and architecture work on unit price start to pay. The three scenarios trace that transition: in A, E is far larger than S; in B, E is 2.6 times S; in C, S overtakes E.

9. Five clauses off the price list that set next year’s bill

The pricing page sets month one. The contract sets year two. None of the five clauses below appears on a pricing page, and each one moves year two by more than the spread between tiers.

9.1 How failure is defined, and by whom

Ask for a written definition of one successful call, covering three response types: a 200 with empty business fields, a 200 whose body is a placeholder or a challenge page, and a valid empty result such as a delisted product. The first is the most frequent and the easiest to leave vague. You need a sentence that fits in an acceptance test, not a sentence that sounds reassuring.

9.2 Whether failures bill, and how retries count

Ask three separate questions: are failed attempts billed; are the retries the vendor’s server performs billed; are client-side retries billed. Some vendors retry server-side and bill the request once, others bill each pass. At a 90% success rate this clause is worth 11%, and at 80% it is worth 25% (see the table in 5.1).

9.3 Overage unit price and whether tiers fall back

The price per unit above your bundle runs above the bundle’s implied rate, by a factor between 1.5 and 3 in most contracts. Confirm three things: the per-unit price past the bundle, whether the tier falls back on its own or requires a new agreement, and whether service degrades or stops at the limit. The third is the one that hurts: some plans throttle at the ceiling, and your month-end batch does not finish.

9.4 Downgrades, refunds, and commitment

The common restrictions: one downgrade per month, with the difference returned as account credit rather than cash; no mid-term refund on annual plans; a 12-month commitment on enterprise tiers. Before signing, ask what happens if you need to halve your volume in three months. That answer is worth a month’s invoice the day you pick the wrong tier.

9.5 Multipliers for marketplace, postal code, and rendering, and whether they switch off per endpoint

Multiple marketplaces are not a flat multiple of one marketplace, because target difficulty and therefore multipliers differ by market. Postal-code-level targeting, used to read local price and inventory for a given ZIP, carries its own multiplier. Rendering is the same: if only the search endpoint needs rendering and product detail works over static HTTP, can you enable it for search alone? Can you configure it per endpoint? The answer decides whether the multiplier term in your formula is a constant or a variable you can tune.

10. Three misjudgments: the invoice was right, the unit was wrong

10.1 “Billed per successful request” is not “billed per usable record”

One team ran a plan billed on successful requests. The success dashboard held at 99% for months while cost stayed above budget. The cause: responses returned 200 with a valid shape and an empty price field on 18% of rows. The vendor recorded success, the billing system charged, and the team’s quality gate caught it three days later. Fix: split usable rate out of success rate as its own metric and put usable rate into the reconciliation.

10.2 Billed per result page, budgeted per product row

One team budgeted on 20 rows per call. Measurement returned 12 net rows: pagination delivered 16, cross-page duplicates removed 3, and an ad slot removed 1. The budget was off by 1.67x. Fix: measure r over 200 real queries. Do not extrapolate from the documented ceiling.

10.3 The monthly allowance worked, the per-minute rate did not

One team bought a two-million-allowance tier and spent 1.2 million, forfeiting the rest each month. The refill rate worked out to 50,000 per hour, and their overnight batch window was four hours, so 200,000 would not fit. Fix: move the batch to a rolling window, or split the allowance into a low-frequency baseline plus on-demand burst. That line item was $1,200 a month for this team.

11. Seven questions to get in writing before you sign

Send these seven to the vendor and ask for written answers. A plan that answers all seven has a predictable cost. For a plan that does not, treat the missing answer as a negative signal in itself.

Question 4 is the one teams skip, and its effect on cost rivals the unit price. If you poll every four hours and the vendor’s cache TTL is six hours, half your calls buy data someone already fetched, at full price. Turn that around: if you can require data newer than the TTL, you are paying for an explicit freshness commitment rather than for a probability.

12. Where Pangolinfo sits on this basis

The ten sections above are vendor-neutral and apply to any plan, including ours. This section covers our own unit, and what we do not do.

12.1 Our billing unit and published prices

We use one credit unit, and the per-endpoint multipliers are public and adjustable in the calculator on our pricing page: product detail at 1 credit per page, reviews at 5, niche data at 2, AI Overview at 2, with raw HTML output at 75% of structured JSON because parsing is skipped. Tiers are Starter at $19 for 9,600 credits, Professional at $99 for 60,000, and Expert at $369 for 240,000, with tiered usage billing past Expert and annual billing 20% below monthly. At the Expert tier that works out to $1.54 per thousand product records in structured JSON, $1.15 in HTML, and $1.23 on annual billing.

One question comes up often enough to answer here: why our unit price is not the lowest. The answer is what ships as default. JavaScript rendering is on, the IP grade sits where Sponsored coverage holds, and both costs sit inside the per-endpoint multipliers rather than arriving as a second line later. We keep both facts out of our sales material because they are preconditions for collecting the data, not upgrades. For a like-for-like comparison, multiply the base price of any quote by the four add-ons in section 3, or ask for cost per thousand usable records on the endpoint mix you run.

Substitute those numbers into the formula in section 6 and you can compute your own cost. That is the reason we publish them: unit price is the easiest of the seven parameters to compare, hiding it gains nothing, and recomputability is what makes trust possible.

12.2 Three things we do not do

We do not report success rates on a best-efforts basis. Our published numbers are a median latency of about three seconds, a 99% success rate, more than 30 million calls a day, and a 91.4% sponsored-placement detection rate across 13 marketplaces in published comparisons. Those are checkable figures, not sales language.

We do not present field coverage as field availability. A field on the contract and a field with a value are two different states. We would rather tell you the fill rate for a field in a given marketplace than put a checkmark in a feature table. How to verify that field by field is in The Best Amazon Data APIs, Compared Field by Field.

We do not promise zero maintenance. After you connect an API, the quality gate, the monitoring, and the contract tests still sit on your side. What we can do is compress what you maintain from parsers, proxy pools, and anti-bot work down to a quality gate and business rules. That remaining part does not compress away; see Amazon Data Pipelines.

12.3 Three cases where you should not use us

You need historical price curves only. Multi-year price and BSR time series are a database query, not live collection, and products built for that have a cost structure an order of magnitude below ours.

You need data from your own seller account only. If your scope sits inside your own account and the official selling partner API quota covers it, that is the cheapest route available to you.

A few hundred rows, one time. At that volume, manual work plus a spreadsheet is faster, and integration cost exceeds data cost.

12.4 Ninety minutes to your own true unit cost

If you reach a step where a parameter cannot be measured, that is itself the finding: your current vendor is not giving you the visibility to run the arithmetic. How to verify field-level visibility is in ; how to set refresh cadence and freshness commitments is in .

Whether you take raw HTML and parse it yourself or take structured JSON depends on whether your team has parsing capacity. Both are one parameter apart on the same endpoint in our Amazon Scraper API, with a 25% difference in multiplier. Teams building on agents can use Amazon Data MCP, 19 tools over remote HTTP with no install, billed on the same basis as the REST API.

13. Questions teams ask