Guía: Lectura desde GET · Condiciones →

Respuesta de GET /discounts

Referencia OpenAPI: GET https://streaming.loyal.guru/discounts.

Casos de uso habituales para integraciones:

• Catálogo de campañas del customer (filtro customer_id o customer_code).
• Campañas disponibles por país o tienda (countries, location_id, location_code).

Comportamiento del listado:

• Solo devuelve campañas activas (active: true) y vigentes según available_from / available_to.
• Orden en data[]: masivas → loyalty → targeted.
• En targeted, excluye vouchers cancelados o sin redenciones disponibles.
• La misma campaña puede aparecer varias veces para un customer si se envió en varias entregas; para una entrega concreta usa GET /discounts/{value} con search_by=campaign_history_id (ver doc API).

Índice

• Query parameters
• Envoltura de la respuesta
• Campos de reglas en la respuesta
• Metadatos por ítem en data[]
• coupon_info (cuando coupon_required: true)
• voucher_info (solo select_customers: targeted)
• Campos para TPV
• Modo cálculo LG (referencia)

---

Query parameters

Parámetro	Uso
campaign_audience	all_customers, loyalty o targeted. Sin valor: devuelve los tres tipos (sujeto a otros filtros).
customer_id / customer_code	Mutuamente excluyentes. Catálogo del customer: masivas + loyalty del país de registro + targeted de ese customer.
countries	Masivas/loyalty por país (ES, ES&countries=FR = ES o FR). Mutuamente excluyente con location_id / location_code.
location_id / location_code	Campañas en esa tienda. Si envías ambos, solo cuenta location_id.
tier_id	Campañas del tier (masivas + loyalty). Mutuamente excluyente con customer_id / customer_code.
category_id	Filtra por categoría de campaña.
selected	Solo con customer + location: true = vouchers targeted seleccionados; false = no seleccionados. Sin valor: todos. Para solo targeted usa también campaign_audience=targeted.
starting_after	Paginación: valor de next_token_starts_after de la página anterior.

Envoltura de la respuesta

Campo	Descripción
data	Array de objetos campaña.
next_token_starts_after	Token para la siguiente página (starting_after). Ausente en la última página.

Campos de reglas en la respuesta

GET /discounts (listado) y GET /discounts/{id} (detalle) usan los mismos nombres en el objeto campaña:

Campo en la respuesta	Tipo habitual	Contenido tras parsear
rule_conditions	string JSON	Objeto con conditions.and[] / conditions.or[]
rule_application	string JSON	Objeto con application.and[] (clave interna application, no conditions)
rule_effects	string JSON	Efecto: type, value, distribution, limits, rule_group, …

Frecuencia de victoria y presupuesto: once, once_limit, budget_value, budget_period, maximum_discount_transaction — ver Límites.

Estructura interna vs nombre de campo: el campo de la API se llama rule_application, pero dentro del JSON parseado la raíz suele ser application.and[]. No confundir el nombre del campo en la respuesta con la clave interna del objeto.

Metadatos por ítem en data[]

Además de las reglas JSON, cada campaña incluye:

Bloque	Campos	Para qué sirve en integración
Identidad	id, name, description	ID de campaña y textos de catálogo / UI.
Categoría	category.id, category.name, category.priority	Grupo de evaluación y apilamiento — Apilamiento.
Vigencia	active, available_from, available_to, recurrence_type, recurrence_days	Si la campaña aplica hoy; recurrence_type: weekly usa recurrence_days (días de la semana).
Evento / moneda	when, currency	Carrito: after_create_activity; divisa de la campaña.
Audiencia	select_customers, customer_registration_countries, tiers[], coupon_required	all_customers (masiva), loyalty (club), targeted (audiencia dirigida). coupon_required: true implica cupón en caja. En listado: tiers[]; en detalle puede venir achievement_definitions.
Cupón	coupon_info (si coupon_required: true)	Configuración del cupón de la campaña. No incluye datos del voucher salvo campaña targeted.
Límites	once, once_limit, budget_value, budget_period, maximum_discount_transaction	Frecuencia de victoria y presupuesto — Límites. once: always, num_day, num_month, num_year, num_total.
Apilamiento	stackability_properties, priority	stackability o highest_discount dentro de la categoría; priority ordena dentro del grupo.
Partner	partner (opcional)	id, name, description, image_url para co-branding en catálogo.
Integración POS	product_ids_rule_conditions, product_ids_rule_application, locations_ids, location_codes (opcionales)	Modo cupón server + taxonomía interna — ver Campos para TPV.

coupon_info (cuando coupon_required: true)

Si la campaña trae **coupon_required: true**, la respuesta incluye siempre el objeto **coupon_info** (configuración del cupón: IDs, nombre, código estático compartido si aplica, etc.). Esto aplica a masivas y loyalty con cupón opcional/obligatorio en configuración, no solo a targeted.

Campo	Descripción
coupon_info.coupon_id	ID del cupón de campaña.
coupon_info.static_code	Código estático del cupón (campañas masivas/loyalty con código compartido).
coupon_info.coupon_name	Nombre del cupón.
coupon_info.external_id	ID externo de referencia.
coupon_info.key	Clave interna de la plataforma.

En masivas/loyalty con cupón estático, suele bastar static_code (o el código acordado) en coupons_desired del POST /carts. **coupon_info no trae voucher_info en esos casos.**

voucher_info (solo select_customers: targeted)

El subobjeto **coupon_info.voucher_info** aparece únicamente cuando select_customers es **targeted**: la campaña está ligada a un voucher (código único por customer) emitido en un envío dirigido. Ahí sí necesitas el detalle del voucher para catálogo, selección en tienda y canje.

Campo	Descripción
coupon_info.voucher_info.voucher_id	ID del voucher del customer.
coupon_info.voucher_info.voucher_code	Código único a presentar en caja / API.
coupon_info.voucher_info.available_redemptions	Redenciones restantes.
coupon_info.voucher_info.max_redemptions	Máximo de redenciones.
coupon_info.voucher_info.selected	Si el voucher está seleccionado para el customer en esa tienda (requiere filtros customer + location en el GET).
coupon_info.voucher_info.status	Estado del voucher (p. ej. pending).
coupon_info.voucher_info.available_from / available_to	Ventana de canje.
coupon_info.voucher_info.print_from / print_to	Ventana de impresión (si aplica).
coupon_info.voucher_info.printable	Si se puede imprimir.
coupon_info.voucher_info.priority	Prioridad del voucher en selección.

coupon_required: true  →  coupon_info (siempre)
select_customers: targeted  →  coupon_info.voucher_info (además)

En compra targeted, envía voucher_code (o el código pertinente) en coupons_desired. Ver API de campañas.

Campos para TPV

Estos cuatro campos pueden aparecer en GET /discounts y GET /discounts/{id} solo cuando la Company es coupon server: configurations.default_apply_discounts es false. Si ese slug falta o es true, Loyal Guru es el motor promocional y esos arrays no se devuelven — parsea rule_*.

configurations.default_apply_discounts (Company)	Rol de Loyal Guru en el carrito	Campos en la respuesta GET
false	Solo cupón server (canje/validación de códigos)	Pueden venir product_ids_rule_* y locations_* / location_codes (ver relleno abajo)
true (habitual)	LG calcula descuentos vía motor (POST /carts, apply_discounts en el payload)	No se devuelven esos arrays; usar rule_conditions, rule_application, rule_effects

No confundir dos niveles: configurations.default_apply_discounts (Company) define si el GET puede incluir arrays para TPV. El apply_discounts del payload de cada POST /carts controla si esa transacción evalúa descuentos en LG — ver Descuentos.

Cuándo se rellenan los arrays (taxonomía interna)

Loyal Guru expande a listas planas solo categorías ligadas a una taxonomía interna (catálogo mantenido en LG). No basta con el modo cupón server: los arrays llevan IDs/códigos útiles solo si la campaña acota por categorías resolubles en plataforma.

Array	Se rellena cuando…
product_ids_rule_conditions	En rule_conditions hay field: product_categories (habitualmente array_field: lines) con values (feature_pk) de taxonomía de producto interna. Ver formato feature_pk.
product_ids_rule_application	En rule_application hay product_categories con taxonomía interna (alcance del efecto).
locations_ids, location_codes	En rule_conditions hay field: location_categories con taxonomía interna de categoría de tienda. Ver Catálogo — tienda.

Si la regla usa solo product_id / location_id directos, o categorías con taxonomía externa sin mapeo en LG, los arrays suelen venir vacíos: el TPV debe parsear rule_* o su catálogo.

Tabla de campos

Campo	Tipo (API)	Interpretación
product_ids_rule_conditions	string[]	Productos de condiciones de victoria, expandidos desde product_categories con taxonomía interna. Vacío si no aplica. Ver Productos en líneas.
product_ids_rule_application	string[]	Productos del alcance del efecto, expandidos desde product_categories con taxonomía interna en rule_application.
locations_ids	integer[]	Tiendas expandidas desde location_categories con taxonomía interna.
location_codes	string[]	Códigos externos de esas tiendas.

Notas para integraciones TPV

• Vacío esperado si no hay categorías internas resolubles o la campaña no acota por producto/tienda en ese bloque.
• No sustituyen a rule_*: conviven en modo cupón server; usar arrays cuando vengan rellenos.
• Si no ves estos campos, configurations.default_apply_discounts es true en la Company (motor LG activo).

Modo cálculo LG (referencia)

Con configurations.default_apply_discounts = true, el flujo habitual es parsear rule_* y enviar el carrito a POST /carts con apply_discounts: true para obtener effects[] calculados. Ver API de campañas.

Parseo: rule_conditions, rule_application y rule_effects suelen venir como string JSON. Deserializa antes de leer cláusulas. En rule_effects, el campo válido para bundle es rule_group (no variantes legacy como rule_grouped en samples antiguos).

---

---

Siguiente: Condiciones (rule_conditions)