I received a notification stating that we need to register a server-to-server notification endpoint to handle the following three events:
- Changes in email forwarding preferences.
- Account deletions in your app.
- Permanent Apple Account deletions.
However, even though we have registered the API endpoint under our Identifier configuration, it appears that we are not receiving any API calls when these events trigger.
I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending these notifications yet, or is there something I might be missing? I’m stuck and don’t know how to resolve this. I would really appreciate any help or insights you could share. Thank you.
Hi @mslim8803,
You wrote:
I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending these notifications yet, or is there something I might be missing?
Configure Your Server for Notifications
To receive Sign in with Apple server-to-server notifications, your server must support Transport Layer Security (TLS) 1.2 or later. The endpoint URL you provide must be an absolute URI, including the scheme, host, and path (e.g., https://example.com/path/to/endpoint). This URL is configured in App Store Connect or the Apple Developer portal. To learn more, see Processing changes for Sign in with Apple accounts.
Ensure your server is configured to respond with an HTTP 200 status code to indicate successful receipt of a notification. If a non-200 response is returned or a timeout occurs, Apple's servers will retry sending the notification.
Troubleshooting Notification Delivery
If you are not receiving Sign in with Apple server-to-server notifications, consider the following troubleshooting steps:
- Verify Endpoint Configuration: Double-check that the server-to-server notification endpoint URL configured in your Apple Developer account (under Certificates, Identifiers & Profiles, then your App ID) exactly matches your server's endpoint. Only one URL can be provided per Sign in with Apple app grouping and key.
- Check ATS Compliance: Ensure your server's connection adheres to App Transport Security (ATS) requirements. This includes using a certificate issued by a trusted certificate authority, TLS 1.2 or higher, and a certificate signed and hashed using SHA-256 or greater.
- Review Server Logs: Examine your server logs for any incoming requests from Apple's IP addresses (subnet 17.0.0.0/8) and for any errors in processing the notification payload. This can help identify issues with network connectivity, SSL/TLS handshakes, or payload parsing.
- Validate JWS Payload: After receiving a notification, your server must decode the JWS payload and use the algorithm specified in the header's
algparameter to validate the signature. Failure to properly validate the signature might lead to your server discarding valid notifications. - Check for OAuth Errors: If other Sign in with Apple functions are working, but specific notifications are not, review TN3107: Resolving Sign in with Apple response errors for common OAuth error codes and their solutions, which might indirectly affect notification delivery or processing.
Test Server-to-Server Notifications
While there isn't a specific 'test notification' endpoint for Sign in with Apple server-to-server notifications similar to App Store Server Notifications, you can simulate user actions to trigger these notifications in a testing environment.
To test consent-revoked notifications, have a test user revoke authorization for your app. This can be done manually by the user through their device settings. For example, on an iOS device, a user can go to Settings > Apple ID > Password & Security > Apps Using Your Apple ID, select your app, and choose 'Stop Using Apple ID'. You can also programmatically achieve this by invoking the Token revocation endpoint. Your server should then receive a consent-revoked notification.
For comprehensive testing, ensure your server's logic correctly handles the decoding, validation, and processing of all expected notification types, including email-enabled, email-disabled, consent-revoked, and account-deleted events.
If none of the above works, please submit a bug report with Feedback Assistant, including your Team ID, Client ID, and affected user ID for expected the notification event, as well as a timestamp of the triggering event, if possible.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
