Inconsistent metadata Support Across Core Modules (Promotion, Price List, Stock Location, Tax Regions, API Keys, Campaigns)

[rotema-konimbo]

Bug report

Describe the bug

Some core modules in Medusa v2 do not expose a metadata field on their primary data models. This makes it difficult to store additional, custom key–value data consistently across the platform.

Examples of modules/models where metadata is missing:

• Promotion module
  • Promotion does not expose metadata in its data model. The official reference only lists structural fields (id, code, is_automatic, is_tax_inclusive, type, status) and relations, with no metadata property. [Promotion model]
• Tax Regions
  • The PostTaxRegions Admin API shows the tax region’s input schema and includes metadata on the tax region object and on the default_tax_rate, but the underlying data model reference is missing / unclear, so there is no direct confirmation that a metadata column exists on the stored tax region entity. [PostTaxRegions]

Other modules where metadata support is expected for extensibility but appears missing or undocumented (based on current documentation):

• Price list
• Stock location
• API keys
• Campaigns (promotion module)

For comparison, other entities such as product categories, collections, inventory items, images, etc. do expose metadata explicitly in their Admin API schemas. [Admin product/category metadata]

It would be ideal if all primary entities supported metadata consistently, or if the docs clearly stated that the recommended way to extend those entities is only via module links and separate models.

System information

Medusa version (including plugins): v2 (framework / modules) – as per current documentation
Node.js version: N/A (documentation-level issue)
Database: N/A
Operating system: N/A
Browser (if relevant): N/A

Steps to reproduce the behavior

1. Open the Promotion Module model reference.
   • The Promotion model does not list metadata as a property. [Promotion model]
2. Open other Admin API references and observe that many entities do have metadata fields (e.g. collections, categories, inventory items, images). [Admin API responses]
3. Look for similar metadata fields or data model references for:
   • Price lists
   • Stock locations
   • Tax regions
   • API keys
   • Campaigns
4. Notice that the presence or absence of metadata is inconsistent or undocumented for these modules/models.

Expected behavior

• All core entities (including promotions, price lists, stock locations, tax regions, API keys, campaigns) should:
  • Either expose a metadata JSON field for custom key–value data, or
  • Have clear documentation that they intentionally do not support metadata, and that the only recommended extension mechanism is via separate models and module links.
• Documentation should explicitly list metadata (or its absence) in the data model references for these modules so that developers can rely on a consistent extension pattern.

Screenshots

N/A – this is based on documentation and model references.

Code snippets

N/A – this is primarily a schema / documentation issue.

Additional context

• The official guide for extending the Promotion Module instructs developers to create a separate Custom model and link it using a module link to Promotion in order to store extra data. [Extend promotion data model]
• While module links are powerful, having a native metadata field on key entities would simplify many customization scenarios and bring these modules in line with others that already support metadata.
• Even if the design choice is to not add metadata to these entities, it would be very helpful to document that explicitly and clarify the recommended extension strategy in each affected module’s reference.

[luluhoc]

Agree, the metadata should be available in all models. I was using metadata in shipping methods in v1, and now I'm in the process of migration, and metadata is missing

[EvilConsultant]

Same - I use Promotion to drive a Loyalty Points program, but metadata is not in the UI. Although, I admit, a custom admin nav that writes to metadata behind the scenes was easy to build and probably a better UX.