Read and configure discount codes and coupon templates

The selected channel requires OWNER or MANAGE_DISCOUNTS, separate from promotion-campaign permission.

1. Call discounts_get with family discount-code or coupon-template. Default lists return one page of up to 100 rows; follow nextPage explicitly. Discount list activation and coupon usage status are family-specific filters.
2. Copy dcid/cotid into targetId for profile, usage, segments or promotions. A numeric row ID, public code, title or automatic segment ID is not the selected parent identity. Related tabs default to 15 rows and do not accept the list's search/filter options or limit 300.
3. Read stored status and relationships without calculating customer entitlement or assuming that an active code is usable by a particular member.
4. Use discount_handoff for the intended human action. Creation observes plan/capacity; issue/withdraw leads to the coupon tab where the person opens the modal and selects current eligible rows. Report action_required, not a completed financial action.

Read one coupon template page:

{"channelCode":"selected-channel-code","family":"coupon-template","view":{"kind":"list","page":1,"limit":100}}

For an observed template, obtain the edit destination:

{"channelCode":"selected-channel-code","family":"coupon-template","action":{"kind":"edit","targetId":"observed-template"}}

Settings saves have observation-only recovery under taskType discount-settings. Creation now also has the source-supported workflow below; issuance/withdrawal still use the human handoff. Repeated page/parent checks provide a bounded stable observation, not an atomic inventory, reservation or proof of visitor eligibility. Campaigns, coupon notification settings, segment editing and membership-product coupons have separate contracts or unfinished scope.

The current reader returns its selected view and keeps page, size and supported filters in the single console link. Open that returned address to reach the same selection. If DISCOUNT_PAGE_OUT_OF_RANGE is returned, request page1 again; no replacement page was read automatically. Financial handoffs remain human actions and have no completed-write claim.

Edit an existing offer

1. Read the selected profile through discounts_get. Use dcid/cotid as targetId and retain configurationRevision, rather than a list row, public code or coupon serial.
2. Choose one action in discount_settings_apply: profile for either family, or activation for a single discount code. Profile edits accept administrative/display names and absolute expiry; coupon templates also accept benefit text and a nonempty description. Omitted fields are preserved. There is no coupon activation or batch variant.
3. Use dryRun:true to inspect the composed sourceWrite and changesRequired. A fresh preview creates no job. Replace every example identity/revision with the current observed values; no raw endpoint, segment or private DTO is accepted.
4. Submit the same intended input with dryRun:false. A no-op saves a done task without a business write. A save sends one composed request and checks the exact target, preserved fields and two fresh reads. Treat success as current only when historical is false and verification.confirmed is true.
5. For uncertainty, keep the original requestId/input and use the returned discount-settings task. Status reads saved progress; resume observes only. A prepared task needs identical apply; sent requests never repeat. Read the profile separately after historical completion.

Names and coupon texts have UTF-16 limits and are not trimmed. Requested expiry needs an explicit timezone and whole-minute instant; changed expiry must be future. Empty descriptions cannot be cleared. A code profile needs its first observed connected segment, and coupon usage-condition selection is preserved. Missing or invalid stored form values can block an edit even if a reader succeeded.

The writer returns the selected profile address, while the optional edit handoff opens the original edit route. Neither address submits a wizard. A fresh reverse edit is a new operation, with no automatic rollback or promise to restore null expiry, empty description, past expiry, timestamps or visitor effects.

New offer creation can use the workflow below or the existing human handoff; coupon issuance/withdrawal retain that handoff. Settlement, billing, payment and financial execution remain human-console actions.

Create one offer from the original wizard contract

Use OWNER or MANAGE_DISCOUNTS on the selected channel, then choose discount-code or coupon-template. Creation needs a known Essential-or-higher plan; Essential permits one record per family. The getter uses complete unfiltered inventory rather than a filtered page and reserves no capacity.

1. Prepare an optional usage-condition segment separately with the existing segment tools. Select its returned distinctId; creation only observes and preserves its conditions under the discount-screen permission.
2. Supply view:create and the complete draft. Names preserve whitespace, expiry needs an explicit future whole-minute instant, and discount-code preparation performs the source duplicate-check POST. Coupon templates use the reachable RANDOM flow without a keyword or serial-mode input.
3. Copy creationRevision into action:create with the identical family/draft and a stable requestId. Omit targetId. Preview dryRun:true before an authorized creation. The create URL opens the original route without prefilling a step or modal.
4. Keep the discount-create task, original input and authoritative returned identity. A full receipt and two stable readbacks must verify the new offer plus preserved inventory/plan/segment. A confirmed result opens only that new profile.
5. If a sent result is uncertain, exact retry/resume only reads; never create again under another requestId or adopt a matching code/name. No saved receipt means identity remains unknown. Prepared resume does not dispatch. Historical completion needs a fresh profile read before a later edit.

Creation always activates the new offer, but creates no campaign, issued coupon, redemption or payment. The original flow exposes no deletion or automatic cleanup: dedicated test data needs a documented retention/cleanup outcome. Translation backlog and D-PLAN-1 remain separate.