When uploading an iOS IPA via App Store Connect API or altool, App Store Connect validates the IPA against the wrong existing app record, even though the IPA is correctly signed and provisioned. The exact same IPA uploads successfully via Apple Transporter, which correctly routes it to the intended app. This appears to be an App Store Connect upload-resolution issue specific to API-based delivery. Environment Account: App Store Connect (Admin access) Authentication: App Store Connect API Key (Issuer ID + Key ID) Apps in Account: com.dailyaudiobible.dabapp Apple ID: 121xxxx266 com.dailyaudiobible.dabapp2 Apple ID: 645xxxx428 iOS / SDK Details Platform: iOS Build Artifact: Single signed IPA used for all tests Target SDK: iOS 18.5 Xcode: 16.4 .NET iOS SDK: 18.5.9227 Minimum iOS Version: 18.5 Architecture: ios-arm64 Build Type: App Store distribution (Release) This SDK/Xcode combination previously worked for TestFlight uploads of this app. Expected Behavior When uploading an IPA with: CFBundleIdentifier = com.dailyaudiobible.dabapp Provisioning profile for com.dailyaudiobible.dabapp Embedded provisioning profile matching com.dailyaudiobible.dabapp App Store Connect should validate and associate the build with the dabapp app record. Actual Behavior When uploading the IPA using API-based tools, App Store Connect validates the upload against dabapp2 and rejects it with: Validation failed (409): This bundle is invalid. The bundle identifier cannot be changed from the current value, com.dailyaudiobible.dabapp2. No references to dabapp2 exist in the codebase, build configuration, or signing assets. Delivery Methods Tested (Same IPA) App Store Connect API (automation / CI) Upload accepted Validation fails Error references com.dailyaudiobible.dabapp2 altool (Apple CLI, API key authentication) Same behavior as API Same validation error altool logs confirm API key has access to multiple apps but validation resolves to the wrong app Apple Transporter (manual) Automatically detects com.dailyaudiobible.dabapp Upload succeeds Build appears correctly under the dabapp record in App Store Connect This confirms the IPA itself is valid and correctly signed. Verification Performed From the built IPA: Info.plist CFBundleIdentifier = com.dailyaudiobible.dabapp Embedded provisioning profile Application identifier resolves to com.dailyaudiobible.dabapp Provisioning profile used at build time: Explicitly configured for com.dailyaudiobible.dabapp All values are verified by extracting the IPA contents locally. Questions for Apple Engineering Why do API-based uploads (App Store Connect API / altool) resolve this IPA to the wrong existing app record, while Transporter resolves it correctly, and how can that association be corrected or reset? If this is expected behavior when multiple related apps exist under one provider, is this documented, and are there required parameters or constraints for API-based uploads in this scenario? Additional Notes This is reproducible using only Apple-provided tools and APIs. CI/CD tooling itself is not required to reproduce the issue. Manual Transporter uploads are not a viable long-term solution for automated releases. Any guidance or confirmation from App Store Connect engineering or other developers would be appreciated.