Skip to main content
Event subscribers allow you to react to events in your Medusa application, such as order creation, product updates, or custom events from your workflows. They enable asynchronous, decoupled event-driven architectures.

What is an Event Subscriber?

An event subscriber:
  • Listens to one or more events from the event bus
  • Executes asynchronously when events are triggered
  • Has access to the dependency injection container
  • Can trigger workflows, send notifications, or perform side effects
  • Exports a configuration specifying which events to listen to

Creating a Basic Subscriber

1

Create the Subscriber File

Create a file in src/subscribers/ with a default export function and configuration:
src/subscribers/brand-created.ts
2

Access Services and Modules

Resolve dependencies from the container:
3

Execute Workflows

Trigger workflows in response to events:

Subscriber Configuration

Single Event

Multiple Events

With Context

Add metadata to identify the subscriber:

Real-World Examples

Payment Webhook Handler

This example shows processing payment webhooks and triggering workflows:
src/subscribers/payment-webhook.ts

Send Notifications

Send notifications based on configurable events:
src/subscribers/order-notifications.ts

Sync Data to External System

src/subscribers/brand-sync.ts

Event Data Types

Type your event data for type safety:

Built-in Events

Medusa emits events for core entities:
  • order.created, order.updated, order.canceled
  • product.created, product.updated, product.deleted
  • customer.created, customer.updated
  • payment.created, payment.captured
  • fulfillment.created, fulfillment.shipped
And many more. See the Events concept for more information about the event system.

Custom Events from Workflows

Emit custom events using workflow hooks:
src/workflows/brand/create-brand.ts
Subscribe to the hook:
src/subscribers/brand-created.ts

Error Handling

Handle errors gracefully to prevent subscriber failures from affecting the main flow:

Best Practices

  • Keep subscribers focused on a single responsibility
  • Use workflows for complex business logic instead of putting it in subscribers
  • Handle errors gracefully - don’t let subscriber failures break the main flow
  • Use typed event data for type safety
  • Add context with subscriberId for easier debugging
  • Use the logger for debugging and error tracking
  • Consider idempotency when handling events (events may be delivered multiple times)
  • Don’t perform long-running operations synchronously - use workflows or background jobs

Next Steps

Create Workflows

Build workflows triggered by subscribers

Scheduled Jobs

Create time-based background tasks