Catalog Versioning API Sample Use Cases and Flows

Create a Product while supporting both V1 and V3 catalogs

• Call GetCatalogVersion to retrieve the catalog version.
• if the catalogVersion is CATALOG_V1:
  • Call CreateProduct on the V1 catalog
• if the catalogVersion is CATALOG_V3:
  • call CreateProduct on the V3 catalog

Handling domain events and webhooks

On every change in catalog V1 and in catalog V3 we send relevant events. To ensure smooth client migration from V1 to V3 until client started listening to V3 domain events, on every change in V3 catalog we also send duplicating V1 webhook. But once client started migration to V3 catalog and listening to V3 event in addition to V1 event it would cause double event handling issue. To avoid this, we added a new field originatedFromVersion to all V1 webhooks. The client should check this field and ignore the V1 webhook if the originatedFromVersion is CATALOG_V3.

Let's consider example where you need to listen to Product Created event and save new product on your DB.

1. When you receive V3 Product Created domain event, you have entire product entity in createdEvent.entityAsJson. Just save it in your DB or do whatever logic you need.
2. When you receive V1 Product Created event, it might be originated from V3 catalog which you already handled in step 1, so you need to check originatedFromVersion field.
   • If originatedFromVersion is CATALOG_V3 you can ignore this event.
   • Otherwise, you might want to do follow up call to Get Product V1 API if event you receive doesn't have all data you need. Now you can save product in your DB or do whatever logic you need.