Limits and release status
Supported capabilities, concrete limits, current distribution, and known boundaries.
Download this chapterOn this page
This handbook describes the staging preview reviewed on September 9, 2026. It distinguishes implemented behavior from unavailable features and source-integrated packages from public registry releases.
Current distribution
| Surface | Status |
|---|---|
| Hosted dashboard and API | Staging preview at app-staging.cherrysub.com / api-staging.cherrysub.com |
| CherrySub CLI | Standalone macOS, Linux, and Windows builds for amd64/arm64; defaults to staging |
| Swift package | Source-integrated AppVisionIAP; Apple platform minimums are in its guide |
| Kotlin core and Billing adapter | Source-integrated 0.5.0 coordinates |
| TypeScript / Dart core | Source-integrated 0.5.0; public registry publication disabled |
| Flutter storefront adapter | Source-integrated 0.3.0 consuming Dart core 0.5.0 |
| Trusted Go SDK | Source/module package, version 0.2.0 |
| Production hosting | Planned/reviewed separately; staging is not a production availability commitment |
The AppVisionOS import/package names are the current code names. Do not replace them with invented @cherrysub/* or pub.dev/Maven coordinates in your build.
Concrete limits
| Boundary | Limit or default |
|---|---|
| Runtime receipt/ingest request body | 256 KiB |
| Hosted account/dashboard JSON body | 32 KiB; catalog-import endpoints alone accept 1 MiB envelopes |
| Catalog import source file | 512 KiB, 2,000 normalized configuration entries |
| Dashboard store selection | Up to 100 pages and 1,500 products; import entry limit still applies |
| CLI purchase file | 64 MiB, 20,000 records; StoreKit 2 JWS or Google tokens |
| App User ID | 1–512 UTF-8 bytes |
| Customer-token lifetime | Default 3600 seconds; 300–86400 allowed |
| Hosted session lifetime | Default seven days; operator-configurable between one minute and 30 days |
| Verification / reset / invitation link | 24 hours / 30 minutes / seven days |
| Password | 10–72 bytes at the backend; uppercase, lowercase, and special character required |
| Apple credential validator | PEM up to 16 KiB |
| Google credential validator | Service-account JSON up to 64 KiB, subject to the lower hosted-envelope ceiling |
| Customer support notes | 20 per customer; 1000 UTF-8 bytes per note |
| Dashboard dataset page size | Default 50, maximum 100 |
| Relative chart windows | 7, 28, 90, 365 days |
| Custom chart windows | Daily 366 days; weekly five years; monthly ten years |
| Interactive chart query/cache | Eight-second DB deadline; 30-second in-process cache |
| Overview history | Latest 180 UTC days |
| Export requests | One active job/account; ten requests/project/account per rolling 24 hours |
| Export output | 500,000 rows, 32 MiB, ten-minute query deadline |
| Export retries / download link | At most five lease attempts / 24 hours |
| Product package position | Integer 0–1000, unique within its set |
| Webhook event filters | At most 100; default access.changed |
| Outbound derived payload / response excerpt | 20 KiB / 64 KiB |
| Webhook retry window / secret overlap | 72 hours / 24 hours |
| Default core receipt throttle | 100 requests/second, burst 200 per API-key hash, per process; deployment overrides can be lower |
The Google validator's 64 KiB maximum is not the effective hosted upload allowance: JSON escaping and the 32 KiB hosted request-body cap can reject a large file earlier. Normal service-account key files are much smaller; a large-file failure must not be presented as a successful save.
Store setup boundaries
CLI Google browser authorization needs an organization-provided Desktop OAuth client. A CherrySub-owned verified OAuth client is not bundled. Apple automated sign-in uses Apple's web-session endpoints and may need console action when those endpoints, agreements, or key limits change.
CLI setup provisions credentials; it does not currently create complete RTDN infrastructure. Google push audience/service-account verification is deployment-level. Store notification wiring and an actual sandbox purchase remain separate validation steps.
Automated setup has local protocol/flow tests and staging API contract checks. The preview's original provisioning implementation was not validated by creating keys in a real Apple/Google account during development. Operators should validate that final step with their own authorized store account.
Reporting boundaries
Currencies remain separate; net revenue is before any unmodeled taxes/commission. There is no predictive LTV, tax-net proceeds, global exchange-rate normalization, or complete history invented from a recent import.
Run rate uses effective observed service duration, including its extension effects. Partial-month movement calculations can include broader bucket boundaries. Review source evidence for precise partial-period or financial-close comparisons. Cohort windows and maturity are deliberate and differ across metrics.
Features not offered by this version
There is no hosted paywall layout editor, A/B assignment, arbitrary customer merge/alias-management API, manual per-customer premium override, store refund-issuance console, general bulk provider-history import, or self-service customer/project data deletion flow.
Product sets present ordered store products; they do not include user targeting, localized storefront price computation, or store offer creation. Store restore/ownership behavior must be tested against your application's account policy rather than assumed identical to another provider.
How to evaluate a change
Use the test matrix, metric definitions, and complete API contract. For a missing capability, define the exact user flow and required evidence before treating an interface label or a future production design as implemented functionality.
Migration scope
RevenueCat catalog reads, connected-store product import, portable CSV/JSON catalog plans, and resumable verified-purchase CSV ingestion are available in the current staging implementation. Catalog imports are additive and atomic. Google subscription base plan IDs can be preserved in imported packages, but access is still mapped by subscription product; differing base-plan entitlement policies require review and block automatic RevenueCat import.
There is no automatic paywall, experiment, targeting, customer-alias, or complete historical financial import. The purchase command performs normal verified receipt ingestion, can emit webhooks, and does not support legacy Apple StoreKit 1 receipt blobs. Provider history and token-retention limits still apply. Migration guide.