Sign up

app_store_version_app_version_state_updated

Learn about the APP_STORE_VERSION_APP_VERSION_STATE_UPDATED webhook event from App Store Connect. Fired when a version is approved, rejected, or moves to another review state.

App Store ConnectApp Version
app_store_version_app_version_state_updated

The APP_STORE_VERSION_APP_VERSION_STATE_UPDATED event fires whenever an App Store version changes state during the review and release process. This is one of the most important events for iOS teams because it tells you exactly where your app stands in Apple's review pipeline.


When does it fire?


This event triggers on every state transition for an App Store version, including:


  • Waiting for Review — your build has been submitted and is queued
  • In Review — Apple is actively reviewing your app
  • Approved / Ready for Distribution — your app passed review
  • Rejected — Apple found issues that need to be addressed
  • Developer Rejected — you pulled the submission yourself
  • Pending Developer Release — approved and waiting for you to release

Each transition sends a separate webhook event, so you can track the full lifecycle from submission to release.


Payload highlights


The webhook payload carries the previous state and the new state as oldValue and newValue, plus a reference to the version record — not the version string itself. Yeethook resolves that reference, so the alert can say exactly what changed, such as "MyApp 2.1.0 moved from In Review to Approved."


How Yeethook helps


Without Yeethook, you need to poll the App Store Connect API or manually check the dashboard. With Yeethook, every state change arrives in Slack or Discord within seconds. If you provide a p8 key, Yeethook adds the version string, the App Store state, the release type, and phased release progress to the message.


Common use cases


  • Get instant alerts when your app is approved or rejected
  • Track how long each review takes by comparing timestamps
  • Notify your release manager when a version is ready for distribution
  • Trigger CI/CD pipelines on approval

Example payload

App Store Connect posts this event as plain JSON. The transition itself is just oldValue and newValue; relationships.instance names the version record, so the version string in the message comes from a follow-up API call.

{
  "data": {
    "type": "appStoreVersionAppVersionStateUpdated",
    "id": "d4f0a2c8-1b7e-4c53-9a10-2f6b8e5d4c31",
    "version": 1,
    "attributes": {
      "oldValue": "IN_REVIEW",
      "newValue": "READY_FOR_DISTRIBUTION"
    },
    "relationships": {
      "instance": {
        "data": {
          "type": "appStoreVersions",
          "id": "8f2b1c04-77a9-4c2e-b3d5-9e1a6f0c4b28"
        }
      }
    }
  }
}

What it looks like in Slack

Success

v2.1.0 ready for distribution

Version
2.1.0
State
Ready For Distribution
Release type
After Approval
Phased release
Active (Day 3)

The same event arrives with different values depending on what changed. Yeethook rewrites the headline to match:

  • IN_REVIEW→ v2.1.0 in review
  • REJECTED→ v2.1.0 rejected
  • DEVELOPER_REJECTED→ v2.1.0 developer rejected
  • PENDING_DEVELOPER_RELEASE→ v2.1.0 pending developer release

Enrichment with p8 key

With a p8 key, Yeethook enriches this event with the version string, App Store state, release type, and phased release status from the App Store Connect API.

Questions about app_store_version_app_version_state_updated

Does this event tell me why Apple rejected my app?

No. The webhook carries the old and new state and nothing else — rejection reasons stay in Resolution Center. Yeethook links straight to the version in App Store Connect so you can read the message without hunting for the app first.

How do I tell an Apple rejection apart from one my team triggered?

Apple sets newValue to REJECTED when it rejects a submission and DEVELOPER_REJECTED when someone on your side withdraws it. Yeethook treats the first as critical and the second as a warning, so the two never look alike in your channel.

Is there a separate event for every review state?

Yes. Each transition is its own webhook, so a normal release produces a chain from Waiting For Review through In Review to Ready For Distribution. Comparing timestamps across that chain is the simplest way to measure how long Apple actually took.

Which version does the event refer to?

Only by ID, under relationships.instance. Resolving that ID to a human version string like 2.1.0 needs an App Store Connect API call, which is what Yeethook does with your p8 key before it posts to Slack or Discord.

Learn More

Official Apple documentation:

Get this event in Slack or Discord

Connect Yeethook to receive app_store_version_app_version_state_updated notifications in your team's Slack or Discord channels.

Get Started Free