SERP API pricing models answer different questions: how work is charged, how much can be in flight, and when purchased capacity expires. Compare those units separately. A large balance does not establish high concurrency, and a concurrency allowance does not establish a fixed throughput.
Read the billing unit before the plan label
| Unit | What to record | What it does not establish |
|---|---|---|
| Search or request | Which successful operation consumes the allowance | The cost of reading every selected page |
| Credit | Operation and add-on charges | That every API call costs one credit |
| Concurrency | Allowed simultaneous requests | A fixed requests-per-second result |
| Time-window limit | The period and reset behavior | The size of the prepaid balance |
| Expiry | Consumption deadline and unused balance | The effective cost at low usage |
A concrete SearchCans example
The current SearchCans Standard plan lists $18, 20,000 credits and two Parallel Lanes. A standard SERP operation uses one credit; a standard Reader extraction uses two. Proxy choices can add credits to an extraction. Browser rendering is a mode choice and does not itself create another billing unit. Check the linked plan and Reader documentation before purchasing or scheduling work.
Use the plan to answer two separate questions: will the balance cover the expected mix before expiry, and will the allowed simultaneous work fit the burst? If your application reads source pages after each search, include those reads in the balance calculation.
| Decision | Input needed |
|---|---|
| Balance size | Charged SERP calls, Reader calls and selected add-ons |
| Worker cap | Account lanes and the application resource limit |
| Renewal or top-up | Expected consumption before the balance expires |
| Higher tier | Measured queue pressure and an actual capacity need |
Avoid two misleading comparisons
A cost-per-thousand figure calculated at full consumption is different from your cost when much of a prepaid balance expires unused. Report both assumptions. Likewise, an advertised dedicated-node option is not your own measurement of request duration or a guarantee that upstream pages always respond.
Use a workflow cost worksheet for mixed SERP and Reader usage. Use a throughput plan for scheduling. This page explains the billing model; it does not select a universal cheapest provider.
Reference documentation: www.searchcans.com — /pricing; www.searchcans.com — /reader-api.
Related implementation and validation guides
- SERP API Cost per Search: Calculate the Complete Workflow
- Plan SERP API Throughput With Bounded Concurrency
A procurement checklist for the billing contract
| Ask before buying | Record the answer |
|---|---|
| What consumes a billing unit? | Endpoint, successful/failed attempt treatment, optional add-ons |
| When do credits or included searches expire? | Expiry date, renewal or reset rule, unused balance treatment |
| What limits simultaneous work? | Concurrency and any per-period allowance; do not infer requests per second |
| Which operations require a separate step? | Search, page reading, document conversion and your own model calls |
| What is an accepted output? | The task-specific check used to calculate cost per usable result |
Apply this checklist to the provider’s current contract. Browser rendering, retries, geography and proxy use are questions to verify; they are not universal extra charges. For SearchCans, the current Reader options distinguish rendering mode from proxy add-ons. Do not transfer another provider’s pricing rule to those parameters.
This explanation absorbs the useful fee-checklist task from the older developer pricing article. It does not retain unsupported budget-overrun percentages. Use current packages for purchase choices and the search-plus-Reader workflow cost model for a complete pipeline calculation.
For the procurement decision across billing horizons, use payment-model and unused-quota calculation rather than compare an advertised unit rate alone.
