Import Launch Plan
POST/api/launch-plan/import
Imports a cutover bundle exported from another account (normally staging → production). Send multipart/form-data.
launch_plan:writeGrant 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
- 201
- 401
- 403
- 409
- 422
- 429
Created
Response Headers
Unauthenticated — the bearer token is missing, revoked, expired, or malformed. Never retry automatically; fix the credential. See the Errors guide.
Forbidden — the token lacks a required scope, the endpoint is not available to API tokens, or the user behind the token lacks the permission. A human must adjust the token scopes or user permissions; do not retry.
Conflict
Response Headers
Unprocessable Content
Response Headers
Rate limited — platform limit is 1,000 requests/min; individual tokens may carry lower limits. Honor the Retry-After header before retrying. See the Rate Limits guide.