Org Web Adapter

Editing hungryroot/jira/be_7320_bring_v2_get_get_promo_data_endpoint_to_parity_with_v1.org

:PROPERTIES:
:ID:       29f45805-9394-4bce-ba3a-fab85275997a
:END:
#+title: BE-7320 Bring V2 GET get_promo_data endpoint to parity with V1
#+filetags: :project:

- source :: https://hungryroot.atlassian.net/browse/BE-7320
- tags   :: [[id:3a477c02-e26d-40f7-a719-0aa1cd169dd8][Hungryroot API Project]]
- epic   :: [[id:86327fb4-0f66-4bc6-9068-c414cea77042][EP-411 Eng Parking Lot]]
- sprint :: [[id:9821b605-4d59-432e-b15d-95999d25cc39][HR BE Sprint 106]]  [[id:c4663d81-db80-4eb0-a898-9f2c4aea9023][HR BE Sprint 107]]
- status :: [[id:4d41d978-e56f-45c1-88d1-e2c76510972e][Status - Complete]]
- points :: 1

* Tasks
** DONE Open a PR using auto-pr tag :work:hungryroot:autopr:be7320:ep411:sprint106:apiv1:v1migration:
:PROPERTIES:
:ID:       1ccdf264-a368-425a-0e85-8fc7d4287668
:END:
** DONE Fix tests that did not work on firs tpass :work:hungryroot:autopr:be7320:ep411:sprint106:apiv1:v1migration:
:PROPERTIES:
:ID:       cd801584-7462-fe48-b61e-ec04d07c07e3
:END:
<2026-03-24 Tue>
** DONE Review and clean up auto-pr for get_promo_data V1 transition :work:hungryroot:autopr:be7320:ep411:sprint106:apiv1:v1migration:
:PROPERTIES:
:ID:       555ee712-51d2-dc84-f00d-e15c9d92740c
:END:
<2026-03-31 Tue>
** TODO Try again to rebuild this with knowledge of what the clients actually need :work:hungryroot:be7320:ep411:sprint107:apiv1:v1migration:
:PROPERTIES:
:ID:       6cc854be-30c0-784f-7b46-4fef09a3ab21
:END:

- Note taken on [2026-04-01 Wed 11:16]

I really don't have my head around this one. I think the next step is see how
  the clients are using this so I know what needs to carried over. [[id:811ce160-bfe5-429f-b2cb-545cb2acadef][Esther Plants]]
  called out my auto-pr for just blindly porting V1 over. But also, the clients
  are all still using V1, so ... maybe that was appropriate to a degree?
  
* Description

The V1 GET /api/get_promo_data/ endpoint has session-aware and page-context-driven
promo resolution logic that has no equivalent in the V2 GET /api/v2/promo/<code>/
endpoint. The V2 endpoint needs to be extended (or a new V2 endpoint created) to
cover the V1 use cases.

** Gaps in V2

- Session-based promo resolution: V1 cascades through promo_code query param,
  promo query param, and promo session key. V2 requires the code explicitly in
  the URL path.
  
- Page-context factory selection: V1 uses a page query param to select among
  PreSignUpPromoFactory, SignUpPromoFactory, HomePagePromoFactory, or
  BasePromoFactory. V2 only supports use_case for factory selection via
  UseCaseEnum.
  
- CYO promo layering: V1 has special logic on the /signup/ page to layer a CYO
  promo on top of the primary promo. V2 has no CYO awareness.
  
- Cart fallback: On the /limited-time/ page, V1 falls back to the authenticated
  user's current cart promo if no promo is in the query string or session. V2
  has no equivalent.
  
- Response shape: V1 returns the raw factory.get_effect() dict (with keys like
  discount, cyo, full_effect). V2 wraps the effect in a serialized model
  response with additional fields (code, code_effect, type, value,
  is_reactivation, is_cancel_winback).
  
- Silent fallback vs 404: V1 silently returns a default/empty effect for invalid
  promos. V2 returns a 404.

**  Acceptance Criteria

- V2 supports all promo resolution paths currently handled by V1
- V2 supports page-context-aware factory selection
- V2 supports CYO promo layering for signup flow
- V2 response contract is documented and covers all V1 response fields
- Existing V2 consumers are not broken by the changes

**   Relevant Files

- V1 view: app/views/api.py (lines 891-968)
- V2 view: app/rest/promo_code.py
- V1 URL: app/urls/apiv1.py
- V2 URL: app/rest/urls.py
- Promo factories: app/services/promo_factory.py