# POST /api/transactions/{id}/operations

> Deprecated

Legacy single-id route retained for backward compatibility.

Looks up the transaction's `MerchantId` first, then forwards to the merchant-scoped path. New callers should target the merchant-scoped route directly, which reads the transaction without that lookup. The `Deprecation` response header lets client telemetry pick up traffic on this route during the migration.



The caller needs the permission for the requested operation type:
`Transactions.Operations.Void` for Void and Reversal, `Transactions.Operations.Refund`
for Refund, `Transactions.Operations.Capture` for Capture,
`Transactions.Operations.Adjustment` for OfflineAdjustment and IncrementalAuthorization,
`Transactions.Payments.Create` for Repeat and Retry, and
`Transactions.PartialApproval.Acknowledge` for AcceptPartialApproval and SplitTender. A
Refund, Repeat or Retry creates a new transaction, which also requires
`Transactions.Payments.Create`. A caller without the permission receives 403 before the
transaction is read, so the response does not reveal whether the transaction exists.

**Operation ID:** `transactionOperationsExecuteOperationLegacy`

## Authorization

No permission required.

Requires API key scope: `transactions:refund`

## Parameters

| Name | In | Required | Type | Description |
| --- | --- | --- | --- | --- |
| id | path | yes | string(uuid) | The transaction to operate on. |
| suppressNulls | query | no | boolean | If true, omit properties with null values. |

## Request Body

The operation details (type, optional amount, optional reason).

**Content type:** `application/json`

Schema: [`ExecuteTransactionOperationInput`](https://devportal.demo.winkpg.io/docs/api/models/ExecuteTransactionOperationInput.md)

Properties:
- `operationType` ([TransactionOperationType](https://devportal.demo.winkpg.io/docs/api/models/TransactionOperationType.md)): The type of operation to execute (e.g., Refund, Reversal, Void, Capture).
  Values:
  - `Capture`: Finalizes a previously-approved authorization by sending an online capture / clearing message to the processor. Moves the transaction from "funds held" to "marked for the next batch close": settlement still happens later when the merchant's batch cuts. Valid only against approved, uncaptured TransactionType.Authorization transactions; the action matrix removes Capture once the transaction is settled (Refund is the post-settlement undo). Partial captures (less than the authorized amount) are supported and release the unused portion of the issuer hold per network rules.
  - `Refund`: Returns funds to the cardholder by spawning a new standalone TransactionType.Return transaction linked back to the parent via OriginalTransaction.TransactionId. The new transaction flows through the normal auth + settlement pipeline rather than mutating the parent in place. Used once the parent has settled (post-batch-close), at which point Reversal and Void are no longer applicable. Refund capacity is reserved against the parent's PendingRefundAmount with optimistic concurrency so concurrent partial refunds from different callers cannot collectively exceed the parent's available balance.
  - `Void`: Offline ledger-only cancel: marks the transaction for exclusion from the next batch close without sending any processor message. Used pre-settlement. Acts as the fallback when the configured processor does not support online Reversal (or the reversal window has expired). The action evaluator's mutual-exclusion step drops Void from the candidate set when Reversal is also eligible: Reversal is a strict superset of Void on the same stage. Terminal once approved.
  - `Reversal`: Online undo: sends a processor message (0420-equivalent on card networks) that releases the issuer hold on a captured-but-not-cleared transaction and pulls the transaction from the next clearing. Distinct from Void in that an actual rails-level message is exchanged with the processor; the processor can decline. Eligible post-auth and pre-settlement against Authorization, Sale, RepeatSale, and captured Authorization stages. Per-processor support is advertised via ProcessorCapabilities.SupportsReversal and gated by ReversalWindowSeconds; the gateway falls back to Void when the processor opts out. Partial reversals (strictly less than the remaining authorized balance) are supported when the processor also advertises SupportsPartialReversal; a partial reversal leaves the transaction non-terminal until cumulative reversed equals the authorized ceiling. Once settlement has cleared, Reversal is no longer valid and Refund is the only available undo.
  - `Repeat`: Re-runs a previously-approved transaction with the same payment data by spawning a new transaction linked back to the parent via OriginalTransaction.TransactionId. Authorizations repeat as Authorization (re-hold funds); Sale and RepeatSale both repeat as RepeatSale. Used for recurring billing, card-on-file scenarios, and operator-initiated re-charges. The caller may supply a different amount than the original; the new transaction flows through the normal auth + settlement pipeline. Available against approved transactions in any settlement state: once an authorization has settled, Repeat is the only re-charge path (Capture is no longer eligible).
  - `Retry`: Re-attempts a previously declined or failed transaction with the same TransactionType and the same amount as the original: changing either would violate retry semantics. Spawns a new transaction linked back to the parent via OriginalTransaction.TransactionId. Available only when the parent ended in a non-approved result code (decline, processing error, gateway failure). Distinct from Repeat, which preserves type-mapping rules (Sale → RepeatSale) and allows a caller-specified amount; Retry is intended to recover from a transient failure on the original attempt without altering its commercial intent.
  - `OfflineAdjustment`: An offline adjustment to a previously-authorized transaction's settlement record: tip (gratuity), tax, level-3 data, PO number, or AVS fields. Modifies the settlement amount/data before batch close without contacting the processor network. Tip and other amount-bearing fields are constrained to industry types that allow post-auth adjustments (restaurant, retail, e-commerce). Online amount changes (incremental authorization) belong to IncrementalAuthorization.
  - `IncrementalAuthorization`: An online incremental (or "estimated → final") authorization on top of a previously authorized (but uncaptured) transaction. The processor sends a fresh auth message to the brand network; on approve, the transaction's Total_Auth_Amt is bumped and a new auth response (with its own customer-facing receipt) replaces the prior one. Distinct from OfflineAdjustment in that an actual rails round-trip is performed and the issuer can decline. Valid only against TransactionType.Authorization transactions that have not yet been captured. Per-processor support is advertised via ProcessorCapabilities.SupportedAdjustmentTypes; the gateway rejects the operation up front when the configured processor lacks the capability.
  - `AcceptPartialApproval`: Acknowledges a partial approval by keeping the reduced authorization as-is. The issuer approved less than the gateway asked for, and the operator (or the cardholder) has decided the lesser amount is acceptable, so no reversal is issued and the transaction proceeds through the normal capture / settlement path for the approved amount. Valid only while the transaction is parked at TransactionStage.SplitTenderPending with PartialApprovalData.Disposition still Pending; a late acknowledgment against a disposition the deadline sweep has already resolved is expected traffic and is rejected. Its counterpart is Void, which rejects the reduced amount instead.
  - `SplitTender`: Acknowledges a partial approval by keeping the reduced authorization and collecting the shortfall on a second tender. The continuation transaction carries the same SplitTenderGroupId with the next SplitTenderSequence. Valid only while the transaction is parked at TransactionStage.SplitTenderPending, and only when the merchant permits split tender and the group has not reached VirtualTerminalSettings.SplitTenderMaxTenders.
- `amount` (number(double)): Optional amount for partial operations (refund, reversal). What an omitted value means  differs by operation, so it is stated per operation rather than as one rule. Conditional: When Amount is not null. Must be > 0. (nullable)
- `reason` (string): Optional reason or note for the operation. (nullable)
- `idempotencyKey` (string): Optional caller-supplied idempotency key used to deduplicate a retried operation  (reversal, void, capture, refund, repeat, retry) after a network timeout. The key is  scoped to a single merchant + transaction + operation: submitting the same operation  twice with the same key executes once and the second call returns the original  operation's outcome (for a spawning operation, the same child transaction id) instead  of re-applying it. Conditional: When IdempotencyKey is not empty. Max length: 128. (nullable)
- `offlineAdjustment` ([OfflineAdjustmentFields](https://devportal.demo.winkpg.io/docs/api/models/OfflineAdjustmentFields.md)): Structured field bundle for the  `OfflineAdjustment`  operation. Required when `operationType` is  `OfflineAdjustment`; rejected by the input validator for any other operation  type so the wrong shape cannot ride along quietly. Required: When OperationType == OfflineAdjustment. Conditional: When OfflineAdjustment is not null. Conditional: When OperationType != OfflineAdjustment.
  Fields:
  - `tipAmount` (number(double)): Replacement gratuity in major currency units (e.g. `5.00` = $5.00). Mutates the  settlement `<Gratuity>` and `<SettlementAmount>` elements and  patches the transaction document's `/InvoiceData/Amounts/Tip` field when  populated. `0` is interpreted as "clear the existing tip". The transaction's  `Total` is intentionally not patched: `TrxAmounts.Total` is a computed  property (`Base + Tip + Tax + Shipping + Convenience`) re-derived on every  hydration, so the new tip flows through to the displayed Total automatically without  a stored mutation.  <b>Wired today.</b> Conditional: When TipAmount is not null. Must be >= 0. (nullable)
  - `taxAmount` (number(double)): Replacement tax amount in major currency units. Settlement-only field: does not affect  the transaction's running total. Used for interchange-rate qualification on the batch.  <b>Not yet implemented.</b> (nullable)
  - `level3Amount` (number(double)): Replacement level-3 line-item subtotal in major currency units. Settlement-only field  for level-3 (commercial card / GSA) interchange-rate qualification.  <b>Not yet implemented.</b> (nullable)
  - `poNumber` (string): Replacement purchase-order number. Settlement-only field for level-3 / level-2  commercial-card data.  <b>Not yet implemented.</b> (nullable)
  - `billingStreet` (string): Replacement AVS street value. Settlement-only field: used for retro AVS attachment  when the original auth was processed without AVS.  <b>Not yet implemented.</b> (nullable)
  - `billingZip` (string): Replacement AVS postal/ZIP value. Settlement-only field: paired with  `billingStreet`.  <b>Not yet implemented.</b> (nullable)
  - `isEmpty` (boolean): `true` when no fields are populated. An empty bundle is a caller  error: the OfflineAdjustment operation has nothing to apply. (read only)
  - `isTipOnly` (boolean): `true` when only `tipAmount` is populated (or no fields,  but `isEmpty` would be checked first). Used by the contributor to  short-circuit the non-tip wiring path that does not yet exist. (read only)
- `incrementalAuthorization` ([IncrementalAuthorizationFields](https://devportal.demo.winkpg.io/docs/api/models/IncrementalAuthorizationFields.md)): Structured field bundle for the  `IncrementalAuthorization`  operation. Required when `operationType` is  `IncrementalAuthorization`; rejected by the input validator for any other  operation type so the wrong shape cannot ride along quietly. Required: When OperationType == IncrementalAuthorization. Conditional: When IncrementalAuthorization is not null. Conditional: When OperationType != IncrementalAuthorization.
  Fields:
  - `incrementalAmount` (number(double)): The additional authorization amount to request, in major currency units (e.g. `10.00`  = $10). The new `Total_Auth_Amt` after a successful incremental auth equals the  existing approved amount plus this value. Must be strictly positive: clearing or  reducing an existing hold is the reversal flow's job, not this one. (greater than 0)
  - `reason` (string): Optional caller-supplied reason / merchant note (e.g. `"Estimated tab plus 20% tip"`).  Surfaced on the close-stage history entry and the customer-facing receipt. Not validated  against any controlled vocabulary: purely informational. Conditional: When Reason is not empty. Max length: 500. (nullable)
  - `isEmpty` (boolean): `true` when the bundle carries no actionable information. An  incremental authorization with a non-positive increment has nothing to ask the  brand for and is a caller error, rejected before anything is sent to the processor. (read only)
- `initiationType` ([InitiationType](https://devportal.demo.winkpg.io/docs/api/models/InitiationType.md)): Classification gate for `Repeat`. The caller  must declare whether the new charge is being initiated by the cardholder (CIT:  cardholder is present and authorizing this specific re-run) or by the merchant  (MIT: under prior consent or as a network resubmission of a declined attempt). Required: When OperationType == Repeat. Conditional: When InitiationType is not null. (nullable)
  Values:
  - `CardholderInitiated`: The cardholder is present or otherwise authorizing this specific charge contemporaneously. Default for transactions originated by the cardholder through HPP checkout, API with cardholder interaction, or virtual terminal sales with the cardholder present.
  - `MerchantInitiated`: The merchant is initiating this charge without contemporaneous cardholder authorization, relying on prior consent captured on an earlier cardholder-initiated transaction. Used for recurring billing, unscheduled credential-on-file charges, resubmissions, and other merchant-triggered uses of a stored credential.
- `mitReason` ([MITReasonCode](https://devportal.demo.winkpg.io/docs/api/models/MITReasonCode.md)): MIT reason code (Recurring, UnscheduledCOF, Resubmission, etc.) accompanying  `initiationType` when it is  `MerchantInitiated`. Required: When OperationType == Repeat and InitiationType == MerchantInitiated. Conditional: When MITReason is not null. (nullable)
  Values:
  - `Recurring`: Fixed or variable charges on a scheduled basis for a subscription or ongoing service the cardholder has enrolled in.
  - `Installment`: A series of charges dividing a known total amount over a defined schedule.
  - `UnscheduledCOF`: Charges triggered by a specific, pre-agreed event (e.g. account balance threshold, usage overage). Not on a schedule.
  - `Resubmission`: Recharging after a declined or reversed transaction, in accordance with card network resubmission rules. Must be for the same amount as the original declined attempt and within the network's permitted resubmission window.
  - `Reauthorization`: Re-authorizing a prior authorization (e.g. when the original authorization has expired but the merchant still intends to capture).
  - `DelayedCharge`: A charge finalized after the cardholder's original authorization (e.g. tip adjustment, additional services added after checkout, or final amounts determined after service completion).
  - `NoShow`: No-show or cancellation fee where the cardholder made a reservation or booking and failed to cancel within the required window.
  - `IncrementalAuth`: Additional authorization on top of a prior authorization (e.g. hotel incidentals, car rental overages).
- `storedCredentialConsentId` (string(uuid)): Identifier of the `StoredCredentialConsent` record that authorizes this MIT.  Required for non-resubmission MITs (Recurring, UnscheduledCOF, NoShow, DelayedCharge,  Installment, Reauthorization, IncrementalAuth). Ignored for  `Resubmission`: resubmissions are authorized by card-network  resubmission rules rather than by a consent record. (nullable)

_Example: Capture an approved authorization_

Captures an approved authorization that has not been captured or settled, so it is included in the merchant's next batch close. Put the authorization's id in the route. This endpoint captures the authorization as it stands and reads no amount for a capture.

```json
{
  "operationType": "Capture"
}
```

_Example: Reverse an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Reversal. Put the charge's id in the route. With no amount the whole remaining authorization is released and the charge is pulled from the next batch. The gateway offers Reversal or Void for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}
```

_Example: Void an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Void. Put the charge's id in the route. A void is always for the full amount and keeps the charge out of the next batch close. The gateway offers Void or Reversal for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Void",
  "reason": "Duplicate order"
}
```

_Example: Refund part of a settled sale_

Returns part of a settled sale (settleData.settlementStatus reads SettlementSucceeded) to the card or bank account it was paid with. Put the sale's id in the route. The refund is a new Return transaction linked to the sale, for the amount sent, and its id comes back as newTransactionId. Send an explicit amount on every refund after the first: an omitted amount asks for the sale's whole total. The idempotency key makes a retry after a timeout return the original outcome instead of a second refund.

```json
{
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}
```

**Content type:** `text/json`

Schema: [`ExecuteTransactionOperationInput`](https://devportal.demo.winkpg.io/docs/api/models/ExecuteTransactionOperationInput.md)

Properties:
- `operationType` ([TransactionOperationType](https://devportal.demo.winkpg.io/docs/api/models/TransactionOperationType.md)): The type of operation to execute (e.g., Refund, Reversal, Void, Capture).
  Values:
  - `Capture`: Finalizes a previously-approved authorization by sending an online capture / clearing message to the processor. Moves the transaction from "funds held" to "marked for the next batch close": settlement still happens later when the merchant's batch cuts. Valid only against approved, uncaptured TransactionType.Authorization transactions; the action matrix removes Capture once the transaction is settled (Refund is the post-settlement undo). Partial captures (less than the authorized amount) are supported and release the unused portion of the issuer hold per network rules.
  - `Refund`: Returns funds to the cardholder by spawning a new standalone TransactionType.Return transaction linked back to the parent via OriginalTransaction.TransactionId. The new transaction flows through the normal auth + settlement pipeline rather than mutating the parent in place. Used once the parent has settled (post-batch-close), at which point Reversal and Void are no longer applicable. Refund capacity is reserved against the parent's PendingRefundAmount with optimistic concurrency so concurrent partial refunds from different callers cannot collectively exceed the parent's available balance.
  - `Void`: Offline ledger-only cancel: marks the transaction for exclusion from the next batch close without sending any processor message. Used pre-settlement. Acts as the fallback when the configured processor does not support online Reversal (or the reversal window has expired). The action evaluator's mutual-exclusion step drops Void from the candidate set when Reversal is also eligible: Reversal is a strict superset of Void on the same stage. Terminal once approved.
  - `Reversal`: Online undo: sends a processor message (0420-equivalent on card networks) that releases the issuer hold on a captured-but-not-cleared transaction and pulls the transaction from the next clearing. Distinct from Void in that an actual rails-level message is exchanged with the processor; the processor can decline. Eligible post-auth and pre-settlement against Authorization, Sale, RepeatSale, and captured Authorization stages. Per-processor support is advertised via ProcessorCapabilities.SupportsReversal and gated by ReversalWindowSeconds; the gateway falls back to Void when the processor opts out. Partial reversals (strictly less than the remaining authorized balance) are supported when the processor also advertises SupportsPartialReversal; a partial reversal leaves the transaction non-terminal until cumulative reversed equals the authorized ceiling. Once settlement has cleared, Reversal is no longer valid and Refund is the only available undo.
  - `Repeat`: Re-runs a previously-approved transaction with the same payment data by spawning a new transaction linked back to the parent via OriginalTransaction.TransactionId. Authorizations repeat as Authorization (re-hold funds); Sale and RepeatSale both repeat as RepeatSale. Used for recurring billing, card-on-file scenarios, and operator-initiated re-charges. The caller may supply a different amount than the original; the new transaction flows through the normal auth + settlement pipeline. Available against approved transactions in any settlement state: once an authorization has settled, Repeat is the only re-charge path (Capture is no longer eligible).
  - `Retry`: Re-attempts a previously declined or failed transaction with the same TransactionType and the same amount as the original: changing either would violate retry semantics. Spawns a new transaction linked back to the parent via OriginalTransaction.TransactionId. Available only when the parent ended in a non-approved result code (decline, processing error, gateway failure). Distinct from Repeat, which preserves type-mapping rules (Sale → RepeatSale) and allows a caller-specified amount; Retry is intended to recover from a transient failure on the original attempt without altering its commercial intent.
  - `OfflineAdjustment`: An offline adjustment to a previously-authorized transaction's settlement record: tip (gratuity), tax, level-3 data, PO number, or AVS fields. Modifies the settlement amount/data before batch close without contacting the processor network. Tip and other amount-bearing fields are constrained to industry types that allow post-auth adjustments (restaurant, retail, e-commerce). Online amount changes (incremental authorization) belong to IncrementalAuthorization.
  - `IncrementalAuthorization`: An online incremental (or "estimated → final") authorization on top of a previously authorized (but uncaptured) transaction. The processor sends a fresh auth message to the brand network; on approve, the transaction's Total_Auth_Amt is bumped and a new auth response (with its own customer-facing receipt) replaces the prior one. Distinct from OfflineAdjustment in that an actual rails round-trip is performed and the issuer can decline. Valid only against TransactionType.Authorization transactions that have not yet been captured. Per-processor support is advertised via ProcessorCapabilities.SupportedAdjustmentTypes; the gateway rejects the operation up front when the configured processor lacks the capability.
  - `AcceptPartialApproval`: Acknowledges a partial approval by keeping the reduced authorization as-is. The issuer approved less than the gateway asked for, and the operator (or the cardholder) has decided the lesser amount is acceptable, so no reversal is issued and the transaction proceeds through the normal capture / settlement path for the approved amount. Valid only while the transaction is parked at TransactionStage.SplitTenderPending with PartialApprovalData.Disposition still Pending; a late acknowledgment against a disposition the deadline sweep has already resolved is expected traffic and is rejected. Its counterpart is Void, which rejects the reduced amount instead.
  - `SplitTender`: Acknowledges a partial approval by keeping the reduced authorization and collecting the shortfall on a second tender. The continuation transaction carries the same SplitTenderGroupId with the next SplitTenderSequence. Valid only while the transaction is parked at TransactionStage.SplitTenderPending, and only when the merchant permits split tender and the group has not reached VirtualTerminalSettings.SplitTenderMaxTenders.
- `amount` (number(double)): Optional amount for partial operations (refund, reversal). What an omitted value means  differs by operation, so it is stated per operation rather than as one rule. Conditional: When Amount is not null. Must be > 0. (nullable)
- `reason` (string): Optional reason or note for the operation. (nullable)
- `idempotencyKey` (string): Optional caller-supplied idempotency key used to deduplicate a retried operation  (reversal, void, capture, refund, repeat, retry) after a network timeout. The key is  scoped to a single merchant + transaction + operation: submitting the same operation  twice with the same key executes once and the second call returns the original  operation's outcome (for a spawning operation, the same child transaction id) instead  of re-applying it. Conditional: When IdempotencyKey is not empty. Max length: 128. (nullable)
- `offlineAdjustment` ([OfflineAdjustmentFields](https://devportal.demo.winkpg.io/docs/api/models/OfflineAdjustmentFields.md)): Structured field bundle for the  `OfflineAdjustment`  operation. Required when `operationType` is  `OfflineAdjustment`; rejected by the input validator for any other operation  type so the wrong shape cannot ride along quietly. Required: When OperationType == OfflineAdjustment. Conditional: When OfflineAdjustment is not null. Conditional: When OperationType != OfflineAdjustment.
  Fields:
  - `tipAmount` (number(double)): Replacement gratuity in major currency units (e.g. `5.00` = $5.00). Mutates the  settlement `<Gratuity>` and `<SettlementAmount>` elements and  patches the transaction document's `/InvoiceData/Amounts/Tip` field when  populated. `0` is interpreted as "clear the existing tip". The transaction's  `Total` is intentionally not patched: `TrxAmounts.Total` is a computed  property (`Base + Tip + Tax + Shipping + Convenience`) re-derived on every  hydration, so the new tip flows through to the displayed Total automatically without  a stored mutation.  <b>Wired today.</b> Conditional: When TipAmount is not null. Must be >= 0. (nullable)
  - `taxAmount` (number(double)): Replacement tax amount in major currency units. Settlement-only field: does not affect  the transaction's running total. Used for interchange-rate qualification on the batch.  <b>Not yet implemented.</b> (nullable)
  - `level3Amount` (number(double)): Replacement level-3 line-item subtotal in major currency units. Settlement-only field  for level-3 (commercial card / GSA) interchange-rate qualification.  <b>Not yet implemented.</b> (nullable)
  - `poNumber` (string): Replacement purchase-order number. Settlement-only field for level-3 / level-2  commercial-card data.  <b>Not yet implemented.</b> (nullable)
  - `billingStreet` (string): Replacement AVS street value. Settlement-only field: used for retro AVS attachment  when the original auth was processed without AVS.  <b>Not yet implemented.</b> (nullable)
  - `billingZip` (string): Replacement AVS postal/ZIP value. Settlement-only field: paired with  `billingStreet`.  <b>Not yet implemented.</b> (nullable)
  - `isEmpty` (boolean): `true` when no fields are populated. An empty bundle is a caller  error: the OfflineAdjustment operation has nothing to apply. (read only)
  - `isTipOnly` (boolean): `true` when only `tipAmount` is populated (or no fields,  but `isEmpty` would be checked first). Used by the contributor to  short-circuit the non-tip wiring path that does not yet exist. (read only)
- `incrementalAuthorization` ([IncrementalAuthorizationFields](https://devportal.demo.winkpg.io/docs/api/models/IncrementalAuthorizationFields.md)): Structured field bundle for the  `IncrementalAuthorization`  operation. Required when `operationType` is  `IncrementalAuthorization`; rejected by the input validator for any other  operation type so the wrong shape cannot ride along quietly. Required: When OperationType == IncrementalAuthorization. Conditional: When IncrementalAuthorization is not null. Conditional: When OperationType != IncrementalAuthorization.
  Fields:
  - `incrementalAmount` (number(double)): The additional authorization amount to request, in major currency units (e.g. `10.00`  = $10). The new `Total_Auth_Amt` after a successful incremental auth equals the  existing approved amount plus this value. Must be strictly positive: clearing or  reducing an existing hold is the reversal flow's job, not this one. (greater than 0)
  - `reason` (string): Optional caller-supplied reason / merchant note (e.g. `"Estimated tab plus 20% tip"`).  Surfaced on the close-stage history entry and the customer-facing receipt. Not validated  against any controlled vocabulary: purely informational. Conditional: When Reason is not empty. Max length: 500. (nullable)
  - `isEmpty` (boolean): `true` when the bundle carries no actionable information. An  incremental authorization with a non-positive increment has nothing to ask the  brand for and is a caller error, rejected before anything is sent to the processor. (read only)
- `initiationType` ([InitiationType](https://devportal.demo.winkpg.io/docs/api/models/InitiationType.md)): Classification gate for `Repeat`. The caller  must declare whether the new charge is being initiated by the cardholder (CIT:  cardholder is present and authorizing this specific re-run) or by the merchant  (MIT: under prior consent or as a network resubmission of a declined attempt). Required: When OperationType == Repeat. Conditional: When InitiationType is not null. (nullable)
  Values:
  - `CardholderInitiated`: The cardholder is present or otherwise authorizing this specific charge contemporaneously. Default for transactions originated by the cardholder through HPP checkout, API with cardholder interaction, or virtual terminal sales with the cardholder present.
  - `MerchantInitiated`: The merchant is initiating this charge without contemporaneous cardholder authorization, relying on prior consent captured on an earlier cardholder-initiated transaction. Used for recurring billing, unscheduled credential-on-file charges, resubmissions, and other merchant-triggered uses of a stored credential.
- `mitReason` ([MITReasonCode](https://devportal.demo.winkpg.io/docs/api/models/MITReasonCode.md)): MIT reason code (Recurring, UnscheduledCOF, Resubmission, etc.) accompanying  `initiationType` when it is  `MerchantInitiated`. Required: When OperationType == Repeat and InitiationType == MerchantInitiated. Conditional: When MITReason is not null. (nullable)
  Values:
  - `Recurring`: Fixed or variable charges on a scheduled basis for a subscription or ongoing service the cardholder has enrolled in.
  - `Installment`: A series of charges dividing a known total amount over a defined schedule.
  - `UnscheduledCOF`: Charges triggered by a specific, pre-agreed event (e.g. account balance threshold, usage overage). Not on a schedule.
  - `Resubmission`: Recharging after a declined or reversed transaction, in accordance with card network resubmission rules. Must be for the same amount as the original declined attempt and within the network's permitted resubmission window.
  - `Reauthorization`: Re-authorizing a prior authorization (e.g. when the original authorization has expired but the merchant still intends to capture).
  - `DelayedCharge`: A charge finalized after the cardholder's original authorization (e.g. tip adjustment, additional services added after checkout, or final amounts determined after service completion).
  - `NoShow`: No-show or cancellation fee where the cardholder made a reservation or booking and failed to cancel within the required window.
  - `IncrementalAuth`: Additional authorization on top of a prior authorization (e.g. hotel incidentals, car rental overages).
- `storedCredentialConsentId` (string(uuid)): Identifier of the `StoredCredentialConsent` record that authorizes this MIT.  Required for non-resubmission MITs (Recurring, UnscheduledCOF, NoShow, DelayedCharge,  Installment, Reauthorization, IncrementalAuth). Ignored for  `Resubmission`: resubmissions are authorized by card-network  resubmission rules rather than by a consent record. (nullable)

_Example: Capture an approved authorization_

Captures an approved authorization that has not been captured or settled, so it is included in the merchant's next batch close. Put the authorization's id in the route. This endpoint captures the authorization as it stands and reads no amount for a capture.

```json
{
  "operationType": "Capture"
}
```

_Example: Reverse an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Reversal. Put the charge's id in the route. With no amount the whole remaining authorization is released and the charge is pulled from the next batch. The gateway offers Reversal or Void for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}
```

_Example: Void an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Void. Put the charge's id in the route. A void is always for the full amount and keeps the charge out of the next batch close. The gateway offers Void or Reversal for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Void",
  "reason": "Duplicate order"
}
```

_Example: Refund part of a settled sale_

Returns part of a settled sale (settleData.settlementStatus reads SettlementSucceeded) to the card or bank account it was paid with. Put the sale's id in the route. The refund is a new Return transaction linked to the sale, for the amount sent, and its id comes back as newTransactionId. Send an explicit amount on every refund after the first: an omitted amount asks for the sale's whole total. The idempotency key makes a retry after a timeout return the original outcome instead of a second refund.

```json
{
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}
```

**Content type:** `application/*+json`

Schema: [`ExecuteTransactionOperationInput`](https://devportal.demo.winkpg.io/docs/api/models/ExecuteTransactionOperationInput.md)

Properties:
- `operationType` ([TransactionOperationType](https://devportal.demo.winkpg.io/docs/api/models/TransactionOperationType.md)): The type of operation to execute (e.g., Refund, Reversal, Void, Capture).
  Values:
  - `Capture`: Finalizes a previously-approved authorization by sending an online capture / clearing message to the processor. Moves the transaction from "funds held" to "marked for the next batch close": settlement still happens later when the merchant's batch cuts. Valid only against approved, uncaptured TransactionType.Authorization transactions; the action matrix removes Capture once the transaction is settled (Refund is the post-settlement undo). Partial captures (less than the authorized amount) are supported and release the unused portion of the issuer hold per network rules.
  - `Refund`: Returns funds to the cardholder by spawning a new standalone TransactionType.Return transaction linked back to the parent via OriginalTransaction.TransactionId. The new transaction flows through the normal auth + settlement pipeline rather than mutating the parent in place. Used once the parent has settled (post-batch-close), at which point Reversal and Void are no longer applicable. Refund capacity is reserved against the parent's PendingRefundAmount with optimistic concurrency so concurrent partial refunds from different callers cannot collectively exceed the parent's available balance.
  - `Void`: Offline ledger-only cancel: marks the transaction for exclusion from the next batch close without sending any processor message. Used pre-settlement. Acts as the fallback when the configured processor does not support online Reversal (or the reversal window has expired). The action evaluator's mutual-exclusion step drops Void from the candidate set when Reversal is also eligible: Reversal is a strict superset of Void on the same stage. Terminal once approved.
  - `Reversal`: Online undo: sends a processor message (0420-equivalent on card networks) that releases the issuer hold on a captured-but-not-cleared transaction and pulls the transaction from the next clearing. Distinct from Void in that an actual rails-level message is exchanged with the processor; the processor can decline. Eligible post-auth and pre-settlement against Authorization, Sale, RepeatSale, and captured Authorization stages. Per-processor support is advertised via ProcessorCapabilities.SupportsReversal and gated by ReversalWindowSeconds; the gateway falls back to Void when the processor opts out. Partial reversals (strictly less than the remaining authorized balance) are supported when the processor also advertises SupportsPartialReversal; a partial reversal leaves the transaction non-terminal until cumulative reversed equals the authorized ceiling. Once settlement has cleared, Reversal is no longer valid and Refund is the only available undo.
  - `Repeat`: Re-runs a previously-approved transaction with the same payment data by spawning a new transaction linked back to the parent via OriginalTransaction.TransactionId. Authorizations repeat as Authorization (re-hold funds); Sale and RepeatSale both repeat as RepeatSale. Used for recurring billing, card-on-file scenarios, and operator-initiated re-charges. The caller may supply a different amount than the original; the new transaction flows through the normal auth + settlement pipeline. Available against approved transactions in any settlement state: once an authorization has settled, Repeat is the only re-charge path (Capture is no longer eligible).
  - `Retry`: Re-attempts a previously declined or failed transaction with the same TransactionType and the same amount as the original: changing either would violate retry semantics. Spawns a new transaction linked back to the parent via OriginalTransaction.TransactionId. Available only when the parent ended in a non-approved result code (decline, processing error, gateway failure). Distinct from Repeat, which preserves type-mapping rules (Sale → RepeatSale) and allows a caller-specified amount; Retry is intended to recover from a transient failure on the original attempt without altering its commercial intent.
  - `OfflineAdjustment`: An offline adjustment to a previously-authorized transaction's settlement record: tip (gratuity), tax, level-3 data, PO number, or AVS fields. Modifies the settlement amount/data before batch close without contacting the processor network. Tip and other amount-bearing fields are constrained to industry types that allow post-auth adjustments (restaurant, retail, e-commerce). Online amount changes (incremental authorization) belong to IncrementalAuthorization.
  - `IncrementalAuthorization`: An online incremental (or "estimated → final") authorization on top of a previously authorized (but uncaptured) transaction. The processor sends a fresh auth message to the brand network; on approve, the transaction's Total_Auth_Amt is bumped and a new auth response (with its own customer-facing receipt) replaces the prior one. Distinct from OfflineAdjustment in that an actual rails round-trip is performed and the issuer can decline. Valid only against TransactionType.Authorization transactions that have not yet been captured. Per-processor support is advertised via ProcessorCapabilities.SupportedAdjustmentTypes; the gateway rejects the operation up front when the configured processor lacks the capability.
  - `AcceptPartialApproval`: Acknowledges a partial approval by keeping the reduced authorization as-is. The issuer approved less than the gateway asked for, and the operator (or the cardholder) has decided the lesser amount is acceptable, so no reversal is issued and the transaction proceeds through the normal capture / settlement path for the approved amount. Valid only while the transaction is parked at TransactionStage.SplitTenderPending with PartialApprovalData.Disposition still Pending; a late acknowledgment against a disposition the deadline sweep has already resolved is expected traffic and is rejected. Its counterpart is Void, which rejects the reduced amount instead.
  - `SplitTender`: Acknowledges a partial approval by keeping the reduced authorization and collecting the shortfall on a second tender. The continuation transaction carries the same SplitTenderGroupId with the next SplitTenderSequence. Valid only while the transaction is parked at TransactionStage.SplitTenderPending, and only when the merchant permits split tender and the group has not reached VirtualTerminalSettings.SplitTenderMaxTenders.
- `amount` (number(double)): Optional amount for partial operations (refund, reversal). What an omitted value means  differs by operation, so it is stated per operation rather than as one rule. Conditional: When Amount is not null. Must be > 0. (nullable)
- `reason` (string): Optional reason or note for the operation. (nullable)
- `idempotencyKey` (string): Optional caller-supplied idempotency key used to deduplicate a retried operation  (reversal, void, capture, refund, repeat, retry) after a network timeout. The key is  scoped to a single merchant + transaction + operation: submitting the same operation  twice with the same key executes once and the second call returns the original  operation's outcome (for a spawning operation, the same child transaction id) instead  of re-applying it. Conditional: When IdempotencyKey is not empty. Max length: 128. (nullable)
- `offlineAdjustment` ([OfflineAdjustmentFields](https://devportal.demo.winkpg.io/docs/api/models/OfflineAdjustmentFields.md)): Structured field bundle for the  `OfflineAdjustment`  operation. Required when `operationType` is  `OfflineAdjustment`; rejected by the input validator for any other operation  type so the wrong shape cannot ride along quietly. Required: When OperationType == OfflineAdjustment. Conditional: When OfflineAdjustment is not null. Conditional: When OperationType != OfflineAdjustment.
  Fields:
  - `tipAmount` (number(double)): Replacement gratuity in major currency units (e.g. `5.00` = $5.00). Mutates the  settlement `<Gratuity>` and `<SettlementAmount>` elements and  patches the transaction document's `/InvoiceData/Amounts/Tip` field when  populated. `0` is interpreted as "clear the existing tip". The transaction's  `Total` is intentionally not patched: `TrxAmounts.Total` is a computed  property (`Base + Tip + Tax + Shipping + Convenience`) re-derived on every  hydration, so the new tip flows through to the displayed Total automatically without  a stored mutation.  <b>Wired today.</b> Conditional: When TipAmount is not null. Must be >= 0. (nullable)
  - `taxAmount` (number(double)): Replacement tax amount in major currency units. Settlement-only field: does not affect  the transaction's running total. Used for interchange-rate qualification on the batch.  <b>Not yet implemented.</b> (nullable)
  - `level3Amount` (number(double)): Replacement level-3 line-item subtotal in major currency units. Settlement-only field  for level-3 (commercial card / GSA) interchange-rate qualification.  <b>Not yet implemented.</b> (nullable)
  - `poNumber` (string): Replacement purchase-order number. Settlement-only field for level-3 / level-2  commercial-card data.  <b>Not yet implemented.</b> (nullable)
  - `billingStreet` (string): Replacement AVS street value. Settlement-only field: used for retro AVS attachment  when the original auth was processed without AVS.  <b>Not yet implemented.</b> (nullable)
  - `billingZip` (string): Replacement AVS postal/ZIP value. Settlement-only field: paired with  `billingStreet`.  <b>Not yet implemented.</b> (nullable)
  - `isEmpty` (boolean): `true` when no fields are populated. An empty bundle is a caller  error: the OfflineAdjustment operation has nothing to apply. (read only)
  - `isTipOnly` (boolean): `true` when only `tipAmount` is populated (or no fields,  but `isEmpty` would be checked first). Used by the contributor to  short-circuit the non-tip wiring path that does not yet exist. (read only)
- `incrementalAuthorization` ([IncrementalAuthorizationFields](https://devportal.demo.winkpg.io/docs/api/models/IncrementalAuthorizationFields.md)): Structured field bundle for the  `IncrementalAuthorization`  operation. Required when `operationType` is  `IncrementalAuthorization`; rejected by the input validator for any other  operation type so the wrong shape cannot ride along quietly. Required: When OperationType == IncrementalAuthorization. Conditional: When IncrementalAuthorization is not null. Conditional: When OperationType != IncrementalAuthorization.
  Fields:
  - `incrementalAmount` (number(double)): The additional authorization amount to request, in major currency units (e.g. `10.00`  = $10). The new `Total_Auth_Amt` after a successful incremental auth equals the  existing approved amount plus this value. Must be strictly positive: clearing or  reducing an existing hold is the reversal flow's job, not this one. (greater than 0)
  - `reason` (string): Optional caller-supplied reason / merchant note (e.g. `"Estimated tab plus 20% tip"`).  Surfaced on the close-stage history entry and the customer-facing receipt. Not validated  against any controlled vocabulary: purely informational. Conditional: When Reason is not empty. Max length: 500. (nullable)
  - `isEmpty` (boolean): `true` when the bundle carries no actionable information. An  incremental authorization with a non-positive increment has nothing to ask the  brand for and is a caller error, rejected before anything is sent to the processor. (read only)
- `initiationType` ([InitiationType](https://devportal.demo.winkpg.io/docs/api/models/InitiationType.md)): Classification gate for `Repeat`. The caller  must declare whether the new charge is being initiated by the cardholder (CIT:  cardholder is present and authorizing this specific re-run) or by the merchant  (MIT: under prior consent or as a network resubmission of a declined attempt). Required: When OperationType == Repeat. Conditional: When InitiationType is not null. (nullable)
  Values:
  - `CardholderInitiated`: The cardholder is present or otherwise authorizing this specific charge contemporaneously. Default for transactions originated by the cardholder through HPP checkout, API with cardholder interaction, or virtual terminal sales with the cardholder present.
  - `MerchantInitiated`: The merchant is initiating this charge without contemporaneous cardholder authorization, relying on prior consent captured on an earlier cardholder-initiated transaction. Used for recurring billing, unscheduled credential-on-file charges, resubmissions, and other merchant-triggered uses of a stored credential.
- `mitReason` ([MITReasonCode](https://devportal.demo.winkpg.io/docs/api/models/MITReasonCode.md)): MIT reason code (Recurring, UnscheduledCOF, Resubmission, etc.) accompanying  `initiationType` when it is  `MerchantInitiated`. Required: When OperationType == Repeat and InitiationType == MerchantInitiated. Conditional: When MITReason is not null. (nullable)
  Values:
  - `Recurring`: Fixed or variable charges on a scheduled basis for a subscription or ongoing service the cardholder has enrolled in.
  - `Installment`: A series of charges dividing a known total amount over a defined schedule.
  - `UnscheduledCOF`: Charges triggered by a specific, pre-agreed event (e.g. account balance threshold, usage overage). Not on a schedule.
  - `Resubmission`: Recharging after a declined or reversed transaction, in accordance with card network resubmission rules. Must be for the same amount as the original declined attempt and within the network's permitted resubmission window.
  - `Reauthorization`: Re-authorizing a prior authorization (e.g. when the original authorization has expired but the merchant still intends to capture).
  - `DelayedCharge`: A charge finalized after the cardholder's original authorization (e.g. tip adjustment, additional services added after checkout, or final amounts determined after service completion).
  - `NoShow`: No-show or cancellation fee where the cardholder made a reservation or booking and failed to cancel within the required window.
  - `IncrementalAuth`: Additional authorization on top of a prior authorization (e.g. hotel incidentals, car rental overages).
- `storedCredentialConsentId` (string(uuid)): Identifier of the `StoredCredentialConsent` record that authorizes this MIT.  Required for non-resubmission MITs (Recurring, UnscheduledCOF, NoShow, DelayedCharge,  Installment, Reauthorization, IncrementalAuth). Ignored for  `Resubmission`: resubmissions are authorized by card-network  resubmission rules rather than by a consent record. (nullable)

_Example: Capture an approved authorization_

Captures an approved authorization that has not been captured or settled, so it is included in the merchant's next batch close. Put the authorization's id in the route. This endpoint captures the authorization as it stands and reads no amount for a capture.

```json
{
  "operationType": "Capture"
}
```

_Example: Reverse an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Reversal. Put the charge's id in the route. With no amount the whole remaining authorization is released and the charge is pulled from the next batch. The gateway offers Reversal or Void for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}
```

_Example: Void an unsettled charge_

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Void. Put the charge's id in the route. A void is always for the full amount and keeps the charge out of the next batch close. The gateway offers Void or Reversal for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

```json
{
  "operationType": "Void",
  "reason": "Duplicate order"
}
```

_Example: Refund part of a settled sale_

Returns part of a settled sale (settleData.settlementStatus reads SettlementSucceeded) to the card or bank account it was paid with. Put the sale's id in the route. The refund is a new Return transaction linked to the sale, for the amount sent, and its id comes back as newTransactionId. Send an explicit amount on every refund after the first: an omitted amount asks for the sale's whole total. The idempotency key makes a retry after a timeout return the original outcome instead of a second refund.

```json
{
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}
```

## Responses

### 200

OK

**Content type:** `application/json`

Schema: [`TransactionOperationResultDto`](https://devportal.demo.winkpg.io/docs/api/models/TransactionOperationResultDto.md)

Properties:
- `success` (boolean): Whether the operation was successfully submitted to the orchestrator.
- `message` (string): Human-readable message describing the result. (nullable)
- `transactionId` (string(uuid)): The original transaction ID the operation was performed on.
- `operationType` ([TransactionOperationType](https://devportal.demo.winkpg.io/docs/api/models/TransactionOperationType.md)): The operation type that was executed.
  Values:
  - `Capture`: Finalizes a previously-approved authorization by sending an online capture / clearing message to the processor. Moves the transaction from "funds held" to "marked for the next batch close": settlement still happens later when the merchant's batch cuts. Valid only against approved, uncaptured TransactionType.Authorization transactions; the action matrix removes Capture once the transaction is settled (Refund is the post-settlement undo). Partial captures (less than the authorized amount) are supported and release the unused portion of the issuer hold per network rules.
  - `Refund`: Returns funds to the cardholder by spawning a new standalone TransactionType.Return transaction linked back to the parent via OriginalTransaction.TransactionId. The new transaction flows through the normal auth + settlement pipeline rather than mutating the parent in place. Used once the parent has settled (post-batch-close), at which point Reversal and Void are no longer applicable. Refund capacity is reserved against the parent's PendingRefundAmount with optimistic concurrency so concurrent partial refunds from different callers cannot collectively exceed the parent's available balance.
  - `Void`: Offline ledger-only cancel: marks the transaction for exclusion from the next batch close without sending any processor message. Used pre-settlement. Acts as the fallback when the configured processor does not support online Reversal (or the reversal window has expired). The action evaluator's mutual-exclusion step drops Void from the candidate set when Reversal is also eligible: Reversal is a strict superset of Void on the same stage. Terminal once approved.
  - `Reversal`: Online undo: sends a processor message (0420-equivalent on card networks) that releases the issuer hold on a captured-but-not-cleared transaction and pulls the transaction from the next clearing. Distinct from Void in that an actual rails-level message is exchanged with the processor; the processor can decline. Eligible post-auth and pre-settlement against Authorization, Sale, RepeatSale, and captured Authorization stages. Per-processor support is advertised via ProcessorCapabilities.SupportsReversal and gated by ReversalWindowSeconds; the gateway falls back to Void when the processor opts out. Partial reversals (strictly less than the remaining authorized balance) are supported when the processor also advertises SupportsPartialReversal; a partial reversal leaves the transaction non-terminal until cumulative reversed equals the authorized ceiling. Once settlement has cleared, Reversal is no longer valid and Refund is the only available undo.
  - `Repeat`: Re-runs a previously-approved transaction with the same payment data by spawning a new transaction linked back to the parent via OriginalTransaction.TransactionId. Authorizations repeat as Authorization (re-hold funds); Sale and RepeatSale both repeat as RepeatSale. Used for recurring billing, card-on-file scenarios, and operator-initiated re-charges. The caller may supply a different amount than the original; the new transaction flows through the normal auth + settlement pipeline. Available against approved transactions in any settlement state: once an authorization has settled, Repeat is the only re-charge path (Capture is no longer eligible).
  - `Retry`: Re-attempts a previously declined or failed transaction with the same TransactionType and the same amount as the original: changing either would violate retry semantics. Spawns a new transaction linked back to the parent via OriginalTransaction.TransactionId. Available only when the parent ended in a non-approved result code (decline, processing error, gateway failure). Distinct from Repeat, which preserves type-mapping rules (Sale → RepeatSale) and allows a caller-specified amount; Retry is intended to recover from a transient failure on the original attempt without altering its commercial intent.
  - `OfflineAdjustment`: An offline adjustment to a previously-authorized transaction's settlement record: tip (gratuity), tax, level-3 data, PO number, or AVS fields. Modifies the settlement amount/data before batch close without contacting the processor network. Tip and other amount-bearing fields are constrained to industry types that allow post-auth adjustments (restaurant, retail, e-commerce). Online amount changes (incremental authorization) belong to IncrementalAuthorization.
  - `IncrementalAuthorization`: An online incremental (or "estimated → final") authorization on top of a previously authorized (but uncaptured) transaction. The processor sends a fresh auth message to the brand network; on approve, the transaction's Total_Auth_Amt is bumped and a new auth response (with its own customer-facing receipt) replaces the prior one. Distinct from OfflineAdjustment in that an actual rails round-trip is performed and the issuer can decline. Valid only against TransactionType.Authorization transactions that have not yet been captured. Per-processor support is advertised via ProcessorCapabilities.SupportedAdjustmentTypes; the gateway rejects the operation up front when the configured processor lacks the capability.
  - `AcceptPartialApproval`: Acknowledges a partial approval by keeping the reduced authorization as-is. The issuer approved less than the gateway asked for, and the operator (or the cardholder) has decided the lesser amount is acceptable, so no reversal is issued and the transaction proceeds through the normal capture / settlement path for the approved amount. Valid only while the transaction is parked at TransactionStage.SplitTenderPending with PartialApprovalData.Disposition still Pending; a late acknowledgment against a disposition the deadline sweep has already resolved is expected traffic and is rejected. Its counterpart is Void, which rejects the reduced amount instead.
  - `SplitTender`: Acknowledges a partial approval by keeping the reduced authorization and collecting the shortfall on a second tender. The continuation transaction carries the same SplitTenderGroupId with the next SplitTenderSequence. Valid only while the transaction is parked at TransactionStage.SplitTenderPending, and only when the merchant permits split tender and the group has not reached VirtualTerminalSettings.SplitTenderMaxTenders.
- `errorCode` (string): Machine-readable error code for programmatic handling. (nullable)
- `timedOut` (boolean): True when the operation was submitted to the orchestrator but completion  timed out. The operation may still be processing: the user should check the transaction status.
- `newTransactionId` (string(uuid)): The ID of a newly created transaction, set when the operation creates a new transaction  (e.g., Repeat). Null for operations that modify the existing transaction in-place. (nullable)

### 403

Forbidden

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

### 401

Unauthorized

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

### 400

Bad Request

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

_Example: Request failed validation_

One or more fields were rejected before any rule ran. error.code is null on the envelope and the causes are in validationErrors, one entry per failure. An entry carries code when the validator declared a publishable one, and memberPaths when the full path says more than members does (an element inside a collection, for example). Both keys are omitted when they would add nothing.

```json
{
  "error": {
    "code": "null",
    "message": "Your request is not valid!",
    "details": "The following errors were detected during validation.",
    "data": {
      "correlationId": "0123456789abcdef0123456789abcdef"
    },
    "validationErrors": [
      {
        "message": "'Amount' must be greater than 0.",
        "members": [
          "amount"
        ]
      },
      {
        "message": "The card has expired.",
        "members": [
          "expirationDate"
        ],
        "code": "CardData:CardExpired"
      },
      {
        "message": "'Value' must not be empty.",
        "members": [
          "value"
        ],
        "memberPaths": [
          "customFields[2].value"
        ]
      }
    ]
  }
}
```

### 404

Not Found

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

_Example: Resource not found_

The id in the path names no record the caller can see. Most resources answer with a null error.code and a message naming the resource type and the id; a resource that publishes a not-found code in the catalog above carries it in error.code instead, so check for one before matching on the message.

```json
{
  "error": {
    "code": "null",
    "message": "There is no entity Transaction with id = 7d1f3a52-0c4e-4b8a-9e21-5a6b7c8d9e00!",
    "details": "null",
    "data": {
      "correlationId": "0123456789abcdef0123456789abcdef"
    },
    "validationErrors": "null"
  }
}
```

### 501

Not Implemented

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

### 500

Internal Server Error

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

### default

The request failed. The body carries the standard error envelope: a machine-readable `error.code`, a human-readable `error.message`, and `error.validationErrors` when the failure was a validation rejection. The [error reference](https://devportal.demo.winkpg.io/docs/errors.md) lists the values `error.code` can take.

**Content type:** `application/json`

Schema: [`RemoteServiceErrorResponse`](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorResponse.md)

Properties:
- `error` ([RemoteServiceErrorInfo](https://devportal.demo.winkpg.io/docs/api/models/RemoteServiceErrorInfo.md))

_Example: Business rule refused the request_

The request was understood and rejected by a platform rule. This is the shape that carries a code from the catalog above, so branch on error.code rather than on the message text. The HTTP status is the one listed against the code.

```json
{
  "error": {
    "code": "Transactions:OperationNotAllowed",
    "message": "The operation 'Void' is not allowed on a Sale transaction with result 'Approved' and settlement state 'Settled'.",
    "details": "null",
    "data": {
      "correlationId": "0123456789abcdef0123456789abcdef"
    },
    "validationErrors": "null"
  }
}
```

### 429

The request was refused because a rate limit was exceeded, or because something a later retry can clear stopped it. A rate limit refusal carries an `application/problem+json` body: wait at least the interval `Retry-After` names before retrying, then back off. Limits are tuned per deployment, so read the allowance from the response headers rather than assuming a fixed ceiling. Any other refusal carries the standard error envelope as `application/json`, and its `error.code` names the cause. A sandbox request whose merchant has spent the plan's transaction allowance is refused with a different `application/json` body: `code` is `USAGE_BUDGET_EXCEEDED`, and `limit` and `used` report the allowance. `Retry-After` is sent only when the allowance resets. An allowance that never resets sends none, and retrying won't help.

**Content type:** `application/problem+json`

Schema: [`RateLimitProblemDetails`](https://devportal.demo.winkpg.io/docs/api/models/RateLimitProblemDetails.md)

Properties:
- `type` (string) required: The problem type identifier. Always the same value: the failure is the status code itself,  so there is no sub-type for a caller to branch on. (nullable)
- `title` (string) required: A short, human-readable summary of the problem type. (nullable)
- `status` (integer(int32)) required: The HTTP status code, repeated in the body as the problem-details format defines.
- `detail` (string) required: A human-readable explanation of this occurrence of the problem. (nullable)
- `retryAfterSeconds` (integer(int32)) required: How long to wait before retrying, in whole seconds, carrying the same figure as the  `Retry-After` header. Always at least one: a value of zero would invite an immediate  retry that is certain to be rejected again.

**Content type:** `application/json`

Schema type: `object`

## Example request

Every block below sends the same request. Replace {{BASE_URL}} with the address of the API you are calling and {{API_KEY}} with your own key.

The request body is a ExecuteTransactionOperationInput. See the Request body section below for its fields.

These blocks send the Capture an approved authorization example. The other examples follow under Other request examples.

Captures an approved authorization that has not been captured or settled, so it is included in the merchant's next batch close. Put the authorization's id in the route. This endpoint captures the authorization as it stands and reads no amount for a capture.

### cURL

```bash
curl -X POST "{{BASE_URL}}/api/transactions/{id}/operations" \
  -H "api-key: {{API_KEY}}" \
  -H "Content-Type: application/json" \
  -d '{
  "operationType": "Capture"
}'
```

### PowerShell

```powershell
$headers = @{
    'api-key' = '{{API_KEY}}'
}

$body = @'
{
  "operationType": "Capture"
}
'@

$response = Invoke-RestMethod -Method POST -Uri '{{BASE_URL}}/api/transactions/{id}/operations' `
    -Headers $headers -ContentType 'application/json' -Body $body
```

### TypeScript (SDK)

```bash
npm install @winkpg/winkpg-api
```

```typescript
import { Configuration, TransactionsApi } from '@winkpg/winkpg-api';

const api = new TransactionsApi(new Configuration({
  basePath: '{{BASE_URL}}',
  apiKey: '{{API_KEY}}',
}));

const { data } = await api.transactionOperationsExecuteOperationLegacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", {
  "operationType": "Capture"
});
```

### TypeScript (raw HTTP)

```typescript
const response = await fetch('{{BASE_URL}}/api/transactions/{id}/operations', {
  method: 'POST',
  headers: {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "operationType": "Capture"
  }),
});

const data = await response.json();
```

### C# (SDK)

```bash
dotnet add package WinkPg.Api.Client
```

```csharp
using WinkPg.Api.Client.Api;
using WinkPg.Api.Client.Client;
using System.Text.Json;

var config = new Configuration { BasePath = "{{BASE_URL}}" };
config.AddApiKey("api-key", "{{API_KEY}}");

var api = new TransactionsApi(config);
var body = JsonSerializer.Deserialize<ExecuteTransactionOperationInput>("""
    {
      "operationType": "Capture"
    }
    """);

var result = await api.TransactionOperationsExecuteOperationLegacyAsync(Guid.Parse("3fa85f64-5717-4562-b3fc-2c963f66afa6"), body);
```

### C# (raw HTTP)

```csharp
using System.Text;

using var http = new HttpClient { BaseAddress = new Uri("{{BASE_URL}}") };

var request = new HttpRequestMessage(new HttpMethod("POST"), "/api/transactions/{id}/operations");
request.Headers.Add("api-key", "{{API_KEY}}");

request.Content = new StringContent("""
    {
      "operationType": "Capture"
    }
    """, Encoding.UTF8, "application/json");

var response = await http.SendAsync(request);
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsStringAsync();
```

### Python (SDK)

```bash
pip install winkpg-api
```

```python
import winkpg_api

configuration = winkpg_api.Configuration(host="{{BASE_URL}}")
configuration.api_key["ApiKey"] = "{{API_KEY}}"

with winkpg_api.ApiClient(configuration) as client:
    api = winkpg_api.TransactionsApi(client)
    body = winkpg_api.ExecuteTransactionOperationInput.from_dict({
      "operationType": "Capture"
    })
    result = api.transaction_operations_execute_operation_legacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", body)
```

### Python (raw HTTP)

```bash
pip install requests
```

```python
import requests

headers = {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
}

body = {
  "operationType": "Capture"
}

response = requests.request(
    "POST",
    "{{BASE_URL}}/api/transactions/{id}/operations",
    headers=headers,
    json=body,
)
response.raise_for_status()
data = response.json()
```

## Other request examples

Each example below is one request, shown in every language with the same placeholders.

### Reverse an unsettled charge

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Reversal. Put the charge's id in the route. With no amount the whole remaining authorization is released and the charge is pulled from the next batch. The gateway offers Reversal or Void for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

#### cURL

```bash
curl -X POST "{{BASE_URL}}/api/transactions/{id}/operations" \
  -H "api-key: {{API_KEY}}" \
  -H "Content-Type: application/json" \
  -d '{
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}'
```

#### PowerShell

```powershell
$headers = @{
    'api-key' = '{{API_KEY}}'
}

$body = @'
{
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}
'@

$response = Invoke-RestMethod -Method POST -Uri '{{BASE_URL}}/api/transactions/{id}/operations' `
    -Headers $headers -ContentType 'application/json' -Body $body
```

#### TypeScript (SDK)

```bash
npm install @winkpg/winkpg-api
```

```typescript
import { Configuration, TransactionsApi } from '@winkpg/winkpg-api';

const api = new TransactionsApi(new Configuration({
  basePath: '{{BASE_URL}}',
  apiKey: '{{API_KEY}}',
}));

const { data } = await api.transactionOperationsExecuteOperationLegacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", {
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
});
```

#### TypeScript (raw HTTP)

```typescript
const response = await fetch('{{BASE_URL}}/api/transactions/{id}/operations', {
  method: 'POST',
  headers: {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "operationType": "Reversal",
    "reason": "Customer canceled before shipping"
  }),
});

const data = await response.json();
```

#### C# (SDK)

```bash
dotnet add package WinkPg.Api.Client
```

```csharp
using WinkPg.Api.Client.Api;
using WinkPg.Api.Client.Client;
using System.Text.Json;

var config = new Configuration { BasePath = "{{BASE_URL}}" };
config.AddApiKey("api-key", "{{API_KEY}}");

var api = new TransactionsApi(config);
var body = JsonSerializer.Deserialize<ExecuteTransactionOperationInput>("""
    {
      "operationType": "Reversal",
      "reason": "Customer canceled before shipping"
    }
    """);

var result = await api.TransactionOperationsExecuteOperationLegacyAsync(Guid.Parse("3fa85f64-5717-4562-b3fc-2c963f66afa6"), body);
```

#### C# (raw HTTP)

```csharp
using System.Text;

using var http = new HttpClient { BaseAddress = new Uri("{{BASE_URL}}") };

var request = new HttpRequestMessage(new HttpMethod("POST"), "/api/transactions/{id}/operations");
request.Headers.Add("api-key", "{{API_KEY}}");

request.Content = new StringContent("""
    {
      "operationType": "Reversal",
      "reason": "Customer canceled before shipping"
    }
    """, Encoding.UTF8, "application/json");

var response = await http.SendAsync(request);
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsStringAsync();
```

#### Python (SDK)

```bash
pip install winkpg-api
```

```python
import winkpg_api

configuration = winkpg_api.Configuration(host="{{BASE_URL}}")
configuration.api_key["ApiKey"] = "{{API_KEY}}"

with winkpg_api.ApiClient(configuration) as client:
    api = winkpg_api.TransactionsApi(client)
    body = winkpg_api.ExecuteTransactionOperationInput.from_dict({
      "operationType": "Reversal",
      "reason": "Customer canceled before shipping"
    })
    result = api.transaction_operations_execute_operation_legacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", body)
```

#### Python (raw HTTP)

```bash
pip install requests
```

```python
import requests

headers = {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
}

body = {
  "operationType": "Reversal",
  "reason": "Customer canceled before shipping"
}

response = requests.request(
    "POST",
    "{{BASE_URL}}/api/transactions/{id}/operations",
    headers=headers,
    json=body,
)
response.raise_for_status()
data = response.json()
```

### Void an unsettled charge

Cancels an approved charge that has not settled, when the transaction's allowedActions lists Void. Put the charge's id in the route. A void is always for the full amount and keeps the charge out of the next batch close. The gateway offers Void or Reversal for a transaction according to the merchant's processor, so read allowedActions and send the cancel it lists. The reason is kept as a note on the transaction.

#### cURL

```bash
curl -X POST "{{BASE_URL}}/api/transactions/{id}/operations" \
  -H "api-key: {{API_KEY}}" \
  -H "Content-Type: application/json" \
  -d '{
  "operationType": "Void",
  "reason": "Duplicate order"
}'
```

#### PowerShell

```powershell
$headers = @{
    'api-key' = '{{API_KEY}}'
}

$body = @'
{
  "operationType": "Void",
  "reason": "Duplicate order"
}
'@

$response = Invoke-RestMethod -Method POST -Uri '{{BASE_URL}}/api/transactions/{id}/operations' `
    -Headers $headers -ContentType 'application/json' -Body $body
```

#### TypeScript (SDK)

```bash
npm install @winkpg/winkpg-api
```

```typescript
import { Configuration, TransactionsApi } from '@winkpg/winkpg-api';

const api = new TransactionsApi(new Configuration({
  basePath: '{{BASE_URL}}',
  apiKey: '{{API_KEY}}',
}));

const { data } = await api.transactionOperationsExecuteOperationLegacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", {
  "operationType": "Void",
  "reason": "Duplicate order"
});
```

#### TypeScript (raw HTTP)

```typescript
const response = await fetch('{{BASE_URL}}/api/transactions/{id}/operations', {
  method: 'POST',
  headers: {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "operationType": "Void",
    "reason": "Duplicate order"
  }),
});

const data = await response.json();
```

#### C# (SDK)

```bash
dotnet add package WinkPg.Api.Client
```

```csharp
using WinkPg.Api.Client.Api;
using WinkPg.Api.Client.Client;
using System.Text.Json;

var config = new Configuration { BasePath = "{{BASE_URL}}" };
config.AddApiKey("api-key", "{{API_KEY}}");

var api = new TransactionsApi(config);
var body = JsonSerializer.Deserialize<ExecuteTransactionOperationInput>("""
    {
      "operationType": "Void",
      "reason": "Duplicate order"
    }
    """);

var result = await api.TransactionOperationsExecuteOperationLegacyAsync(Guid.Parse("3fa85f64-5717-4562-b3fc-2c963f66afa6"), body);
```

#### C# (raw HTTP)

```csharp
using System.Text;

using var http = new HttpClient { BaseAddress = new Uri("{{BASE_URL}}") };

var request = new HttpRequestMessage(new HttpMethod("POST"), "/api/transactions/{id}/operations");
request.Headers.Add("api-key", "{{API_KEY}}");

request.Content = new StringContent("""
    {
      "operationType": "Void",
      "reason": "Duplicate order"
    }
    """, Encoding.UTF8, "application/json");

var response = await http.SendAsync(request);
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsStringAsync();
```

#### Python (SDK)

```bash
pip install winkpg-api
```

```python
import winkpg_api

configuration = winkpg_api.Configuration(host="{{BASE_URL}}")
configuration.api_key["ApiKey"] = "{{API_KEY}}"

with winkpg_api.ApiClient(configuration) as client:
    api = winkpg_api.TransactionsApi(client)
    body = winkpg_api.ExecuteTransactionOperationInput.from_dict({
      "operationType": "Void",
      "reason": "Duplicate order"
    })
    result = api.transaction_operations_execute_operation_legacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", body)
```

#### Python (raw HTTP)

```bash
pip install requests
```

```python
import requests

headers = {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
}

body = {
  "operationType": "Void",
  "reason": "Duplicate order"
}

response = requests.request(
    "POST",
    "{{BASE_URL}}/api/transactions/{id}/operations",
    headers=headers,
    json=body,
)
response.raise_for_status()
data = response.json()
```

### Refund part of a settled sale

Returns part of a settled sale (settleData.settlementStatus reads SettlementSucceeded) to the card or bank account it was paid with. Put the sale's id in the route. The refund is a new Return transaction linked to the sale, for the amount sent, and its id comes back as newTransactionId. Send an explicit amount on every refund after the first: an omitted amount asks for the sale's whole total. The idempotency key makes a retry after a timeout return the original outcome instead of a second refund.

#### cURL

```bash
curl -X POST "{{BASE_URL}}/api/transactions/{id}/operations" \
  -H "api-key: {{API_KEY}}" \
  -H "Content-Type: application/json" \
  -d '{
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}'
```

#### PowerShell

```powershell
$headers = @{
    'api-key' = '{{API_KEY}}'
}

$body = @'
{
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}
'@

$response = Invoke-RestMethod -Method POST -Uri '{{BASE_URL}}/api/transactions/{id}/operations' `
    -Headers $headers -ContentType 'application/json' -Body $body
```

#### TypeScript (SDK)

```bash
npm install @winkpg/winkpg-api
```

```typescript
import { Configuration, TransactionsApi } from '@winkpg/winkpg-api';

const api = new TransactionsApi(new Configuration({
  basePath: '{{BASE_URL}}',
  apiKey: '{{API_KEY}}',
}));

const { data } = await api.transactionOperationsExecuteOperationLegacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", {
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
});
```

#### TypeScript (raw HTTP)

```typescript
const response = await fetch('{{BASE_URL}}/api/transactions/{id}/operations', {
  method: 'POST',
  headers: {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "operationType": "Refund",
    "amount": 4,
    "reason": "Returned one item",
    "idempotencyKey": "order-4471-refund-1"
  }),
});

const data = await response.json();
```

#### C# (SDK)

```bash
dotnet add package WinkPg.Api.Client
```

```csharp
using WinkPg.Api.Client.Api;
using WinkPg.Api.Client.Client;
using System.Text.Json;

var config = new Configuration { BasePath = "{{BASE_URL}}" };
config.AddApiKey("api-key", "{{API_KEY}}");

var api = new TransactionsApi(config);
var body = JsonSerializer.Deserialize<ExecuteTransactionOperationInput>("""
    {
      "operationType": "Refund",
      "amount": 4,
      "reason": "Returned one item",
      "idempotencyKey": "order-4471-refund-1"
    }
    """);

var result = await api.TransactionOperationsExecuteOperationLegacyAsync(Guid.Parse("3fa85f64-5717-4562-b3fc-2c963f66afa6"), body);
```

#### C# (raw HTTP)

```csharp
using System.Text;

using var http = new HttpClient { BaseAddress = new Uri("{{BASE_URL}}") };

var request = new HttpRequestMessage(new HttpMethod("POST"), "/api/transactions/{id}/operations");
request.Headers.Add("api-key", "{{API_KEY}}");

request.Content = new StringContent("""
    {
      "operationType": "Refund",
      "amount": 4,
      "reason": "Returned one item",
      "idempotencyKey": "order-4471-refund-1"
    }
    """, Encoding.UTF8, "application/json");

var response = await http.SendAsync(request);
response.EnsureSuccessStatusCode();
var json = await response.Content.ReadAsStringAsync();
```

#### Python (SDK)

```bash
pip install winkpg-api
```

```python
import winkpg_api

configuration = winkpg_api.Configuration(host="{{BASE_URL}}")
configuration.api_key["ApiKey"] = "{{API_KEY}}"

with winkpg_api.ApiClient(configuration) as client:
    api = winkpg_api.TransactionsApi(client)
    body = winkpg_api.ExecuteTransactionOperationInput.from_dict({
      "operationType": "Refund",
      "amount": 4,
      "reason": "Returned one item",
      "idempotencyKey": "order-4471-refund-1"
    })
    result = api.transaction_operations_execute_operation_legacy("3fa85f64-5717-4562-b3fc-2c963f66afa6", body)
```

#### Python (raw HTTP)

```bash
pip install requests
```

```python
import requests

headers = {
    "api-key": "{{API_KEY}}",
    "Content-Type": "application/json",
}

body = {
  "operationType": "Refund",
  "amount": 4,
  "reason": "Returned one item",
  "idempotencyKey": "order-4471-refund-1"
}

response = requests.request(
    "POST",
    "{{BASE_URL}}/api/transactions/{id}/operations",
    headers=headers,
    json=body,
)
response.raise_for_status()
data = response.json()
```

## See also

- [All documentation](https://devportal.demo.winkpg.io/llms.txt): the machine-readable index of every public page on this site.