Apple Server Notifications Webhooks stopped retrying on HTTP 400

Question

Created Mar ’26

Replies 4

Boosts 2

Participants 3

Hey

We have noticed a change in the retry behavior of Apple Server Notifications webhooks V2 starting around March 12–13, 2026.

Previously, when our webhook endpoint returned an HTTP 400 response, Apple would retry the notification delivery multiple times according to the documented retry policy.

However, beginning around March 12–13, it appears that Apple no longer retries the webhook when a 400 response is returned. The notification is sent only once and no further retry attempts are made.

From our understanding of the documentation, retries should occur when delivery fails, and historically we observed retries even for some 4xx responses.

We would like to confirm:

Has Apple recently changed the retry behavior for Server Notifications?
Are HTTP 4xx responses (specifically 400) now considered terminal failures that will not trigger retries?
Is this change intentional or related to a rollout in the webhook delivery system?

We have called the "Notification History" endpoint for some users who purchased a sub and we are only getting one attempt with the following data in it:

{ attemptDate: 1773469202552, (2026-03-14T06:20:02.552Z) sendAttemptResult: 'UNSUCCESSFUL_HTTP_RESPONSE_CODE', }

This was 2 days ago, based on the docs, the user should have a few attempts at least.

This behavior change affects systems that rely on retries to handle temporary validation issues or transient failures.

Thanks!

Boost

Answer 1

App Store Commerce Engineer OP

Apple

Mar ’26

Hello, can you please confirm if you're still seeing this behavior? As you mentioned, you should be getting at least 5 retries on version 2 at 1, 12, 24, 48, and 72 hours after the previous attempt.

If this issue is still present, please submit a Feedback Assistant with as much detail as possible and share the generated ID here to further investigate.

1

Answer 2

itsjgf OP

Mar ’26

@App Store Commerce Engineer This started working a day or two after I posted the message. Looks like we are now receiving a lot of duplicated notifications (which is better than missing the retries). But it looks like something change on your end that started sending a lot of duplicated notifs, has Apple changed something on their lately?

0

Answer 3

App Store Commerce Engineer OP

Apple

Mar ’26

Great to hear the notifications are arriving now.

Please create a Feedback Assistant to investigate the duplicate notifications.

Include as much detail as possible, such as the notifications payload, timing of the received notifications, or any other relevant information.

Once created, share the Feedback Assistant ID here for further investigation.

0

Answer 4

BigBalli OP

6d

The retry policy is actually documented behavior, though enforcement seems to have gotten stricter around that date. Apple's webhook retry rules:

2xx response: success, no retry (as expected).
4xx response: treated as a permanent failure. Your server is effectively saying "this notification is malformed or not for me", so no retry because retrying won't help.
5xx response: treated as a temporary failure. Retries follow the documented schedule (5 attempts over roughly 3 days).
No response or timeout: also treated as temporary failure, retried.

If you want retries, return 5xx (or just let your server error naturally). Returning 400 tells Apple "I got your notification but I permanently cannot process it, don't bother sending again."

Before that change, 4xx may have been getting retried in some cases, which wasn't the documented behavior. The March 2026 change likely aligned actual behavior with what the docs have always said.

Two things I'd check:

Why is your server returning 400 in the first place? If it's a decode failure on a malformed payload (JWS signature check failing, etc.), that might warrant returning 500 so you get retries and can investigate. If it's intentional validation rejection, 400 is fine but log it so you know what's being discarded.
Use the App Store Server API requestTestNotification plus getTestNotificationStatus endpoints to verify your webhook end-to-end without waiting on real transactions.

0