The promise
When you list an API on ApyHub, you sell atoms — our universal usage unit. The deal between you and us has two knobs and only two knobs:
- What one atom is worth. Your subscription rate is the floor — a flat per-atom payout we contractually owe you for every call we route from a Pro/Pro+/Team/Scale customer. That number doesn't change with the customer's specific plan, balance, or any plan-tier discounts we run.
- The top-up upside. When the call comes from a customer who paid for atoms à la carte, we share the revenue we collected on those atoms 50/50 — but never below your floor. Run-of-the-mill: top-ups pay you noticeably more than subscription calls. During a promo where we charge customers a discounted rate: the floor takes over, you still earn at least your subscription rate, we eat the difference. Your floor is a contract; the top-up share is upside on top.
- How many atoms a request costs. You decide. You tell us when you answer the call: "this one was 1 atom" or "this one was 200." We deduct that many atoms from the customer's balance and credit you the right rate × that many.
Together they give you precise pricing power without surface-area to renegotiate. The floor is contractual stability; the 50% top-up share is upside that scales with retail; the atoms-per-request dial is the lever you pull when your real cost changes — adding a premium model variant, an expensive input path, a long-running operation. The customer pays for what each request actually took.
What you control
The atoms-per-request dial is real control, not a knob with a ceiling. You set it at response time, per call. Some patterns you'll likely use:
Per-endpoint base cost
Different endpoints serve different value. A "geocode" lookup that hits a cache might be 1 atom. A "summarize this document" running a frontier model might be 250. You set a base atom count per endpoint when you publish.
Per-request adjustment
The same endpoint can charge differently per call based on actual work done — input size, output tokens, model selected, whether the cache hit. You report the final atom count when you answer. A 4K-token generation isn't priced like a 40K-token one.
AI cost passthrough
The case providers ask about most: your upstream model gets more expensive, or you switch to a premium one. The fix is local — you increase atoms-per-request on the affected endpoint. Your margin per atom is unchanged (the contract rate stays put); your revenue per request scales with the new cost; the customer pays the real cost. Nobody's renegotiating.
Plan against your floor: atoms_charged × subscription_rate is the worst case for any call. Top-up calls land somewhere between that and 2× that, depending on retail pricing at the time of purchase. Your margin per request = revenue − your_upstream_cost. You set atoms_charged at response time; we report back which source the call came from on the request log. No per-customer guesswork.
What we absorb
You control per-request atom cost; we control how those atoms get packaged and sold. A few specific kinds of risk land on us so the rate you see stays clean:
Free-tier exploration
Every prospective customer starts on the free Starter tier with 5 calls. They've paid us nothing. We still pay you the full subscription rate per atom for every call we route to your endpoint. That is our customer-acquisition cost — your endpoint gets discovered, we eat the bill.
Subscription-tier volume discounts
A Scale customer pays a much lower effective per-atom rate than a Pro customer because they committed to a big bundle. You still earn the full subscription rate per atom on every one of those calls. We give the discount; we eat the smaller margin.
Top-up promos
When we run a promotion on top-up pricing — flash sales, holiday discounts, partnership credits — your subscription rate floor stops the discount from reaching your line. We collect less per atom from the customer; you still earn at least your floor; the gap comes out of our share, not yours.
Billing, fraud, tax, and the rest
Gateway routing, atom accounting, throttling, abuse detection, chargebacks, dunning, tax remittance, customer support, regulatory compliance — all of that runs out of our share. None of it shows up on your line.
Why you don't worry about plan tiers
On the customer side, things get complicated. There are multiple subscription plans, volume discounts, top-up packs, coupon campaigns, free-tier trials, regional currency conversions, fraud risk, chargebacks, tax remittance, and a renewal worker that has to handle all of it without missing a beat.
None of that is your problem. You sell atoms to us at the two flat rates indexed by source. We run the whole customer-facing apparatus, deal with whatever it throws at us, and pay you predictably at the end of every cycle.
A worked example
A fictional month for a provider running three endpoints — one cheap, one heavy, one premium — to show how the two knobs work together. We'll use €0.000035 as the example subscription rate (your floor). The top-up payout is the higher of "50% of retail revenue per atom" or your floor — your dashboard does the math per call so you don't have to. Your actual numbers live in your contract and dashboard.
Step 1 — you set the per-request atom cost
/geocode(lookup, mostly cache) → 1 atom per call/ocr(vision model, scales with input pages) → 10–80 atoms per call, you decide at response time/summarize(frontier LLM, scales with token count) → 50–500 atoms per call
Step 2 — traffic over the month, split by source
Of the 7.4M atoms served, 6.6M came from subscription customers and 800K from top-up customers — half of those purchased at full retail, the other half during a 30%-off weekend promo. The math per slice:
- Subscription atoms: 6,600,000 at the floor rate → 6,600,000 × €0.000035 = €231.00
- Top-up atoms (full retail): 400,000 at 50% of retail per atom (above floor) → ~€44.00
- Top-up atoms (promo retail): 400,000 at 50% of retail per atom (below floor → floor kicks in) → 400,000 × €0.000035 = €14.00
Total earned: €289.00 across 7.4M atoms. The promo slice didn't drop you below the contract — the floor handled it; we ate the discount. On the full-retail top-ups you earned ~3× the subscription rate per atom, the way 50% of full-rate revenue tends to play out.
Step 3 — your costs go up mid-month
Say the LLM you use for /summarize raises prices 30%. Your fix: bump the atoms-per-request range from 50–500 to 65–650. Same call now costs the customer ~30% more atoms; your revenue per call scales with it; your per-atom rate is unchanged (subscription calls keep the floor; top-up calls keep the 50% share or floor, whichever's higher). Customer sees the new cost transparently on their bill. No renegotiation with us, no waiting on a contract amendment.
What you see in your dashboard
The provider dashboard surfaces a few numbers per cycle:
- Subscription atoms served — successful calls from Pro / Pro+ / Team / Scale customers, paid at your floor rate.
- Top-up atoms served — successful calls from customers using prepurchased atoms, paid at 50% of retail revenue per atom or your floor (whichever's higher).
- Floor rate — your contractual subscription per-atom rate. If we ever change it, we give you 60 days notice in writing before the new rate takes effect.
- Earnings — the rolled-up total. One transfer at the end of the cycle.
- Per-endpoint breakdown — informational. Shows you which endpoints are pulling weight.
Failures don't show up — atoms only count on successful responses (HTTP 2xx, plus the small set of 4xx classes the customer pays for). You're never paid for a call that didn't deliver value to the customer, and you're never charged for one either.
FAQ
Why a floor instead of a pure percentage split?
A pure percentage split would tie your per-call payout to every pricing knob we ever touched — plan tiers, top-up promos, regional currency moves. The floor severs that link for the bulk of your revenue (subscription calls), and the 50% share gives you upside on top-up calls when retail is at full strength. You're contractually safe; we have room to run promos to drive top-up adoption without renegotiating with you.
What if my upstream costs go up?
You raise atoms-per-request. Either bump the base cost on the affected endpoint, or scale per-call (e.g. atoms proportional to input size or output tokens). Your margin per atom stays at the contract rate; your revenue per request scales with the new cost; the customer pays the real cost. No renegotiation, no downtime, no waiting on us.
How do I price a request fairly?
You know one number on your side: your cost to fulfil this request. Plan against the floor — your subscription rate. Take your cost, multiply by your target margin, divide by the floor rate, and you have the atoms-per-request to charge. Top-up calls then earn 50% of retail revenue per atom (above the floor when retail's at full strength) on the same atom count — that's upside on top, not something you have to model separately.
What about errors / timeouts / failed calls?
Failed calls don't earn. The atom counter only ticks on successful responses (HTTP 2xx, plus the small set of 4xx classes the customer pays for — auth failures and not-found, never your server-side errors). You're never paid for a call that didn't deliver value to the customer.
Can I price two endpoints differently?
Yes — that's the point. Each endpoint has its own atom cost, settable at publish time and adjustable per-request. A geocode endpoint at 1 atom and a summarize endpoint at 200 atoms can sit side-by-side on the same provider profile. Customers see the per- endpoint price up front; you keep the per-call flexibility.
When do I get paid?
Monthly, in arrears. Earnings for a calendar month settle on the 15th of the following month, paid via bank transfer to the account on your provider profile. Minimum payout threshold is €50 — anything below rolls forward to next cycle.