Create a destination by calling the Notifications API `createDestination` endpoint with a `resourceSpecification` pointing to your SQS queue ARN (for SQS) or your EventBridge partner event source configuration; capture the returned `destinationId`.
Grant Amazon's SP-API service principal permission to publish to your SQS queue by attaching the appropriate policy to the SQS queue — the SP-API documentation specifies the required principal and action.
Subscribe to a notification type (e.g., `ORDER_CHANGE`, `REPORT_PROCESSING_FINISHED`) by calling `createSubscription` with the `notificationType` and `destinationId`.
Poll your SQS queue or configure your EventBridge rule/target to consume and process notification messages; each message payload conforms to the notification type's schema.
Parse the notification payload's `notificationVersion` and `payload` fields — the inner payload structure differs by `notificationType`, so implement a dispatcher pattern.
Delete or acknowledge each SQS message after successful processing to prevent redelivery; implement idempotent handlers because duplicate deliveries can occur.
Known gotchas
Destinations and subscriptions are per-selling-partner and per-application — creating duplicate subscriptions for the same notification type results in duplicate messages to your queue.
SQS queue policies must explicitly allow the SP-API service principal to `SendMessage`; omitting this causes silent delivery failures with no error from the subscription creation API.
Notification schemas can be versioned and updated by Amazon; always check `notificationVersion` and handle unknown fields gracefully to avoid breaking on schema additions.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp