Push Notifications - Tracking a Shipment

Using push notifications helps shippers to automatically receive shipment status updates for a package as they become available, without the need to make any external calls. Using the push mechanism additionally helps to minimize throttling risks.

3rd Party Integrators and direct integrated shippers who are using Shipping V2 API to create shipments for Amazon Shipping carrier can use this feature to get tracking notifications and updates of their shipments.

Yes. HTTPS is a mandatory requirement for webhook URLs. Amazon will only accept and configure HTTPS-enabled webhook URLs to ensure secure communication and protect sensitive tracking data during transmission.

Push Notifications are configured via our tech team. You will receive a response within 5 business days.

Push Notifications can only be enabled for orders shipped with Amazon Shipping. As the subscription process is manual as of today, please contact your Amazon Account Manager for further assistance to enable Push Notification Tracking feature.

No — as of Q2 2026, Push Notifications now include both location and proofOfDelivery objects, achieving full parity with the Tracking API (pull). The only structural difference remains: the pull API response includes the full event history for every call, while push notifications are sent per-event and contain only that single event.

There is no difference in schema or information — both use the same fields, enums, and data structures (location, proofOfDelivery, eventCode, status, etc.).

The difference is in scope:

• Tracking API (pull): Returns the full accumulated event history for a shipment — every scan event throughout the entire journey in a single response.
• Push Notifications: Delivers a single event at the point it occurs. Each notification contains only that one scan event's details.

In short: same data, same schema — but the Tracking API gives you the complete timeline, while Push Notifications give you each event in real time as it happens.

Event Codes and tracking status list is available in the API reference:

• Event Codes
• Status Codes
• Detail Codes

The eventTime field can include the local timezone offset in ISO 8601 format — however, this is currently enabled on a per-account basis via additional configuration. The format remains ISO 8601 regardless:

• With offset: 2026-06-15T19:52:00+05:30
• Without offset (default): 2026-06-15T14:22:00Z

If you require local timezone offset in your push notification events, please contact your Amazon Account Manager to request enablement.

Yes. The location object is included in every push notification event. However, when the carrier does not provide node/facility data for an event, all fields within location (city, stateOrRegion, postalCode, countryCode) will be null.

Yes. For example, countryCode may be available while city and postalCode are null. Do not assume that one populated field guarantees the others.

Events associated with a physical facility or delivery point (e.g., ArrivedAtCarrierFacility, OutForDelivery, Delivered) are most likely to have location data. Early lifecycle events (e.g., ReadyForReceive) often have null location fields.

Yes. Location data is available across US, UK, FR, IT, ES, and IN. Population depends on carrier-provided data, not marketplace.

Only on Delivered events where proof of delivery was captured. For non-delivery events, or deliveries where no proof was collected (e.g., safe place delivery without a photo), the field is null.

All fields are nullable — availability depends on the delivery workflow for each package.

No. POD availability depends on the delivery workflow. Not all deliveries require a photo or signature. If no proof was captured, proofOfDelivery will be null.

Download or cache images immediately upon receiving the notification. Expired URLs cannot be regenerated.

Yes. POD data is also available via the Tracking API. Push Notifications provide the same data in real-time without polling.

The name of the person who received the package, as captured by the delivery driver. This field is null if the recipient's name was not recorded (e.g., unattended delivery).

No. GPS coordinates are captured when the delivery driver's device provides location data at the point of delivery. The field may be null if GPS was unavailable.

Yes. In the event of a system outage, shippers can request previous notifications through two methods:

1. Using the existing pull API to retrieve previous tracking information
2. Requesting retriggering of push notifications for a specific timeline

When retriggering push notifications, they will be sent based on the timeline criteria only — not for specific event codes or tracking IDs.

Common causes:

1. API Key mismatch — Verify the key-value pair matches what was configured during onboarding.
2. OAuth token expired — Ensure your OAuth endpoint issues tokens with sufficient TTL.
3. Username/Password incorrect — Verify the Basic Auth credentials match your endpoint's configuration.

Network latency and retry sequencing may cause events to arrive out of chronological order. Always use the eventTime field to sort events — not the order of delivery. Maintain a local event store keyed by trackingId and sort by eventTime.

1. Verify your endpoint is publicly accessible (not behind a VPN or firewall)
2. Ensure your endpoint returns HTTP 2xx for POST requests
3. Check that your authentication credentials are valid and accessible
4. Contact your Amazon Account Manager to verify your subscription is active and enabled

This is expected behavior. The carrier does not provide node/facility data for every event. Specifically:

• ReadyForReceive — typically null (label created, no physical scan yet)
• Delivered — may be null if the carrier doesn't map the delivery address to a node

For Delivered events with null location, use proofOfDelivery.deliveryLocationCoordinates (GPS) instead.

No. Both are additive fields. Existing integrations that do not parse these fields will continue to function without changes. No updates to webhook subscription or endpoint configuration are required.

Yes. The Push Notification payload will continue to evolve toward full Tracking API parity. Future additions will be backward-compatible (additive only). Design your parser to ignore unknown fields rather than failing on them.

Schema changes are announced via: Developer Docs Feed

• Please subscribe to our RSS feeds Developer Docs RSS Feed
• Email communication to your registered technical contact
• Pre-launch announcements with advance notice for significant changes