We priced our API at one cent per call. Here is what happened

When we decided to open up our social stats endpoints, every playbook said the same thing: free tier, three paid tiers, annual discount, API keys, a dashboard, usage alerts, and a sales motion for the enterprise tier. We threw the playbook out and shipped one price instead: $0.01 per request, paid in USDC on Base, per request, with no accounts at all. I want to explain the reasoning like a founder rather than a landing page, because the reasoning is the product.

Subscriptions tax the wrong thing

A subscription prices commitment, not usage. The customer pays for the month they might need, and the vendor's incentive quietly becomes maximizing the gap between what is paid for and what is used. Every API pricing page with a "contact us" tier is monetizing that gap. It works, but it selects for a specific customer: one with a credit card, a procurement process, and predictable monthly volume.

Our expected caller looked nothing like that. Someone verifying a single influencer post. A notebook analyst pulling two hundred numbers for one report. And increasingly, software: AI agents that decide mid-task they need a view count, with no human available to sign up for anything. For all three, the natural unit of consumption is the request, so we priced the request. One question, one cent. The full argument against key-based access for this traffic is in x402 vs API keys.

Why a cent, specifically

The price had to clear three bars. It had to cover our real cost per lookup, including upstream data infrastructure, with margin. It had to be low enough that nobody does mental math before calling; at $0.01, checking a stat costs less than thinking about whether to check it. And it had to be high enough to make abuse economically boring: hammering us a million times costs an attacker ten thousand real dollars, which is a better rate limiter than most rate limiters.

One cent also survives contact with real budgets beautifully. A creator vet is a dime. A month of daily monitoring on a 50 post campaign is $15. A serious research dataset is a hundred bucks. Nobody has ever had to ask their manager for approval, which means nobody churns from a plan they forgot they had, because there is no plan.

What x402 removed from our roadmap

Choosing the x402 protocol over Stripe-plus-keys deleted entire subsystems before we wrote them. No signup flow, so no email verification, password reset, or OAuth. No API keys, so no key issuance, rotation, revocation, or leaked-key incident response. No metering-to-invoice pipeline, no dunning emails for failed cards, no refund ops. Payment settles per request, atomically with the work: the middleware challenges with a 402, the client signs a USDC authorization, a facilitator verifies and settles on Base, and our handler runs. The settlement receipt goes back in a response header. Billing disputes are structurally impossible, because there is no bill, only receipts.

We spent some of that saved complexity on fairness rules we could actually enforce in code: validation failures return HTTP 400 and 4xx responses are never charged, upstream outages on our side return an unpaid 502, and a lookup that runs but finds nothing returns a paid {"success": false, "error": "not_found"} because an answer is an answer. Try getting that precision out of a monthly invoice.

What happened

Three things, roughly in order of how much they surprised us.

First, the funnel inverted. With key-based APIs, the funnel is docs, signup, sandbox, integration, first real call, and every step leaks users. With x402, the first real paid call is the funnel: curl the endpoint from the quickstart, see the 402, wire a client, done. Time from landing page to paying customer is measured in minutes, and "paying customer" starts at one cent, a bar low enough that curiosity converts.

Second, agent traffic behaves differently than human traffic. Humans integrate once and call in bursts. Agents discover the API through llms.txt and the OpenAPI spec, then call steadily, in odd but rational patterns: daily monitoring sweeps, ratio checks before decisions, time series polling around viral moments. Per-request pricing means we never had to predict those patterns to bill them correctly. Agents cannot hold subscriptions, but they are excellent at holding wallets, and a wallet-holding cron job is a customer that never churns as long as it keeps finding the data useful. The pattern is documented from the buyer's side in building a social listening agent with a wallet.

Third, pricing became marketing. "$0.01 per request, no signup" fits in a tweet and answers every objection at once. There is no pricing page to negotiate against, no fear of the surprise tier upgrade, no anchor to a competitor's $99 plan. The price is the whole pitch, and it is verifiable in sixty seconds for a cent.

The honest tradeoffs

This model is not free lunch. Requiring a crypto wallet is real onboarding friction for teams who have never touched USDC, even if funding one takes minutes; we wrote a whole guide to soften it. Revenue is less predictable than subscriptions, which finance people dislike. And per-request pricing only fits when marginal cost per call is real and legible; if your costs are fixed, subscriptions may honestly fit better. We think the tradeoffs land firmly on our side for data APIs serving mixed human and agent traffic, but we got here by economics, not ideology.

Context matters too: the API is not our business, it is our business's measurement layer, opened up. FindClout sells native brand placement inside viral clips across the biggest independently owned American meme page network, spanning sports, finance, entrepreneurship, movies, TV, and music, and advertisers verify our delivered views with these exact endpoints. Charging a fair cent for the same lookups we run ourselves keeps the API sustainable without needing it to be a rocket ship. That story is in why FindClout built this API.

If you run an API and the subscription model has been quietly mispricing your smallest and strangest customers, steal this playbook. It is one middleware and one decision.