Migration map.

papp_remove

Remove one installed feature, including its irreversible data impact. Read papps_get, identify the exact installed row and review removeBlock and removalImpact. Removal is not deactivation; dependent features are not removed automatically.

{
  "requestId":"papp-remove-example-001",
  "channelCode":"selected-channel-code",
  "expectedRevision":"0000000000000000000000000000000000000000000000000000000000000000",
  "installedPAppId":123,
  "pAppCode":"A00003",
  "confirmation":"DELETE_PAPP",
  "dryRun":true
}

Every identity and the zero revision above is illustrative. Copy the actual ID/code pair from one current installed snapshot. The literal confirmation is a required tool input; it does not replace the user's authorization for the intended removal. OWNER or selected-channel DELEGATEE with MANAGE_P_APP_INSTALL_UNINSTALL is required; hosted account resources cannot call this tool.

Default instances and protected X00001/X00002/Z00007/Z00008 features are blocked. A missing or unresolved catalog policy returns PAPP_REMOVAL_POLICY_UNVERIFIED; an unreleased feature is blocked. The release flag used here is isReleasedInStore, not store visibility. Extension or multi-instance dependents block removal of their parent. None of these conditions is bypassed by supplying the confirmation string.

A fresh dry run validates the snapshot, target and policy and returns PLAN_READY, action/remove target, removalImpact, planned steps and writesPerformed:false. It creates no job and sends no DELETE or refresh. An existing matching task's dry run returns its saved phase instead of a fresh eligibility check. At actual dispatch the workflow rereads state and selected detail, checking ID/code, default/active flags and alias before deleting.

The removal sends DELETE for the selected installed ID, then tracks channel credential refresh and verifies the remaining list equals the old list minus that exact instance. Detail must now be absent; only the selected detail endpoint's HTTP 404 is interpreted as absence. Plan, currency and account type stay unchanged, and final snapshot reads must be stable.

Success is PAPP_REMOVED with the current installed projection, revision, original task ID/type and stored-state verification. Feature data cannot be recovered through this tool, visitors lose the removed functionality, and existing usage charges may still be settled. No payment or refund is performed; reinstalling is not a data restore.

After interruption, use taskType:"papp-lifecycle" and the original ID. PAPP_DETAIL_CONFLICT, PAPP_CONFLICT and PAPP_OUTCOME_UNKNOWN require interpreting the saved stage and current evidence, not issuing another deletion under a new ID. Definitive rejection can return the original task to prepared; uncertain sent deletion is not resent. See recovery for refresh and completion limits.

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