On this page

In-App Events: draft, localize, upload, inspect

flightline events manages selected In-App Event workflows directly in App Store Connect. It is outside flightline fetch, plan, and apply; events have no L2 state YAML contract. The commands below use the synthetic bundle ID com.example.app and placeholder IDs returned by your own account. Check the commands and flags in your installed build with flightline events --help and the relevant subcommand --help before using this guide. This source workflow has local test coverage; live Apple qualification is pending.

Inspect the app and event

Shell

flightline events list com.example.app --output json
flightline events get com.example.app --event EVENT_ID --output json
flightline events localizations list com.example.app --event EVENT_ID --output json

The bundle ID is resolved to one app. Each event ID is checked against that app; localization and media IDs are checked against the selected parent before use. Read the event's eventState, primaryLocale, and territorySchedules before editing. Use the actual IDs returned by list/get, never a display name as an ID.

Creation requires --confirm and must return a DRAFT event. Updating, localizing, and changing media require an existing DRAFT event and --confirm. Event deletion permits DRAFT, ARCHIVED, or APPROVED; inspect state and identity before that destructive operation. Flightline does not offer a command here to force an event to another lifecycle state.

Create the draft and localization

Shell

flightline events create com.example.app \
  --reference-name 'Example launch event' \
  --badge SPECIAL_EVENT \
  --deep-link 'https://example.com/event' \
  --purchase-requirement 'No purchase required' \
  --primary-locale en-US \
  --priority NORMAL \
  --purpose APPROPRIATE_FOR_ALL_USERS \
  --territory-schedules '[{"territories":["USA"],"publishStart":"2026-12-01T12:00:00Z","eventStart":"2026-12-02T12:00:00Z","eventEnd":"2026-12-03T12:00:00Z"}]' \
  --confirm --output json

Replace these example dates with future RFC 3339 times. The schedule must have publishStart <= eventStart < eventEnd; event duration is 15 minutes to 31 days, and publication can precede the event by at most 14 days. If you customize starts across territories, their spread is limited to 48 hours. Territory codes in one event cannot repeat. A draft can be created with less metadata, but the proposal check later requires all fields shown above and a schedule.

The create response contains the event ID. If creation reports an uncertain outcome, list events and inspect the reference name before retrying: a duplicate name is treated as a conflict, not an automatic reuse.

Shell

flightline events localizations create com.example.app \
  --event EVENT_ID --locale en-US \
  --name 'Example launch' \
  --short-description 'Explore the new experience' \
  --long-description 'Open the app during the event to explore the new experience.' \
  --confirm --output json

flightline events localizations get com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID --output json

--name, --short-description, and --long-description have 30, 50, and 120 character limits. The primary locale must exist among the event localizations before proposal. Each localization needs all three text fields for review. To change draft text, use flightline events localizations update with --event, --localization, changed fields, and --confirm. To change draft event metadata, use flightline events update with --event, changed fields, and --confirm; eventState cannot be patched.

Shell

flightline events update com.example.app \
  --event EVENT_ID --priority HIGH --confirm --output json

flightline events localizations update com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID \
  --short-description 'See what is new' --confirm --output json

Updates merge changed fields with the current record; omitted fields are retained. Re-read the event after a schedule change because the proposed times must still satisfy the future-date bounds at review time.

Upload card and detail media

Each localization needs one processed EVENT_CARD media item and one processed EVENT_DETAILS_PAGE item for proposal. Each slot can hold an image or video. Flightline's selected workflow rejects an ambiguous slot with multiple resources, including mixed image and video. Inspect existing media first:

Shell

flightline events media list com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID --output json

flightline events media upload com.example.app ./event-card.png \
  --event EVENT_ID --localization LOCALIZATION_ID \
  --asset-type EVENT_CARD --confirm --output json

flightline events media upload com.example.app ./event-details.png \
  --event EVENT_ID --localization LOCALIZATION_ID \
  --asset-type EVENT_DETAILS_PAGE --confirm --output json

Images accept .jpg, .jpeg, or .png. For a .mov, .m4v, or .mp4, add --video; video uploads may also set --preview-frame-time-code. Upload reserves, transfers, commits, then waits for processing. The default polling bound is 20 reads, 3 seconds apart; --max-polls and --poll-interval adjust it. A committed upload can still be processing, so retain its returned media ID.

Shell

flightline events media get com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID --media MEDIA_ID --output json

flightline events media wait com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID --media MEDIA_ID --output json

wait checks the selected media without uploading bytes again. A timeout or processing error calls for inspection of that ID. Apple's event media response does not provide a server source checksum; Flightline cannot prove that an occupied slot matches a local file. An occupied completed slot blocks another upload, even when the filename matches. Inspect it and, if replacement is intended, explicitly delete the selected draft media before uploading again:

Shell

flightline events media delete com.example.app \
  --event EVENT_ID --localization LOCALIZATION_ID --media MEDIA_ID --confirm

--resume is only for a matching AWAITING_UPLOAD reservation and its exact local checkpoint, file, parent localization, and media ID. It is not a replacement mechanism. Keep the original file and checkpoint when resuming an interrupted upload; otherwise inspect before retrying.

Check review readiness

Shell

flightline events propose-submission-item com.example.app \
  --event EVENT_ID --output json

This read-only command checks that the event is still DRAFT, the schedule remains valid and future-dated, required metadata and primary localization exist, every localization has complete text, and both media slots are unambiguous and COMPLETE. It returns an appEvent item proposal with the event ID. A proposal does not attach an item, create a review submission, or submit anything to Apple. Recheck readiness immediately before any separate submission assembly action; the event or media may have changed meanwhile.