Skip to main content

Import Launch Plan

POST 

/api/launch-plan/import

Imports a cutover bundle exported from another account (normally staging → production). Send multipart/form-data.

Required scope: launch_plan:write

Grant this scope to your token under Settings → Developer → Personal Access Tokens.

Allowed only when the account has no plan, an archived plan, or a plan nobody has worked on — that plan is replaced (an archived plan is kept as history; an untouched one is deleted). Any sign-off, hand tick (done or in progress), custom step, due-date override, comment, owner / size / not-needed / profile edit or member change (adding, changing or removing a member) counts as work: 409 plan_has_progress with details (steps_completed_by_people, custom_steps, due_overrides, comments, step_edits, member_edits, plan_id); archive the existing plan first.

A bundle whose step dependencies form a loop (counting the beta_signoff checkpoint as waiting on every validate-phase step, custom ones included) is refused before anything is changed: 422 bundle_dependency_loop with loop (the step keys, first repeated at the end) and the loop's titles in message. The replace and the re-check run in one transaction, so any failure leaves the existing plan as it was.

A bundle that is unsigned, was changed after export, was signed by a server with a different signing key, or uses another schema_version is refused with 422 bundle_unverified (reason: signature_missing | signature_mismatch | schema_version, requires_staff_confirmation: true). A SKU.io staff member can import it anyway with confirm_unverified=1.

On import: members are matched by email to users with access to this account (others are reported in warnings and left off; their steps are unassigned); sign-offs and comments keep their original timestamps and are marked imported; unknown step keys become custom steps flagged from_newer_version (exporting such a plan carries them in custom_steps under their own key, and a later import accepts them again with their sign-offs, comments and dependencies); only the bundle's members and the owners of steps that were open at export become members — a step done at export keeps its owner for the record without making them a member; a hand tick on a production-only step exported from a non-production account is dropped; the plan records imported_from, which completes the cutover step on a production account; every data-driven step is re-checked against this account's data.

Response: {data: <launch plan>, warnings: [{code, message, email?, step_key?}], signature_verified}. Warning codes: member_unmatched, owner_unmatched, step_from_newer_version, signature_unverified, step_cap_reached.

Authentication: Requires Bearer token with the launch_plan:write scope. The user needs the launch_plan.manage permission.

Request​

Responses​

Created

Response Headers
    Content-Type