Pay-as-You-Go vs Subscription API Pricing: Model Real Use

Choose an API payment model using the workload over its billing and expiry horizon. Pure pay-as-you-go, a monthly subscription and a prepaid credit pack differ in when cash is paid and what happens to unused capacity. A low advertised unit price is not necessarily a low cost per successful output.

Three payment models, three different assumptions

SearchCans published plans are prepaid credits valid for six months, with usage deductions; do not label them pure postpaid billing. The validity is six calendar months rather than a universal 180-day promise. Standard SERP uses one credit, standard Reader uses two, and proxy options add their documented credits. A mixed workflow cannot be costed as one credit per output.

Calculate cash and utilization separately

Use the same horizon for all options. The example models one prepaid pack only, within its validity, and a subscription that remains active throughout that horizon. All generic pay-as-you-go and subscription rates in the worked example are hypothetical, not vendor quotes.

from decimal import Decimal

def payment_options(monthly_units, payg_unit, subscription_monthly,
                    subscription_units, overage_unit, prepaid_price, prepaid_units,
                    validity_months):
    if validity_months < 1 or any(x < 0 for x in monthly_units):
        raise ValueError("Valid horizon and nonnegative workload required")
    if len(monthly_units) > validity_months or sum(monthly_units) > prepaid_units:
        raise ValueError("This example models one prepaid pack within its validity")
    total = sum(monthly_units)
    payg = Decimal(str(payg_unit)) * total
    subscription = sum(Decimal(str(subscription_monthly)) +
        Decimal(str(overage_unit)) * max(0, u-subscription_units) for u in monthly_units)
    return {"payg":float(payg), "subscription":float(subscription),
        "prepaid_cash":prepaid_price, "prepaid_unused_units":prepaid_units-total,
        "prepaid_effective_unit":prepaid_price/total if total else None}

A bursty-workload example

For an illustrative six-month workload of 5,000 units in the first month and zero thereafter, set hypothetical postpaid usage at $0.002 per unit, a subscription at $20 per month with 10,000 units included, and one $18 prepaid pack containing 20,000 units. The calculated cash totals are $10, $120 and $18 respectively. The prepaid pack leaves 15,000 unused units. This example deliberately shows that a lower advertised pack rate need not be the lowest cash purchase for small demand.

That calculation assumes a continuously active subscription and one pack. If the buyer can cancel, pause, upgrade or use a free tier, model those choices explicitly. For continuous demand, allocate usage by month and check each allowance. For demand extending beyond expiry, divide it into separate purchase horizons; the function rejects an input it cannot represent.

Check the delivered unit

Count successful searches, successful extractions, proxy additions and your own downstream processing separately. A service credit is not a common currency between vendors. Record peak concurrency independently from volume; a pack’s size says nothing about how quickly a burst can finish.

Use SERP billing terminology for units and quota language, search-plus-Reader workflow costing for the operation mix, and the concurrency terminology for request capacity. This page owns the payment-model decision, without duplicating those jobs or promising a fixed savings percentage.