Event-driven architecture in Selling Partner API

Use the Notifications API to to build an event-driven architecture.

by Federico R., Solutions Architect, Selling Partner Developer Services and Hetti S., Engagement Manager, Selling Partner Developer Services | August 2, 2022

This blog post describes what event-driven architectures are, the benefits of implementing them, how the Notifications API enables this design model, and the use cases that can be built around it.

The event-driven architecture pattern is an asynchronous architecture design model. This architecture uses events to connect decoupled, independent components of a system. These components are typically microservices that execute specific tasks. Instead of a monolithic application containing all the logic, an event-driven architecture utilizes small components that generate and react to events. These events represent state changes or other types of updates.

The key elements of event-driven architecture are producers and consumers. Normally, an application consists of multiple producers and consumers. A producer generates an event that is processed by one or more consumers in order to execute different tasks. Together, these tasks accomplish a business use case.

Building an event-driven architecture benefits the performance, cost, reliability, scalability, and development lifecycle of an application. Examples of these benefits include:

  • Event-driven applications perform better by reacting to events in real-time, as opposed to schemas where data is pulled on a scheduled basis, which introduces delays.

  • Reacting to events reduces the amount of unnecessary work, like polling a service for updates, which helps cut costs by saving resources and usage.

  • The event-driven architecture call pattern alleviates the load on third-party services, removing the rate limit bottleneck and reducing throttling errors.

  • Decoupled components can scale and fail independently, enabling them to adapt to demand based on individual needs and reduce the blast radius of failures.

  • The development lifecycle shortens, because the architecture is simpler and therefore easier to adapt to new use cases.

Notifications and event-driven architecture in Selling Partner API

Selling Partner API (SP-API) provides the Notifications API, which enables users to build an event-driven architecture. With the Notifications API, you can subscribe to different event types and receive notifications about relevant changes to your Amazon businesses.

The use cases covered by the various notification types range from listing status changes, order updates, and fee promotion activations, to report processing completion, and product definition changes:

Use CaseNotification Type
Listing management and submissionLISTINGS_ITEM_STATUS_CHANGE
Product pricingANY_OFFER_CHANGED
Fee promotionsFEE_PROMOTION
Multi-channel fulfillmentFULFILLMENT_ORDER_STATUS
Merchant fulfillmentMFN_ORDER_STATUS_CHANGE
Selling partner account managementACCOUNT_STATUS_CHANGED

SP-API offers two workflows for receiving notifications. One of them uses Amazon Simple Queue Service (Amazon SQS) and the other one uses Amazon EventBridge as routers for the events. Depending on the notification type you want to subscribe to you will need to implement one of these workflows. The following paragraphs discuss these workflows in detail.

Amazon Simple Queue Service (Amazon SQS) is a fully managed message queuing service that enables the receipt of messages from different sources and their corresponding processing. The use of Amazon SQS provides a scalable, highly available, and secure solution for receiving and processing events that are relevant to the customer’s business. Amazon SQS offers multiple alternatives for processing incoming messages, such as integration with AWS Lambda functions or using the Amazon SQS API, to provide the flexibility your application needs.

A typical architecture for the Amazon SQS notifications workflow in SP-API consists of a message queue and a consumer for those events. The message queue is hosted in the developer’s Amazon Web Services (AWS) account and receives notifications for events the selling partner is subscribed to. Message processing happens asynchronously and is based on the business use cases the application supports.


Amazon SQS workflow reference architecture

The steps for configuring this workflow, as explained in the Tutorial: Set up notifications (Amazon Simple Queue Service workflow), consist of:

  1. Creating an Amazon SQS queue in your AWS account.
  2. Granting SP-API permissions to write to the queue.
  3. Creating an Amazon SQS destination in SP-API.
  4. Subscribing a selling partner to a notification type.

To simplify building this workflow, Amazon provides a Quick Start that creates a working architecture in your AWS account with just a few clicks, and focuses on the report processing use case. Follow the steps in the Selling Partner Reports API Reports Notifications on the AWS Quick Start Deployment Guide to create the required infrastructure, expose API endpoints for notification management, and extend it to any other use case supported by Notifications API.

Amazon EventBridge is a serverless event bus that enables the reception of events from a variety of AWS services and client applications, as well as their corresponding distribution to different targets for processing. EventBridge is a managed, fault-tolerant service that scales based on incoming traffic. You can use EventBridge to define custom rules to filter and transform events before sending them to selected targets, simplifying the integration between software components. EventBridge supports over 40 Software-as-a-Service event sources for ingesting data and multiple destinations, including AWS Lambda, API Gateway, and custom HTTP endpoints.

A typical architecture for the EventBridge notifications workflow in SP-API consists of an event bus hosted in the developer’s AWS account that receives notifications for events the selling partner is subscribed to, one or more custom rules, and their corresponding targets. Message processing happens asynchronously and is based on the business use cases the application supports.


EventBridge workflow reference architecture

The steps for configuring this workflow, as explained in the Tutorial: Set up notifications (Amazon EventBridge workflow), consist of:

  1. Creating an EventBridge destination in SP-API.
  2. Associating the event source with an event bus.
  3. Creating a rule and associating it with the event bus.
  4. Subscribing a selling partner to a notification type.

Developer experience

MerchantSpring, a successful adaptor of the Notifications API, started integrating their application with Amazon programmatically in December of 2018. Their first-hand experience as a multi-channel agency prompted them to begin developing an in-house application with the goal of making it easier to manage and view store data.

They first integrated with the Amazon Marketplace Web Service (Amazon MWS) ListOrders API, to help keep track of and report on sales volumes while managing an Amazon store. Today their solution expands into a data analytics platform, aimed at allowing users to easily view information and derive insights across various aspects of their marketplace performance including orders, products, inventory levels, profitability, and advertising spend. This allows Sellers to trade more effectively and profitably.

MerchantSpring’s primary use case for Notifications API is to receive ANY_OFFER_CHANGED events, which they use to keep track of real-time featured offer performance for their users. This allows their Sellers to view their past featured offer performance, and monitor the current featured offer status of their listings.

“Standing up Amazon SQS infrastructure solely for subscribing to Amazon notifications was quite a bit of work, but fortunately, we have plenty of experience with Terraform and AWS within the team” says Jerome Loh, software developer for MerchantSpring. “Once everything was set up, working with Amazon SQS using the AWS SDK was pretty straightforward”.

Recent changes to the Notifications API also allowed MerchantSpring to make improvements to their solution; in particular, the addition of the AggregationTimePeriod element to the ANY_OFFER_CHANGED notification type helped them reduce the volume of incoming notifications, while the ability to delete subscriptions as a grantless operation enabled them to clean up inactive users.


This blog explained what event-driven architectures are and the benefits of implementing them for your product or application, such as improving performance, decoupling components, and reducing the development lifecycle. It described how the Notifications API enables this design model, and the use cases that can be built around it. Finally, the blog presented the two alternatives for creating event-driven architectures that consume SP-API events.

For more information, refer to:


Have feedback on this post?

If you have questions or feedback on this post, we'd like to hear from you! Please vote and leave a comment using the tools at the bottom of this page.

Subscribe to updates via RSS feed.