InAppify

Request examples and skill usage

Copyable requests for first integration, legacy migration, uncertain purchases and placement-specific Web discounts.

After installation, specify versions, platforms and the desired outcome. Do not provide credentials, session tokens, receipts or real customer data. These examples explicitly invoke Codex; select the skill through the equivalent UI in other hosts.

First cross-platform integration

$inappify-sdk
This app uses inappify_sdk 0.2.1 on Android, iOS and Web.
Inspect resolved versions and the existing session owner first.
The Web provider is @inappifylabs/web-sdk 0.2.0.
Implement configure, platform-correct login, the upgrade placement,
Package-based purchase and premium access checks. Report unsupported capabilities.
Preserve existing purchase/cache/recovery behavior; do not create live payments.

Migrate without losing existing attempts

$inappify-sdk
Migrate the old Inappify integration to the 0.2.1 public API.
First locate dependencies, host wrappers and unresolved-attempt journals.
Use logIn, logOut, setAttributes and purchase with original catalog Packages.
Preserve attempt keys and scope across restart, network errors and account changes.
Do not add a competing Android recovery loop or erase cache/inventory.

Diagnose an uncertain purchase

$inappify-sdk
An Android purchase outcome is still unknown after process restart.
Do not edit code yet. Trace saved attempts, purchaseUpdates and getPurchaseAttempt.
A successful null lookup or empty sync result must not mean purchase failure.
Propose how to reconcile only the same attempt under the same identity.

Discount a Web placement

$inappify-sdk
On Flutter Web, validate the discount for the offering selected by upgrade placement.
Forward its ID to getDiscountedPaymentLinksResult and use the returned
priced offering/code in createCheckout. Invalid IDs must not fall back to default.
Do not replace the SDK base catalog. Preserve native Android/iOS discount links.

Expected output

The agent should report resolved versions, per-platform backends, chosen APIs and limitations; use that release's public signatures and run proportionate checks. It must not assume combined sync or cacheOnly policy forwarding exists in the current Flutter Web bridge.

Distinguish compilation/tests from live verified payment. Review financial changes using safety rules and the SDK checklist.