As a Shop API consumer, I want to see the Start and End dates of a Promotion Catalog

[ebarbeito]

Describe the proposed solution

Utilizing the latest release (v1.13.0), there's an endpoint in the Shop API (/api/v2/shop) available to retrieve a CatalogPromotion resource. Below is an example usage along with a sample response:

$ curl -X 'GET'   'https://localhost:8000/api/v2/shop/catalog-promotions/magidays24'   -H 'accept: application/ld+json' -s | jq
{
  "@context": "/api/v2/contexts/CatalogPromotion",
  "@id": "/api/v2/shop/catalog-promotions/magidays24",
  "@type": "CatalogPromotion",
  "id": 5,
  "label": "Label Magic Days 2024"
}

The CatalogPromotion resource currently provides information about the "id" and "label". I am wondering if it would be possible to also expose the startDate and endDate fields.

These date details could enhance a product page's functionality, enabling users to understand that the current price is part of a temporary promotion scheduled to end on a specific date, as set by the applied catalog promotion.

Describe alternatives you've considered

The current alternative I am considering is to use the Admin API endpoint (/api/v2/admin/catalog-promotions/{code})

This endpoint returns a resource containing both date fields (startDate and endDate). However, it exposes additional CatalogPromotion fields containing potentially sensitive information such as "priority," "exclusive," "state," "scopes," and "actions", etc. not suitable for a Shop API response.

Additional context

Could the fields "startDate" and "endDate" be considered non-sensitive data suitable for exposure in the GET /api/v2/shop/catalog-promotions/{code} Shop API endpoint?

I understand that implementing this feature request may not currently be a high priority. Would you be open to accepting a pull request from me to add this feature?

Thank you in advance.

[Chrysweel]

Great idea

[GSadee]

Hi @ebarbeito!

Indeed, in some cases these dates may make sense in the shop, but probably not in most cases, which is why I have some doubts about adding this by default in Sylius, as we would like to return as little information as possible, which in the end applications can be easily extended. Especially, as it is easier to add something to serialization than to remove it.

So I would suggest adding these fields for serialisation in your end application, you can use our documentation for this case: https://docs.sylius.com/en/1.13/customization/api/serialization_customization.html#adding-a-field-to-response