SATIK DEVELOPER DOCS · V1 BETA
Your checks. Ready when you are.
Understand prepaid checks, available balance, request limits and refunds.
One wallet, no monthly reset
Each workspace receives 100 free Test Ride checks once. Paid recharges add checks to the same wallet. Checks never expire, and there are no subscriptions, recurring charges or monthly resets. Pack size changes how many checks you buy; API capabilities do not depend on the pack. See /pricing for current packs and /billing to manage your workspace balance.
What spends checks
One check is stored as ten integer tenths. Successful fresh verification costs 1 check. Eligible evidence-cache hits and live normalization cost 0.1 checks. DIGIPIN tools, outcome reporting and balance reads spend no checks. Test-key samples spend no wallet checks. A completed idempotent replay returns the saved result without another debit; authentication and request limits still apply. A new request for the same address is not an idempotent replay.
Total versus available balance
GET /v1/usage returns balance_tenths, available_tenths, lifetime_credited_tenths and lifetime_debited_tenths. Divide by ten to display checks. Total balance includes held checks; available balance excludes active usage reservations and pending refund holds. For example, 1,000 total tenths with 200 held means 100 total checks and 80 available. Lifetime credited counts grants; lifetime debited counts net usage, not refund reversals, so subtracting these counters is not a reliable current-balance calculation. A wallet under billing review can also be unavailable for spending; contact support if holds do not explain the difference.
Reserve before processing
A fresh verification reserves one check before work starts. A batch reserves one check per address for the whole batch at acceptance, even if some addresses may later qualify for cache hits. Successful work settles its actual charge and releases unused held checks. Failed work and cancelled unstarted rows release their holds. Started rows follow the normal cancellation and worker-recovery rules. HTTP 402 insufficient_credits means available checks cannot cover the requested work; a positive total balance alone does not guarantee acceptance.
Request limits for every pack
Rate limits are per API key. Live DIGIPIN traffic has a separate bucket from other live API requests. Test keys retain their lower limit, including DIGIPIN calls. Free operations still require authentication and count toward their request-rate limit. Read X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset; on HTTP 429, wait for Retry-After before retrying.
| Operation | Limit |
|---|---|
| Live API requests, excluding DIGIPIN | 100 requests per minute per key. |
| Live DIGIPIN | 600 requests per minute per key, in a separate bucket. |
| Test keys | 5 requests per minute; DIGIPIN and other API requests use separate buckets. Test keys cannot submit batches or report live outcomes. |
| Batch size | Up to 500 addresses, with enough available checks to reserve the full batch. |
| Signed webhooks | Available to every workspace; configure event selections in Webhooks. |
Recharge and confirm payment
Workspace owners can open Usage & billing and choose Recharge when billing is enabled. Razorpay Checkout collects the payment; checks are added only after the server verifies a captured payment. Closing the modal or seeing a browser success callback alone does not prove credit. Check the refreshed balance and recharge history, where each purchase has its matching invoice. If confirmation is delayed, let reconciliation resolve it instead of making another payment immediately. Captured payments that cannot be credited are retried and can be refunded through recovery. Checkout currently supports controlled Razorpay test-mode acceptance; it is not a claim that production payments are enabled.
Refund a specific purchase
A paid purchase can qualify within 7 days when the available wallet balance covers all checks it added. Checks are fungible: there is no last-pack or per-pack consumption tracking, and a later recharge can restore eligibility within the earlier purchase's window. Free trial checks have no refundable purchase. A refund request holds the purchase's checks; only confirmed processed success deducts them. A confirmed failure releases the hold without changing total balance; an uncertain result remains pending. A purchase with an existing refund request cannot be submitted again, including after failure. Owners can request refunds in Usage & billing when enabled; contact hello@satik.in for failed or pending cases. See /refund-policy for the full policy.
Related references
Use the balance API before planning work; a balance read is a snapshot, not a reservation. Concurrent requests can change available funds before your next operation.
| Reference | Use it for |
|---|---|
| Wallet balance API | Read total and available checks and lifetime usage. |
| Batch verification | Reservations, cancellation and results. |
| Idempotency and retries | Retry an operation without another charge. |
| Refund policy | Eligibility and pending or failed refunds. |
| Recharge packs | Current pack sizes and prices. |