Pay per call vs monthly API plans vs official quotas
Official APIs sell a month of capacity. fetcher.sh sells one GET. Credits are a balance, not a subscription.
Most data APIs sell you a month. Official Twitter, YouTube, and Google SKUs come with quotas, seats, and a floor you pay whether you used it or not. SaaS vendors do the same with a dashboard and an invoice. That packaging makes sense when you know you will burn the plan. It is awkward when the job is “fifty searches this week and then silence.”
fetcher.sh sells the call. The price on the endpoint is what that GET costs. There is no monthly plan, no seat fee, and no minimum volume.
If you skip a prepaid key, the server answers 402 and you sign a USDC transfer for that one request. If you would rather not sign every time, a $1 top-up at /topup mints a bby_live_ key and a balance. Credits never expire. They are a prepaid USDC balance — not carbon credits, not Google Cloud credits, not a coupon.
How an agent pays is the 402 loop. This note is the commercial model: month vs call.
Three ways people buy API data
Official quotas. You apply, you wait, you pay for a month of capacity you might not use. The unit is access, billed on a calendar. Unused quota does not roll into a product you can point at a different network. You bought Twitter for June, not “web data.”
Monthly SaaS. A dashboard, a seat, an invoice. Fine when the team will live in the product. You are paying for software around the data, not only the row. Canceling is a calendar event. Adding a contractor is a seat event.
Pay per call. The 402 challenge names an amount. You sign it, or you debit prepaid credits. The ceiling is the wallet, not the SKU. Silence costs nothing. A spike costs the GETs you actually made.
We are not arguing that official APIs are illegitimate. They sell access as a plan. This catalog sells the GET. Enterprise firehose contracts and RapidAPI subscriptions are different products; we do not pretend to be those.
Credits on fetcher.sh also are not a plan in disguise. There is no auto-renew. There is no “use it or lose it” month. A dollar you topped up in August is still there in February if you did not spend it.
How to think about the unit price
People compare a single fetcher.sh GET to a blended “per 1k” line on an official invoice and declare a winner. That comparison is usually the wrong one.
If you are ingesting a firehose, the official bulk SKU will often win on unit cost. If you are an agent that wakes up, needs twenty rows, and sleeps, the official SKU is a month of capacity for twenty rows. The fetcher.sh GET is twenty prices on a page.
If you are a product that will call search a million times a month, sit down with both numbers. Pay-per-call is a shape, not a claim that every unit is cheaper than every official plan. Burst, experiment, and agent workloads are the jobs it fits without argument. Steady, enormous, single-platform ingest is a different conversation — and often a different contract.
Prices live on each endpoint page and in /docs. Eligibility — no official developer account — is a separate note.
A case: a spike, then nothing
A founder ships a landing page that demos “search X for your brand.” For two days after a launch tweet, traffic is real: a few thousand searches. Then it dies down to a handful a week.
On a monthly Twitter API plan, those two days still cost the month. On a SaaS SERP tool, the seat runs until someone remembers to cancel. On fetcher.sh, those two days cost the GETs they actually made. The quiet weeks cost almost nothing. Credits left on the key are still there in six months.
That is the point of pay per call. It is not cheaper per unit than every official SKU — some official bulk plans win if you are a firehose customer. It is cheaper as a shape when volume is bursty, experimental, or agent-driven.
The same founder later adds a Maps demo on the same page. That is a second official SKU in the monthly world (Places API billing in Cloud) and a second host in this catalog, same prepaid key. The commercial model does not fork just because the object did.
A case: a student project that should not have a card on file
A class assignment asks for public Reddit threads and Play reviews as JSON. The student should not put a personal card on a Cloud billing account that is easy to forget. They should not apply for Reddit API approval for a two-week homework.
They top up a dollar. They run the GETs. When the course ends, they stop. Nothing renews. Nothing is waiting in an email for a professor to approve an app.
If the assignment grows into a thesis that hammers the same endpoints all year, they can keep topping up. They still are not on a seat plan. They still are not on Reddit’s partner queue.
What a call looks like
With no key, GET https://twitter.fetcher.sh/api/search?query=hello returns 402. With Authorization: Bearer bby_live_…, the same GET debits the prepaid balance. Minimum credit purchase is $1.
If you are deciding between “sign every 402” and “keep a key in the environment,” use a key for anything you will call more than a handful of times. Use 402 when the client is an agent that already holds a wallet and should not store a secret.
MCP clients follow the same split. Point them at https://mcp.fetcher.sh. Paid tools charge; free tools (search_endpoints, describe_endpoint, check_balance) do not. The envelope is still JSON. The invoice is still “what you called,” not “the month you existed.”

