All packsApp Store MachinerySolve
app store server notifications v2 idempotency duplicate
Apple retries notifications for 3 days -- your handler has to expect duplicates
Apple retries a Server Notification up to 5 times over 3 days on any non-200 response, so the same notification arriving twice has to be a safe no-op, not a double-processed event.
What goes wrong
App Store Server Notifications V2 aren't guaranteed exactly-once -- Apple explicitly retries up to 5 times over 3 days for anything that doesn't return 200 promptly. A handler that processes every incoming notification as if it's new, with no dedupe check, can apply the same renewal or refund event's side effects more than once if a retry happens (a slow response, a transient error, a deploy mid-delivery-window) -- and the fix isn't just "be faster," it's handling the duplicate correctly when one arrives anyway.
Why agents get it wrong
A notification handler that just processes whatever payload arrives works correctly in every test that sends each notification once, which is how manual testing and most integration tests are naturally structured -- Apple's specific retry behavior (5 attempts, 3-day window, triggered by anything other than a fast 200) is a platform detail that has to be read from Apple's own docs, not something that falls out of implementing "handle this webhook."
What App Store Machinery pre-decides
Decision 7 makes notificationUUID a UNIQUE database column and treats a duplicate insert as a 200 no-op -- correct and safe regardless of how many times Apple retries. The handler is also required to respond within 5 seconds by persisting first and doing any heavier work after, and unknown notification types are stored, logged, and still answered with 200, since Apple adding new types over time must never turn into an unhandled-type 500 that triggers pointless retries.
Source: ARCHITECTURE.md decision 7