Understanding AskBiz billing and pricing

Three mechanisms, not one

It’s tempting to think of API usage as a single meter that goes up. AskBiz actually runs three independent mechanisms, and an integration that doesn’t distinguish them will eventually build the wrong assumption into its billing logic.

• Per-call wallet debits — only POST /api/v1/scan (3¢) and POST /api/v1/whatsapp/send (2¢) touch your wallet, and only on success.
• Plan quota — POST /api/v1/ask is free but capped by your plan’s monthly and per-minute limits; there’s no wallet debit at all.
• Billing-on-behalf-of — POST /api/v1/charges collects money from a merchant’s customer via Stripe Checkout. That money is not charged to you, and it is not (yet) automatically paid out to you either.

Get the live numbers for the first mechanism from GET /api/v1/pricing before you hardcode a price anywhere — it’s public, unauthenticated, and it is the source of truth over any number written in prose (including this lesson).

Why only two endpoints are billed per call

Scan and WhatsApp-send are the two endpoints with a real, variable marginal cost behind every call — a Groq vision inference, and a Meta-billed WhatsApp message send. POST /api/v1/ask runs against a shared LLM budget that’s cheaper to cap with a plan quota than to meter per call, which is why it’s free-within-quota rather than wallet-billed. This isn’t an arbitrary pricing choice — it tracks actual cost structure, and it’s worth designing your own usage limits around the same distinction: cap the free endpoint by request volume, budget the paid ones by wallet balance.

What “billed only on success” actually means

Every 4xx and 5xx response on scan and whatsapp/send is unbilled by construction — the debit only fires after the underlying action actually completes (a real vision match came back, Meta confirmed the send). This has a direct consequence for how you should build retry logic: a failed call costs you nothing to retry, so the only thing an Idempotency-Key protects against is a successful call whose response you never received — not a failed one. Don’t withhold retries out of fear of double billing on errors; the billing model already handles that case for you.

Where currency conventions genuinely diverge

This is the part worth being precise about, because assuming one unified currency across the platform is the most common mistake here:

• GET /api/v1/pricing labels per-call prices generically in cents (usd_cents) — a unit, not a live FX-converted charge.
• Wallet top-ups are billed in GBP, in fixed £5 / £20 / £100 bundles — there is no arbitrary top-up amount.
• POST /api/v1/charges defaults its currency field to gbp if you don’t specify one, and accepts amount_cents between 100 and 10,000,000 (£1–£100,000 at the default currency).

Each of these is internally consistent and accurate in its own context. The mistake isn’t in any one of them — it’s in assuming they share a currency because they share an API.

What this means for your own pricing display

If your integration shows a merchant or end-customer a price derived from any of these three mechanisms, show the currency explicitly rather than inferring it from context. A charge you create defaults to GBP; don’t assume it matches the merchant’s local currency without checking what you passed ascurrency.