ticket_pricing_apply — change one event's default tier pricing

Apply the exact E00003 operation prepared by ticket_pricing_get: change an existing tier price, add one price link to an existing global tier label, or remove selected price links. These are options of the existing method. Shared source connects tierPrice, tierLink and tierUnlink; the metadata operation adds a distinct full-form name/management-label update. These examples require a compatible connected endpoint; source integration does not update the running service. It does not enable policy creation, global-label editing, discounts, sales terms, refund configuration or refund execution.

Use the Ticket pricing guide for the selected-channel permission and transport requirements.

Inputs

Objects are strict. There are no caller-supplied currency, raw API body, origin, credentials, consumer or installation overrides. Business IDs use 1–160 ASCII letters, digits, underscores or hyphens. Null is not omission. If preparation or context changes before a new unsent operation, read and prepare again; never change the saved input of an uncertain task.

Price rules

payment:{"kind":"free"} sends amount "0". Paid pricing requires {"kind":"paid","amount":"..."} with a strictly positive decimal string: up to ten integer digits and at most two fractional digits, with no sign, exponent, grouping or extra leading zeros.

The source retains exact-channel minimum exceptions. These are minimum rules, not permission to target those channels; use the observed code without deriving it from a numeric ID.

Currency is observed from the current channel. Do not reuse shop-product, article or membership pricing limits. Paid zero returns TICKET_PRICE_INVALID; select free explicitly.

Plan examples

The following examples are dry runs with illustrative targets and a placeholder revision. Replace them with the exact authorized observations and preparation revision. The first example assumes KRW. To execute a new intended change after inspecting its plan, repeat the same fields with dryRun:false.

Change one existing price without changing its tier assignment:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003",
  "eventId": "event-example",
  "policyId": "policy-example",
  "operation": {
    "kind": "tierPrice",
    "eventPolicyTierPriceId": "price-example",
    "payment": {"kind": "paid", "amount": "20000"}
  },
  "requestId": "ticket-price-example-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "dryRun": true
}

Link an existing global label at a free price:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003",
  "eventId": "event-example",
  "policyId": "policy-example",
  "operation": {
    "kind": "tierLink",
    "tierLabelId": "tier-label-example",
    "payment": {"kind": "free"}
  },
  "requestId": "ticket-link-example-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "dryRun": true
}

Unlink one selected price:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003",
  "eventId": "event-example",
  "policyId": "policy-example",
  "operation": {
    "kind": "tierUnlink",
    "eventPolicyTierPriceIds": ["price-example"],
    "confirmation": "UNLINK_TIER_PRICES"
  },
  "requestId": "ticket-unlink-example-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "dryRun": true
}

Effects and preservation

The three tier operations above use the selected event/default-policy tier-prices/dispatch POST on BOOK_AND_TICKET_V3. tierPrice constructs PATCH with exactly one target price ID and its existing tier label; tierLink constructs CREATE with the existing label, amount and currency; tierUnlink constructs DELETE with only the selected price IDs. Callers never provide these transport bodies. The ticket adapter requires its HTTP 200/data response and preserves the full receipt; shop-specific success/action envelopes are not required.

An existing-price edit preserves all other prices, tier identities and metadata, and all returned event/policy/refund fields. An equal numeric amount is a no-op with no dispatch. Linking requires fewer than 500 total price rows and no row already using the selected label, even a deleted row. Unlinking requires 1–100 distinct active price IDs and can remove all active price links. It does not delete global tier labels.

Link completion requires exactly one valid created-price receipt with new numeric and business identities, the selected label, matching consumer/currency/amount and active status. Optional returned event/policy parents must match. The exact business ID must be saved durably as the receipt before recovery can identify the created row. The result exposes it as createdTierPriceId. A matching label, title, count or list difference cannot substitute for that receipt.

Fresh readback must contain exactly the requested new link with all previous prices and the complete bounded global-label inventory preserved. Unlink readback accepts either absence of each selected price or a DELETED row with a valid deletion timestamp and otherwise unchanged business fields. Unselected prices and the global labels remain unchanged. Partial removals, collateral changes and inventory drift remain pending; the tool never sends a second request for the remaining IDs.

Two stable observations are required. Comparison ignores generated insertedAt/updatedAt values and normalizes price representations. Preservation covers returned data, including supplied event-policy projections; it does not prove omitted projections, separately loaded translations/discounts, schedules, issued tickets or buyer rights. There is no atomic snapshot, backend compare-and-swap, causal attribution or automatic restoration.

Results and uncertain recovery

The journal uses prepared, sent and done, with task type commerce-ticket-pricing. writesPerformed describes the task: false for no-op/prepared, true after acknowledgement, and null for an unacknowledged sent effect. It is not a count of writes by the current status/resume call. A fresh dry-run console link proves the destination, not a save.

Use task_status to inspect saved progress and task_resume to observe sent work. Shared-host resume never dispatches a business write. Prepared work needs the identical original apply after current checks. Once sent, neither identical apply nor resume sends it again. A saved creation receipt allows exact-ID observation; a lost receipt stays pending with lastCode:COMMERCE_CREATE_UNKNOWN, not a top-level success or a guessed identity.

Completed apply replay, status and completed resume are historical with current verification false and no current verified console link. Read the current policy separately. REQUEST_ID_CONFLICT means the supplied fields differ from the saved input; retain that input. COMMERCE_CONFLICT before dispatch requires resolving changed state. Context/credential/installation changes cannot be bypassed by adopting another binding. There is no automatic relink, rollback or original-ID restoration.

<a id="policy-metadata-candidate"></a>

Policy metadata

This closes the earlier candidate integration dependency without adding a tool/task type.

Use the metadata getter to inspect management-label options and prepare the complete intended settings. Apply requires the same channel/event/default policy, exact metadata settings, preparation revision and stable requestId. Empty-settings inspection or a tier-operation revision cannot authorize different metadata. This uses existing current permission and context checks; it does not accept another account, installation, currency, raw request or URL.

Only optional title, presentationalTitle and labelIds are editable. Omitted names and omitted membership are preserved. Explicit labelIds:[] removes this policy's management-label links without deleting global labels. Both final names must satisfy the source's 3–50-code-unit, nonblank, no-CR/LF constraints; leading/trailing whitespace is preserved. The final membership has at most ten unique existing IDs. Label order, translations, global-label changes and price/tier assignments are not metadata inputs.

Plan the exact names/labels operation from the getter:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003",
  "eventId": "event-example",
  "policyId": "policy-example",
  "operation": {
    "kind": "metadata",
    "settings": {
      "title": "Standard policy",
      "presentationalTitle": "Standard admission",
      "labelIds": ["management-label-example"]
    }
  },
  "requestId": "ticket-metadata-example-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "dryRun": true
}

Independently, plan explicit link removal after preparing that exact operation:

{
  "channelCode": "L2NoYW5uZWxzLzk4",
  "pAppCode": "E00003",
  "eventId": "event-example",
  "policyId": "policy-example",
  "operation": {"kind": "metadata", "settings": {"labelIds": []}},
  "requestId": "ticket-metadata-clear-001",
  "expectedRevision": "0000000000000000000000000000000000000000000000000000000000000000",
  "dryRun": true
}

Replace all illustrative targets and the all-zero revision with current authorized observations and the matching preparation. An intended authorized save uses identical fields with dryRun:false. A new dry run creates no journal; an empty/equal valid metadata operation is a no-op with no POST.

Unlike tier-price dispatch, metadata sends one POST to /seller/api/v3/events/{eventId}/event-policies/dispatch, with action PATCH and one target policy ID, both final names and the complete final labelIds array. The adapter reconstructs this full form from observed values plus the selected edits. No bulk targets, translation fields, partial raw form, global-label writes or arbitrary routes are exposed.

Completion requires two stable readbacks matching both requested changes and preservation of all prices/tier assignments, other policies, the returned management-label catalog and all other returned event/policy/refund fields. Generated insertedAt/updatedAt timestamps are ignored and amount representations are normalized for comparison. Partial names, mismatched linked projections, catalog drift or collateral price/refund changes remain pending. This is neither atomic nor proof of causality, and it does not verify omitted projections or separately loaded fields.

Metadata uses the same prepared/sent/done commerce-ticket-pricing journal and observation-only shared task recovery. Prepared work requires identical original apply; sent work never repeats the POST. Unlike tierLink, metadata edits an existing policy and requires no created-ID receipt. Matching exact-policy observations may resolve a lost acknowledgement while preserving that uncertainty's history. Do not change requestId, infer success from a title or automatically reverse an unresolved save. Completed replay remains historical with current verification false and no current link; use a fresh metadata getter for current values.

Fresh metadata reads, plans, no-ops and confirmed completions resolve /channels/{channelCode}/p-apps/E00003/events/{eventId}/base-pricing/home under screen channel.ticket-pricing. Tier pricing keeps base-pricing/detail. Pending/error/historical results have no current verified destination. A plan's home link does not prove that a name or label changed.

Restoration is a separate authorized operation using fresh current metadata, a newly prepared exact reverse change and independent readback. There is no automatic rollback or proof of global-label/display-order restoration.