githubEdit

The Status Report

After sending a notification, you will receive a StatusReport object.

This status report has the following properties:

  • The status code

  • The notification URL (refers to the push service provider)

  • The links for push notification management

Depending on the status code, you will be able to know if it is a success or not. In case of success, you can directly access the management link (location header parameter) or the links entity fields in case of asynchronous call. In case of failure, the response code indicates the main reason for rejection (invalid authorization token, expired endpoint...)

Basic Usage

<?php
use WebPush\Subscription;
use WebPush\Notification;
use WebPush\WebPushService;

/** @var Notification $notification */
/** @var Subscription $subscription */
/** @var WebPushService $webPushService */
$statusReport = $webPushService->send($notification, $subscription);

if(!$statusReport->isSuccess()) {
    //Something went wrong
} else {
    $statusReport->getLocation();
    $statusReport->getLinks();
}

Helper Methods

The StatusReport provides several helper methods to simplify error handling:

Simplified Error Handling

Understanding Status Codes

The status code follows HTTP standards and indicates the result of the push notification delivery.

Success Codes (2xx)

201 Created

The notification was successfully sent and queued for delivery.

Client Error Codes (4xx)

400 Bad Request

The request was malformed or invalid.

Common causes:

  • Invalid payload encryption

  • Malformed subscription

  • Missing required headers

401 Unauthorized

The VAPID authentication failed.

Common causes:

  • Invalid VAPID signature

  • Expired VAPID token

  • Mismatched VAPID public key

404 Not Found

The subscription endpoint no longer exists.

Action required: Remove the subscription from your database.

410 Gone

The subscription has expired and will never be valid again.

Action required: Remove the subscription from your database.

circle-info

One of the failure reasons could be the expiration of the subscription (too old or cancelled by the end-user). This can be checked with the method isSubscriptionExpired(). In this case, you should simply delete the subscription as it is not possible to send notifications anymore.

413 Payload Too Large

The notification payload exceeds the size limit.

Maximum sizes:

  • Chrome/Edge: 4096 bytes

  • Firefox: 4096 bytes

  • Safari: 4096 bytes

429 Too Many Requests

You've exceeded the rate limit for the push service.

Action required: Implement rate limiting and exponential backoff.

Server Error Codes (5xx)

500 Internal Server Error

The push service encountered an error.

Action: Retry with exponential backoff.

502 Bad Gateway

The push service is temporarily unavailable.

Action: Retry with exponential backoff.

503 Service Unavailable

The push service is temporarily overloaded.

Action: Retry later.

Handling Errors

Comprehensive Error Handling

Retry Strategy with Exponential Backoff

Batch Processing with Error Handling

Using sendToMultiple()

The recommended way to send notifications to multiple subscriptions is using the sendToMultiple() method:

circle-info

The sendToMultiple() method does not throw exceptions for individual failures. Instead, it attempts to send to all subscriptions and returns a StatusReport for each one, allowing you to inspect successes and failures.

Filtering Reports

Use the static helper methods to filter and analyze batch results:

Complete Batch Processing Example

Monitoring and Metrics

Track your notification delivery metrics:

Debugging Failed Deliveries

When debugging failures, collect all relevant information:

Best Practices

  1. Always Check Success: Don't assume notifications are delivered

  2. Handle Expired Subscriptions: Clean up your database immediately

  3. Implement Retry Logic: Use exponential backoff for server errors

  4. Log Everything: Track success rates and error patterns

  5. Monitor Metrics: Keep track of delivery rates by push service

  6. Respect Rate Limits: Implement throttling to avoid 429 errors

  7. Validate Early: Check subscription format before sending

  8. Test Thoroughly: Test with real subscriptions from different browsers

Common Issues and Solutions

High Failure Rate

  • Check VAPID keys are correctly configured

  • Verify payload encryption is working

  • Ensure subscriptions are fresh and valid

Subscriptions Expiring Quickly

  • User might be clearing browser data frequently

  • Check if you're using the correct public key

  • Verify the subscription format is correct

Random Failures

  • Implement retry logic with exponential backoff

  • Monitor push service status pages

  • Check for network connectivity issues

Next Steps

Last updated

Was this helpful?