Migration map.

papp_install

Install one selected feature on an existing channel when current prerequisites and all relevant zero-cost conditions are confirmed. Read papps_get first and select the returned feature code and pricing-model identity.

{
  "requestId":"papp-install-example-001",
  "channelCode":"selected-channel-code",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "pAppCode":"A00003",
  "ppmid":"pricing-model-from-get",
  "dryRun":true
}

Replace all illustrative identities and the zero revision from one current get result. The feature is not guaranteed to be available or free in another channel. Unknown fields are rejected. Use OWNER or a selected-channel DELEGATEE with MANAGE_P_APP_INSTALL_UNINSTALL; the hosted resource must admit the exact channel.

A fresh call compares the whole snapshot revision, checks store visibility/release, existing installation, dependencies, plan, account type and selected pricing. It does not install missing parents automatically. Restricted account-allowlist features, an unknown required business-account type, plan restrictions and unconfirmed fees require the corresponding human action. Already installed features are not installed again or repriced by this tool.

Zero cost means explicit zero-valued installation, monthly and usage prices for the actual channel currency. Missing prices, currency mismatch, nonzero values or an unsupported amount representation are not inferred free. The pricing model must belong to the feature and match the current plan class; its FREE name/class alone proves nothing. Blocked or paid installation returns an error or action_required with no install request. See costs and prerequisites.

A fresh successful dry run returns PLAN_READY, action/install target, pricing ID, planned steps and writesPerformed:false, without a new task or install/refresh. An existing matching task's dry run returns its saved phase/task ID and performs no fresh catalog/revision/eligibility comparison. A plan is not installation evidence.

With dryRun:false, the workflow saves the original task, rechecks the pre-dispatch snapshot and sends one necessary install POST. It tracks channel credential refresh before installed-list/detail verification. Completion requires exactly one new installed row for the requested code, preservation of all previously installed rows, the requested active current pricing model, no scheduled next pricing, unchanged plan/currency/account type, and stable final snapshot reads.

Success uses PAPP_INSTALLED and includes installed rows, revision, task ID/type and verification.method:installed_list_detail_and_credential_refresh. It does not prove visitor functionality or operate content inside the installed feature. The recovery contract distinguishes a definitively rejected prepared request from an uncertain sent one; an unsent credential refresh can still run during resume. Completed results are historical.

Use status and resume with taskType:"papp-lifecycle" and the same task ID. Never create a replacement request merely to bypass an unknown install outcome. Changing an installed feature's pricing uses the human handoff.

Saved record identity

Stored task IDs must match the requested lookup key. An intact task copied under a different key, or a present JSON null/false/zero/empty-string record, returns TASK_STATE_UNVERIFIED before context/business calls. Preserve both the original record and the requested file for inspection; do not replace or delete them to bypass uncertainty. Only an actually absent file means no task.

An existing matching dry-run returns its saved plan with historical:true, replayed:true, and verification.currentStateVerified:false. It does not recheck current install/removal eligibility. Follow nextStep to papps_get for the exact original channel and feature before planning further changes. The journal is unchanged and no installation, removal or credential refresh is sent by this plan.

Saved record consistency

Before using an existing task, the workflow checks its original input fingerprint, before-state revision, allowed progress/refresh/checkpoint combinations and any stored completion. A completed result must match the original channel, feature, task, pricing/removed target and preserved installed rows. Inconsistency returns TASK_STATE_UNVERIFIED before context/business calls and leaves the record intact. Preserve it for inspection rather than repairing fields or starting replacement work. This validates consistency, not cryptographic authenticity or current server state. Historical completion still requires a fresh get for current values.

Detail pricing evidence

An installed-list row may omit pricing or contain null while the detail response confirms valid active pricing. Those list values remain unchanged. New tasks keep a separate internal detail-verification receipt and require it for completed installation recovery. The receipt binds the observed installed ID, feature code, requested active price and absence of a scheduled next price. Legacy histories without that receipt retain their existing verified-method metadata and target/ preservation checks; no receipt or list pricing is invented. Historical replay is not a current detail read. Invalid detail identity/pricing cannot confirm a new installation, and uncertain effects are never resent.

Inputs