Changelog
Initial public changelog. Dated entries for what's shipped in the AskBiz developer API and dashboard — idempotency, rate limits, pricing, scoped permissions, webhook tooling, and usage visibility.
This is the first entry in the AskBiz API changelog. It covers seven changes shipped together as the baseline for the public developer docs launching today, 2026-07-17. Going forward, new entries are added above this batch as they ship.
Sandbox (test-mode) API keys
Create a test key (abz_test_…) from the Keys page, or toggle Test when creating a new one — it’s the default for a first key. On /api/v1/scan, /api/v1/whatsapp/send, and /api/v1/charges, a test key always returns a realistic canned response and never debits your balance, sends a real WhatsApp message, or creates a real Stripe charge. /api/v1/ask answers for real on both test and live keys, since it’s never billed and only reads your own data. /api/v1/connections isn’t sandboxed yet — it still requires a live key. Test keys are immutable once created — start a new key if you need a different environment.
Apps — optional named grouping for your keys
Create an app from the dashboard Apps page (name, logo, redirect URI) and assign your keys to it. Purely additive — a key with no app keeps working exactly as before. Once a key that created a connection is grouped under an app, the merchant sees that app’s name and logo on the /connect consent screen instead of an unbranded request.
Interactive API console in the dashboard
A new Console page lets you fire a real request at any core endpoint (ask, scan, whatsapp/send, connections, charges) using your own key, directly from developer.askbiz.co/dashboard/console — no terminal or client code required to see an actual response, with live status, latency, and rate-limit-remaining shown alongside it. Your key is sent through for that one request only and is never stored, logged, or re-displayed. Paste a test key to try it with no real side effects (see the sandbox-keys entry above), or a live key for the real thing.
Durable, cross-instance rate limiting on every endpoint
The per-minute limiter now uses a shared, atomic database counter instead of an in-memory count local to whichever server handled the request — the previous version could under-enforce your plan’s per-minute limit under real concurrent traffic. POST /api/v1/ask also now returns X-RateLimit-Limit and X-RateLimit-Remaining headers, matching /scan and /whatsapp/send.
Idempotency-Key support on /scan and /whatsapp/send
Send an Idempotency-Key header on POST requests to /api/v1/scan or /api/v1/whatsapp/send. Retrying with the same key returns the original response instead of re-running the call — no duplicate WhatsApp sends, no duplicate vision calls, no double charge. Not supported on /ask, /connections, or /charges.
Live pricing at GET /api/v1/pricing
A public, unauthenticated endpoint returning per-call prices for billed endpoints, plan-level rate limits, and a note that only successful calls are ever billed. No x-api-key required — check pricing before writing any code.
Rate-limit response headers (X-RateLimit-Limit / X-RateLimit-Remaining)
Every /api/v1/* response now includes X-RateLimit-Limit and X-RateLimit-Remaining, reflecting your plan’s per-minute limit (free 5/min, growth 60/min, business 120/min).
Low-balance warnings in API responses
When a billed call pushes your wallet below its low-balance threshold, the 200 response now includes low_balance_warning: true and the current balance_cents in-band — you find out at the moment it happens, not only when a later call fails with a 402.
Scoped permissions for merchant connections (read_inventory)
POST /api/v1/connections accepts a scopes array when requesting a merchant connection. The merchant sees exactly which permissions were requested on the consent screen and can untick any before approving. read_inventory is currently the only scope, and it’s what unlocks the merchant_id parameter on POST /api/v1/scan.
Webhook test-ping and delivery log in the dashboard
The Webhooks page in the developer.askbiz.co dashboard now has a Send test event button that enqueues a real synthetic delivery through the same signing path as production events, plus a View deliveries panel showing recent delivery status and attempts — use both before relying on a real sale.created, purchase_order.received, or stock.low event.
Spend visibility and billing history in the Usage dashboard
The Usage dashboard now surfaces per-endpoint call counts and spend alongside your current plan’s monthly and per-minute quotas, so you can see where your credits are going without cross-referencing invoices.
What’s not on this list
This changelog only records real, shipped changes. It does not include planned or in-progress work — see API Reference for the current state of every endpoint and the webhooks guide for the full event-delivery contract, including the ~5-minute cron sweep latency.