@wix/himalaya-cli 0.1545.0 → 0.1547.0

package/guides/himi-json-output.md

@@ -493,3 +493,32 @@ Apple provisioning commands (`draft`, `plan`, `apply`, `status`, `screenshots`)
 legacy `--profile` combined with Catalog registration/route selectors as `invalid_usage`,
 before reading inputs or credentials. `connect` retains its intentional legacy profile plus
 Catalog mapping route and registration check.
+
+## Apple-key onboarding (`himi store apple-keys`)
+
+`setup` and `status` emit JSON with `ok`, `app`, `site`, `bundleId`, `asc`, `iap`,
+`ready`, `purchasesAppId`, and `completed`. `asc` carries `present` and available
+`keyId`/`issuerId`; `iap` carries `present`. A group omitted during setup has
+`present: null`, `state: "not_checked"`. A failed status read has `present: null`,
+`state: "unavailable"`; the other service is still read and reported, and the
+command exits 1 with `apple_keys_failed`. Setup also attempts both selected uploads
+independently and reports the successful writes if either service fails. No private
+key is returned. A successful
+read exits 0 even when `ready` is false. Dry runs add `dryRun: true` and `planned`.
+`completed` names writes confirmed during this invocation (`asc`, `purchases_app`,
+`iap`); it is not a transaction or a guarantee that a timed-out write did not land.
+
+| Code | Meaning |
+|---|---|
+| `invalid_usage` | Invalid identity, incomplete key flags, invalid/unreadable key or a key inside the repository, or missing `--yes`. Exit 2; no key writes. |
+| `owner_session_unavailable` | Himi/Wix owner credentials or target configuration could not be resolved. `error` retains the session diagnostic. |
+| `apple_keys_failed` | A service call, authorization check or read-back failed. Exit 1; earlier writes listed in `completed` remain stored. Read status before retrying. |
+
+The ASC endpoint (`GET`/`POST /v1/admin/store/asc-key`) also returns stable `code`
+values on failures: `unauthorized`, `token_revoked`, `revocation_check_unavailable`,
+`method_not_allowed`, `invalid_input`, `invalid_app_id`, `invalid_site_id`,
+`forbidden_cross_tenant`, `forbidden_site`, `invalid_asc_key`,
+`apple_keys_unconfigured`, `apple_keys_not_saved`, `build_secrets_busy`, or
+`apple_keys_unavailable`. `build_secrets_busy` is HTTP 409: another ASC upload or
+push setup holds the site; retry after it finishes. Responses have `Cache-Control:
+no-store`; both methods require app authority and current Wix site ownership.

package/guides/iap-products.md

@@ -33,6 +33,51 @@ catalogs. Subscriptions are refused before anything reaches Apple.
 
 These key and profile prerequisites apply to direct Apple mode. There is **no ambient fallback**: direct mode requires `--profile`, and exported `ASC_*` variables never select the account. Managed mode below uses no local `.p8`.
 
+## Set up the owner's Apple keys
+
+Use `himi store apple-keys setup` to upload either key independently of push setup
+and local signing profiles. The **App Store Connect API key** is stored in Branded
+BuildSecrets for Catalog. The separate **In-App Purchase key** is stored on the
+purchases app using the purchases service's `SetAppleCredentials` operation.
+Create the latter under App Store Connect → Users and Access → Integrations →
+In-App Purchase; an ASC API key cannot replace it.
+
+Sign into the owner's Wix account (`wix login`) and Himi (`himi login --browser
+--target wix`), and use an app slug that account already owns. Keep both `.p8`
+files outside the repository, including after resolving symlinks.
+
+```sh
+himi store apple-keys setup --app <slug> --site <metaSiteId> --bundle-id <bundle> \
+  --asc-key-file /private/keys/asc.p8 --asc-key-id <id> --asc-issuer-id <issuer> \
+  --iap-key /private/keys/iap.p8 --iap-key-id <id> --iap-issuer-id <issuer> --yes
+himi store apple-keys status --app <slug> --site <metaSiteId> --bundle-id <bundle> --json
+```
+
+Each key's three flags must be supplied together; omit the other group to upload
+only one key. Setup contacts only the services for the supplied key groups; an
+unselected group reports `present: null`, `state: "not_checked"`. Each group supplies
+its own issuer ID. `setup --dry-run` validates
+local inputs and reads stored status without registering an app or uploading keys.
+Without `--dry-run`, setup requires `--yes`; supplied keys replace the corresponding
+stored key. An IAP upload registers the bundle's purchases app if it does not exist,
+and reuses an existing registration. It does not connect the payment provider or
+create product mappings: run `himi store iap connect` afterward.
+
+Status returns presence for each key, ASC identifiers when available, and the
+`purchasesAppId` to use with Catalog commands. `ready` means both keys are stored;
+it does not prove Apple permissions, product readiness or payment-provider setup.
+Private keys are never returned or saved locally. Both commands emit JSON; a
+successful status read exits 0 even when a key is missing. Status reads both services
+independently; if one fails, it exits 1 but retains the other result and marks the
+failed group `present: null`, `state: "unavailable"`. Setup reports completed
+writes if a later step fails. When both keys are selected, a failure in one service
+does not prevent the other upload; read status before retrying. The ASC upload preserves
+existing signing, Google Play and live Ping credentials, and refuses when it cannot
+read the credentials needed for preservation. Concurrent ASC uploads and push setup
+exclude each other through the same site lease; a busy site returns HTTP 409.
+It never provisions certificates,
+profiles, APNs or Firebase. Containers Builder is not used.
+
 ## Managed provisioning through Catalog
 
 Provisioning commands use managed mode when `--profile` is absent; `--managed`
@@ -139,10 +184,10 @@ with Catalog's current revision, preserving the SKU, item identity, and metadata
 Managed `connect` never opens an Apple key on the Mac. It reuses an In-App Purchase key
 already stored by purchases. If there is none, it reports `apple_key_missing`; an App Store
 Connect API key is a different credential and cannot replace it. The purchases contract
-supports encrypted key writes but not reading a key back, and Branded does not currently
-provide a dedicated In-App Purchase key bridge. Provisioning that missing server key remains
-a backend prerequisite. Explicit legacy `--profile` plus `--iap-key` remains available for
-owner-driven onboarding. Supplying local key flags in managed mode is refused.
+supports encrypted key writes but not reading a key back. Upload the missing key with
+`himi store apple-keys setup` and its IAP key flags, then rerun managed connect.
+Explicit legacy `--profile` plus `--iap-key` also remains available. Supplying local
+key flags directly to managed connect is refused.
 
 For a managed draft, pass the Catalog registration and route:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wix/himalaya-cli",
-  "version": "0.1545.0",
+  "version": "0.1547.0",
   "type": "module",
   "description": "himi — the Himalaya authoring CLI. Build a Tier-5 content package on your own machine, push it to the production serve as a draft, preview it on web + Himi Player, and read worker logs back — the remote dev loop. Wraps @himalaya/serve-cli for transport.",
   "keywords": [
@@ -71,5 +71,5 @@
       "artifactId": "himalaya-cli"
     }
   },
-  "falconPackageHash": "537ce9b28dda30a82fe688b5070033e1e9cf0e697d1ed735fe7aea7d"
+  "falconPackageHash": "3c6e4dce693028c9e0531a80ea57ada77181dd515f0e95690052a6c6"
 }