---
title: Handling notification responses from APNs
framework: usernotifications
role: article
role_heading: Article
path: usernotifications/handling-notification-responses-from-apns
---

# Handling notification responses from APNs

Respond to the status codes that the APNs servers return.

## Overview

Overview Apple Push Notification service (APNs) provides a response to each POST request your server transmits. Each response contains a header with fields indicating the status of the response. If the request was successful, the body of the response is empty. If an error occurred, the body contains a JSON dictionary with additional information about the error. If you find your device is having trouble receiving notifications, refer to Troubleshooting push notifications. Interpret header responses The table below describes the meaning of the keys in the header response.  |   |   |   |  The table below lists the possible values in the :status header of the response.  |   |   |   |   |   |   |   |   |   |   |  Understand error codes The table below lists the keys found in the JSON dictionary for unsuccessful requests. The JSON data might also be included in a GOAWAY frame when a connection terminates.  |   |   |  The table below lists the possible error codes included in the reason key of a response’s JSON payload.  |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |  |  After 15 minutes, you can retry JSON payloads that receive response status codes that begin with 5XX. While retrying, you may employ a back-off technique. Most notifications with the status code 4XX can be retried after you fix the error noted in the reason field. Don’t retry notification responses with the error code BadDeviceToken, DeviceTokenNotForTopic, Forbidden, ExpiredToken, Unregistered, or PayloadTooLarge. You can retry with a delay, if you get the error code TooManyRequests. tip: An error code beginning with 4XX slows down your ability to send notifications. Refer to the Settings frame from APNs and adjust your throughput accordingly. APNs disconnects a provider connection with too many error conditions. APNs disconnects sooner with certain error conditions, such as BadDeviceToken. Note that status code 410 isn’t considered an error condition. The code listing below shows a sample response for a successful push request. HEADERS   + END_STREAM   + END_HEADERS   apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b   :status = 200 The code listing below shows a sample response when an error occurs. HEADERS   - END_STREAM   + END_HEADERS   :status = 400   content-type = application/json   apns-id: <a_UUID> DATA   + END_STREAM   { "reason" : "BadDeviceToken" } During testing, if you find that your test devices aren’t receiving push notifications sent by your provider server, see, Troubleshooting push notifications to troubleshoot.

## See Also

### Device push notifications

- [Sending notification requests to APNs](usernotifications/sending-notification-requests-to-apns.md)
- [Viewing the status of push notifications using Metrics and APNs](usernotifications/viewing-the-status-of-push-notifications-using-metrics-and-apns.md)