Org Web Adapter

hungryroot/jira/be_7320_bring_v2_get_get_promo_data_endpoint_to_parity_with_v1.org

ID
29f45805-9394-4bce-ba3a-fab85275997a

BE-7320 Bring V2 GET get_promo_data endpoint to parity with V1

- source :: https://hungryroot.atlassian.net/browse/BE-7320

- tags :: Hungryroot API Project

- epic :: EP-411 Eng Parking Lot

- sprint :: HR BE Sprint 106 HR BE Sprint 107

- status :: Status - Complete

- points :: 1

Tasks

DONE Open a PR using auto-pr tag

workhungryrootautoprbe7320ep411sprint106apiv1v1migration
ID
1ccdf264-a368-425a-0e85-8fc7d4287668

DONE Fix tests that did not work on firs tpass

workhungryrootautoprbe7320ep411sprint106apiv1v1migration
ID
cd801584-7462-fe48-b61e-ec04d07c07e3

DONE Review and clean up auto-pr for get_promo_data V1 transition

workhungryrootautoprbe7320ep411sprint106apiv1v1migration
ID
555ee712-51d2-dc84-f00d-e15c9d92740c

TODO Try again to rebuild this with knowledge of what the clients actually need

workhungryrootbe7320ep411sprint107apiv1v1migration
ID
6cc854be-30c0-784f-7b46-4fef09a3ab21

- Note taken on

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. 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