Feature
Server-side entitlements
Gate any feature from any backend. Tierux verifies purchases with the store and returns normalized entitlement state — one REST call, no client-side secrets.
| Capability | With Tierux | Without Tierux |
|---|---|---|
| Store verification | Server-side via Android Publisher / StoreKit 2 JWS | Manual API calls, per-platform logic |
| Token storage | Hashed for dedup, AES-256-GCM encrypted for refresh | Custom — often raw tokens in plain DB columns |
| Entitlement state | Normalized (active/expired/grace) across Android + iOS | Ad-hoc, platform-specific parsing |
| Multi-platform | One API, same response shape | Separate code paths per store |
| Server integration | REST — any language, any backend | Custom middleware and store SDKs |
| RTDN / webhook processing | Auto-processed — renewals, expiries, cancellations | Must build and maintain Pub/Sub + App Store Server Notifications |
| Pricing model | Flat monthly fee, no revenue tax | % of tracked revenue or free — but dev time is expensive |
Tierux is pre-launch. We ship server-side verification and entitlement state today, and we're building toward the full feature set that mature platforms offer.
Related features
Purchase verification
Send a purchase token to Tierux — it verifies with the store and returns active/expired/grace-period state.
Entitlement mapping
Map any store product to an entitlement ID — one consistent API to check access across platforms.
Quickstart docs
Wire up the REST API in minutes with curl examples and language-agnostic endpoints.
Frequently asked questions
What are server-side entitlements?
Server-side entitlements mean your backend — not the client — decides whether a user has access to a feature. Tierux verifies the purchase with Google Play or Apple, normalizes the result into entitlement state (active/expired/grace), and returns it over a REST API. Your frontend never handles API keys or trust decisions.
Why verify purchases server-side instead of client-side?
Client-side verification exposes your app to tampering and replay attacks. A compromised or modified client can forge 'verified' responses. Server-side verification, where your backend calls Google Play or Apple directly (or through Tierux), eliminates this risk — the client never sees or controls the verification result.
Does Tierux work with both Android and iOS?
Yes. Tierux verifies Google Play purchases via the Android Publisher API and Apple App Store purchases via StoreKit 2 JWS verification server-side, returning the same normalized entitlement shape for both — though Apple App Store support is implemented with limitations and has received less production hardening than the Google Play path (see the platform support matrix).
How does Tierux handle purchase token security?
Raw purchase tokens are never stored on disk. Tierux hashes tokens for deduplication and encrypts a copy (AES-256-GCM) only for refresh operations. Once verified, only the normalized entitlement state is persisted — not the raw token.
Verify server-side, gate anywhere
Free tier — unlimited apps, 1 paywall. No credit card, no revenue share.
Start free