Field reference
This page is a lookup reference, not a tutorial. It exists because a coverage check of this documentation site found 272 distinct field names inside JSON/GraphQL code samples, and 149 of them were never once explained in surrounding prose; a reader could see the field in an example response and have no way to learn what it does, whether it's safe to set, or what values it accepts.
Every field below is grouped by what it does. Each row states, as precisely as the source material allows, what the field means and where that understanding comes from. Where the docs simply don't say (which is most of this page) the row is marked FACT-NEEDED instead of guessing. A guess about a field that moves money is worse than an honest blank, so treat every FACT-NEEDED row as unsafe to rely on until Deal Engine confirms it, especially in the money-flags table below.
How to report a field that's still missing or wrong: open a ticket via Support (or email [email protected] with [Escalation] if it's blocking you), and reference this page and the field name. See Submitting a support ticket for the walkthrough.
1. Money & routing flags: read before you set these
These ten fields change where a refund goes or whether it moves at all. None of them has a definition anywhere else in this documentation. Where a field appears only as a value echoed back in a response (not as a documented input), that is stated explicitly; do not assume you can set it just because you can see it.
| Field | Operation / where seen | Type | Default | What it changes | Risk if wrong |
|---|---|---|---|---|---|
overrideRefundRoute | Only seen as a response field on createQuote's refundCandidate (FAQ/api-usage-integration.md:105, value "GDS"). Compare the plain refundRoute field, which is documented as client-updatable via updateQuote's {from,to} list (Functional/faq.md:300). | String, enum-like (only "GDS" ever shown) | unconfirmed | Refund routing decides which channel actually issues the refund (GDS vs. BSP vs. direct airline). Whether overrideRefundRoute is itself settable, or is purely the engine reporting which route it used, is not shown anywhere. | Wrong routing can send a refund through the wrong settlement channel or fail outright. Do not assume you can set this field until Deal Engine confirms an input path exists. |
overrideBaseFareSegments | updateQuote, inside quoteUpdateRequest's {from,to} optional-field list (Functional/faq.md:288, both null) | unconfirmed | null/null in the only example | Name suggests overriding which segments' base fare feeds the refund calculation. No example ever shows a non-null value, so there's no evidence of its shape or accepted values. | This is the single riskiest blank cell on this page: a field that appears to let a caller substitute which segments' fares are refunded, with zero documented shape, examples, or guardrails. |
overrideTaxCalculations | Appears twice: as a createQuote response field on refundCandidate (FAQ/api-usage-integration.md:109, value false) and as an updateQuote {from,to} input (Functional/faq.md:292) | Boolean | false (per the response sample) | Name suggests bypassing or overriding the engine's own tax computation for the refund. Whether true means "a manual tax override is in effect" or "recompute taxes" is not stated. | Directly affects the tax portion of the refund amount, and potentially what's remitted to tax authorities. |
waiverForceFareRefundWithoutPenalty | Same dual appearance: createQuote response (FAQ/api-usage-integration.md:108, value true) and updateQuote {from,to} input (Functional/faq.md:337) | Boolean | unconfirmed | Name strongly suggests: when true, the fare is refunded in full without the penalty fare rules would normally apply; tied to a granted waiver (waiver is described elsewhere only as "exception granted by the airline that overrides normal rules or penalties," FAQ/api-usage-integration.md:48). Whether it requires a non-null waiver value to take effect is not stated. | This flag, read plainly, removes a penalty deduction from the refund total. Setting it true without a genuine waiver could refund money fare rules say should be withheld. |
refundMode | processRefund, inside fulfillmentRequest input (FAQ/api-usage-integration.md:579, shown as null) | unconfirmed | shown as null | No enum values or description appear anywhere. | Could select the refund's processing path (e.g., automatic vs. manual, full vs. partial). An unconfirmed value should not be set to anything other than null/omitted until documented. |
refundType | createQuote response, refundCandidate.refundType (FAQ/api-usage-integration.md:103, only value ever shown: "FULL FARE REFUND") | String, enum-like | n/a; only ever seen as an output | Only one value has ever been observed in these docs. No other enum members, and no input example anywhere shows a caller setting it. | If this is purely computed, there's no direct risk from a client. If it turns out to be settable, treat it as unconfirmed until proven otherwise; do not assume "FULL FARE REFUND" is the only or default option. |
testingMode | processRefund, inside fulfillmentRequest input (FAQ/api-usage-integration.md:580, shown as null) | unconfirmed, likely Boolean | shown as null | This is the only field anywhere in the docs that looks like it could let a caller force a specific outcome for QA purposes. Testing & environments and the legacy FAQ (Functional/faq.md:589-595) both describe a sandbox that can "simulate various outcomes" (success, rejection, timeout/error), but neither names the mechanism. It is plausible testingMode is that mechanism, but this is my inference connecting two separate pieces of evidence, not a confirmed fact. | If QA has no other documented way to force outcomes, this field is important, but until confirmed, do not assume setting it is safe in any environment, including sandbox. If it has any effect in production, an accidental non-null value here could suppress a real refund while looking like it succeeded, or vice versa. |
shouldCancelItinerary | Dual: createQuote response (FAQ/api-usage-integration.md:110, value false) and updateQuote {from,to} input (Functional/faq.md:308) | Boolean | false (per sample) | Name suggests whether the refund also cancels the underlying itinerary/PNR segments, versus refunding money while leaving the booking intact. | Setting this wrong in either direction has a real-world effect beyond money: true when not intended could cancel active flight segments; false when cancellation was expected could leave a refunded ticket's segments active, risking reuse. |
refundPartialSegments | Seen inside createQuote's response, both in extraParams.refundability and the top-level refundability block (FAQ/api-usage-integration.md:122 and :385, both false). No input example anywhere shows a caller setting it. | Boolean | false (in samples) | Name suggests whether a refund can proceed for only some segments of a multi-segment itinerary rather than requiring all segments to qualify. | If settable, a wrong value could authorize a partial refund when a full one was expected, or block a legitimate partial refund. Until an input path is confirmed, treat as read-only. |
isGuaranteedRefund | createQuote response, refundCandidate.isGuaranteedRefund (FAQ/api-usage-integration.md:104, value false) | Boolean | n/a; only ever seen as an output | Name, read against Refund amounts & reconciliation (which explains the PSS can recalculate taxes/penalties at execution time, so quote and executed amounts can differ), suggests this flag marks whether a given quote's amount is locked against that recalculation. This is a plausible reading of the field name plus adjacent documented behavior; not a confirmed definition. | If a caller (or a downstream team) treats a refund as guaranteed when the flag doesn't actually mean that, they could commit to an exact amount with a customer before the PSS has finalized it. |
2. Engine internals a reader can't otherwise discover
These fields expose how the refund engine actually reasons about a ticket. They appear only inside the createQuote synchronous response sample (FAQ/api-usage-integration.md:87-395).
2.1 The extraParams container is overloaded: check nesting level
extraParams container is overloaded: check nesting levelextraParams appears at five different nesting levels in the same response sample, and means something different at each one. There is no prose anywhere explaining this; the overload is visible only by reading the sample closely:
| Location | Line(s) | What it holds |
|---|---|---|
refundCandidate.extraParams | FAQ/api-usage-integration.md:111-199 | The engine's own working data for the whole candidate: currentDate, refundReason, the refundability decision block, fareBreakdown, penaltyBreakdown, per-segment detail, lineageCount, safeBadge, autogenNotes |
segment.extraParams (inside extraParams.segments[]) | :167-191 | Per-segment FX detail: roe, isNoShow, currencyExchangeDetails, currencyExchange, originalCurrencyExchange |
refundCandidateCoupons[].extraParams | :207-248 | Per-coupon geography/FX: isOpen, IATA area/country/city fields, alternativeOrigins/alternativeDestinations, FX detail |
refundCandidateTaxes[].extraParams | :266-268, :284-298 | Per-tax-line detail: originalRemit, and (only on some lines) the explanation block (below) |
clientData.extraParams in the request shape (Functional/faq.md:147) | shown as null | Unconfirmed; no description or non-null example. |
Practical note: if you're trying to find a field like isOpen or roe, first identify which extraParams block you're inside; the same key name recurs with unrelated meanings.
2.2 The explanation / reconciliation block
explanation / reconciliation blockFound only on some tax lines in refundCandidateTaxes[].extraParams.explanation (FAQ/api-usage-integration.md:284-298, :314-328, :344-358), not on every tax line, and never on segments or coupons.
| Field | Meaning | Notes |
|---|---|---|
explanation | Wrapper object present only when the engine adjusted an amount for this tax line. | Its absence (as on the first tax line in the sample, :251-269) appears to mean no adjustment was made, but this is inferred from the sample, not stated. |
source | Always "RUDDER_TS" in every example. | Reads as the name of an internal rules/reconciliation engine ("Rudder"). Also appears as refundability.invokeRudder (§2.3) and as currencyExchangeDetails.source: "gds" in a different, unrelated source field one level up; don't confuse the two. |
adjustments | Array of reconciliation actions taken on this line. | Every example has exactly one entry. |
adjustments[].type | Only observed value: "AMOUNT_RECONCILIATION". | No other type ever appears in these docs. |
adjustments[].reason | Only observed value: "Adjusted to match input sums". | Free text; likely other reasons exist but none are documented. |
ruleId | A numeric-looking string ID (e.g. "48398136") unique per adjustment. | No lookup or meaning is given for what a ruleId refers to. |
segmentIdxAtSource / couponIdxAtSource | Same shape as segmentIdx/couponIdx (see §3) but explicitly labeled "at source." | Read together with §3 below; these are the reconciliation engine's own indices, which may differ from the ones the API returns to you. |
2.3 Refundability / safety signals
| Field | Where seen | Meaning | Notes |
|---|---|---|---|
isSafeForRefund | Top level of createQuote's per-ticket result (FAQ/api-usage-integration.md:390) | Name suggests an overall verdict on whether it's safe to submit this candidate to processRefund. | Distinct from safeBadge (below); the docs never explain how the two relate, or whether one supersedes the other. |
safeBadge | Inside refundCandidate.extraParams (:197) | Also reads as a safety indicator, but nested inside the engine's internal extraParams rather than at top level like isSafeForRefund. | See above; unconfirmed whether this is meant for clients to act on, or is internal-only. |
willRefund | Per tax line, inside refundCandidateTaxes[] (e.g. :263) and inside updateQuote's taxes[].willRefund {from,to} override (Functional/faq.md:323-326) | Whether this specific tax line will be included in the refund. | Confirmed client-settable on updateQuote (the {from,to} envelope proves it can be overridden), unlike most fields in this table. |
isValid | Per tax line (:262, etc.) | Always true in every example; no example shows false, so the failure case is undocumented. | |
isRefundable | Per tax line (:264, etc.) | Whether this tax is refundable at all, independent of whether it will be refunded (willRefund). | The distinction between isRefundable (can be) and willRefund (will be) is inferred from having both fields present with the same value in every example; never observed to differ, so the case where they diverge is undocumented. |
segmentIsRefundable | Per tax line (:258, etc.) | Same concept as isRefundable, but scoped to the segment rather than the tax line. | |
isOpen | Per tax line and per coupon (:265, :208) | Reads as "coupon/tax status is OPEN"; consistent with the coupon-status table in Refund lifecycle & statuses, where O/open is one of the normalized statuses. | Plausible cross-reference, not confirmed by prose naming this exact field. |
isNoShow | Inside segment.extraParams (:169) | Whether the passenger was a no-show for this segment. | Industry-standard concept (no-show fares/penalties differ), but Deal Engine's exact use of the flag isn't documented. |
lineageCount | Inside refundCandidate.extraParams (:195, value 0) | Plausibly the number of tickets in a reissue/exchange chain; Request parameters documents parentTicketNum/conjunctionTicketNum as tracking exactly this kind of chain. | Connection to the reissue-chain concept is my inference from adjacent documented fields, not a stated definition. |
invokeRudder | Inside refundability (:118, :381) | Boolean flag, presumably controlling whether the "Rudder" reconciliation engine (see source: RUDDER_TS above) runs for this candidate. | |
autogenNotes | Inside refundCandidate.extraParams (:198) | Presumably auto-generated free-text notes about how the quote was computed. | In the only example, the value is a single invisible/zero-width character; so even the shape of real content is unconfirmed. |
exceptionRule | createQuote request, inside clientData (Functional/faq.md:146, shown null) | Sits next to exception (also null at :145); the docs never define either. Note: the coverage checker considers exception "documented" only because the unrelated sentence "waiver: exception granted by the airline…" (FAQ/api-usage-integration.md:48) happens to contain the word; that sentence is about waiver, not this field. Treat exception as equally undocumented in practice. |
3. Identity & context fields
Several field pairs look interchangeable but are not; using the wrong one of a pair silently points at the wrong record.
| Field | Appears on | Meaning | Notes |
|---|---|---|---|
couponIdx | refundCandidateCoupons[], refundCandidateTaxes[] (e.g. FAQ/api-usage-integration.md:204, 255) | Index of the coupon as returned to the API caller. | |
couponIdxAtSource | Only inside extraParams.explanation on tax lines (:295, 325, 355) | Index of the same coupon at the reconciliation source (Rudder; see §2.2). | In every example in these docs the two values are identical (both 1), so no evidence yet shows them differing, but the API models them as separate fields, implying they can. |
segmentIdx | extraParams.segments[], refundCandidateTaxes[] (:146, 254) | Index of the segment as returned to the API caller. | |
segmentIdxAtSource | Only inside extraParams.explanation (:294, 324, 354) | Same segment's index at the reconciliation source. | Same caveat as couponIdxAtSource above. |
marketingAirlineCode | Per segment (:165) | The airline code marketing the flight (as opposed to the operating carrier, which isn't shown in any sample). | Standard industry concept (marketing vs. operating carrier); Deal Engine's exact usage isn't spelled out. |
gds (for contrast) | quoteRequest, Document/Request ownership context (FAQ/api-usage-integration.md:43, Schema/what-is-a-request.md:28) | Already documented elsewhere: "global network that distributes travel inventory and enables real-time booking." Included here only for contrast with the fields below. | |
travelAgencyId (for contrast) | Request "Ownership & channel" (Schema/what-is-a-request.md:28) | Listed, not defined beyond the bullet heading. | Not in the undocumented-field list (the word appears in that prose bullet), but it has no real definition either; borderline case. |
commissionPercent | Document "Financials" bullet (Schema/what-is-a-document.md:30), updateQuote {from,to} input (Functional/faq.md:218), documents query (FAQ/api-usage-integration.md:676) | Listed as a financial field on a Document; no numeric format (percentage 0-100 vs. 0-1) or computation is given. | |
usdot | Inside refundability (FAQ/api-usage-integration.md:124, 387) | Reads as a US Department of Transportation rule flag (US DOT has specific refund-rights regulations for flights touching the US). | Plausible from the name and the airline-refund domain, not explained in prose. |
roe | Inside segment.extraParams (:168, value "0.883723") | Rate of Exchange; matches the adjacent currencyExchangeDetails.rate value (0.883723) exactly in the sample, so this is very likely the same FX rate exposed under its industry abbreviation. | High-confidence inference from matching values in the same sample, but the field is never named in prose. |
4. Everything else, grouped
4.1 Passenger / customer identity (clientData on createQuote)
clientData on createQuote)All from Functional/faq.md:140-166, the clientData sub-object of quoteRequest. None of these have descriptions beyond the field name; the operation and shape are confirmed, the meaning is name-inference only.
| Field | Meaning (inferred from name) |
|---|---|
firstName, lastName, middleName, secondLastName | Passenger name parts. secondLastName suggests Spanish/Latin-American two-surname convention support. |
frequentFlyerNumber | Passenger's loyalty program number. |
identityDocument | Passenger ID document (passport, national ID); also appears as an updateQuote {from,to} field (Functional/faq.md:256). |
activeReserve | |
emailReservation | Likely the reservation contact email. |
feeAmount, feeCurrency, feeEmd, feeFop, feeIndicator, feePaymentdate | A fee sub-record (amount, currency, related EMD, form of payment, an indicator flag, and payment date) attached to the client/quote request. |
isTicket | Boolean, purpose unconfirmed. |
subChannel | Booking sub-channel, distinct from channel (also present, undefined). |
requestDate | Presumably when this client-side request was made; compare refundRequestDate/refundRequestedAt below, which are distinct, documented-by-name-only fields on the outer quoteRequest. |
4.2 Quote-request fields outside clientData
clientDataStill on createQuote's quoteRequest (Functional/faq.md:167-181), sibling to clientData:
| Field | Meaning |
|---|---|
refundRequestDate | Date the refund was requested; listed in the documented optional-fields bullet list at FAQ/api-usage-integration.md:46 ("date refund was requested"), so this one has a definition. |
refundRequestedAt | Timestamp variant of the above, also documented at :47 ("timestamp when the refund request was logged in the system"). |
metadata | Documented generically at FAQ/api-usage-integration.md:51 ("data that describes other data"); i.e., a free-form passthrough field, no fixed shape given. |
reissue | Boolean; presumably flags a reissued ticket. Ties to isReissue mentioned on Document (Schema/what-is-a-document.md:32) and to the reissue-chain fields in Request parameters. |
fetchFromGDSis not a client parameter. It exists for Deal Engine's own development and load testing: it quotes a ticket without fetching PSS information when every input is already supplied. It is not part of a normal integration; omit it.
4.3 updateQuote optional fields (the {from, to} envelope)
updateQuote optional fields (the {from, to} envelope)From Functional/faq.md:206-341. All use the { "from": ..., "to": ... } shape described generically at FAQ/api-usage-integration.md:416; none has an individual description beyond its name.
| Field | Meaning (inferred) |
|---|---|
attachments | Files attached to the request/document; see createUploadUrl in §4.9 for the likely upload mechanism, though no doc links the two explicitly. |
clientVisibility | Presumably controls whether a field/record is visible to the client-facing side. |
emd, emdIssueDate | An EMD (Electronic Miscellaneous Document) reference and its issue date; distinct from the isEmd routing hint flag, which is thoroughly documented in Request parameters. These two (emd/emdIssueDate) are not covered by that explanation. |
endorsement | Ticket endorsement text/restriction; standard airline-ticketing term, not Deal-Engine-specific meaning given. |
identityDocument | See §4.1. |
isAdminFeeApplicable | Whether an admin fee applies to this refund; also appears as a createQuote response field (FAQ/api-usage-integration.md:96, true). No amount or computation shown. |
isQuotationOk | Reads as a quote-validity flag. |
isVoluntaryRefund | Whether the refund is voluntary; consistent with the documented decision values in Refund lifecycle & statuses (VOLUNTARY vs INVOLUNTARY), though this exact field is never tied to that table in prose. |
notes, operatorNotes, remark | Three separate free-text fields with no stated distinction between them. |
osi | Standard PNR term (Other Service Information); industry meaning, not confirmed as used identically here. |
refundCandidateStatus | The mechanism for moving a candidate between the client-settable statuses REVIEW and READY; see Refund lifecycle & statuses §2. Clients never set REFUNDED or ERROR. |
refundRoute | See §1's overrideRefundRoute comparison; this plain version is the one shown as client-updatable. |
ssr | Special Service Request; standard PNR term. |
taxes[].amount, taxes[].code, taxes[].willRefund | Per-tax override list; willRefund is covered in §2.3. amount/code are self-evident (tax amount, tax code) but never formally defined. |
waiver (value shape) | The waiver mechanics (requote interaction) are the best-documented part of this whole file; see API usage & integration §3.2.2. |
waiverCode | Distinct from waiver itself; presumably a short code identifying which waiver was applied. |
overrideBaseFareSegments, overrideTaxCalculations, shouldCancelItinerary, waiverForceFareRefundWithoutPenalty | See §1; these are the money flags, repeated here only because they live in the same {from,to} list. |
4.4 Fare, tax & penalty breakdown
From refundCandidate.extraParams.fareBreakdown and .penaltyBreakdown (FAQ/api-usage-integration.md:127-143), and refundCandidateFulfillment (:361-376). Refund amounts & reconciliation documents a different, overlapping set of fields on these same objects (refundAmount, fareToRefund, taxesToRefund, fareRulePenalty, vatOnPenalty, serviceFee, totalRefundAmount); the fields below sit alongside those documented ones but are not covered by that page.
| Field | Object | Meaning (inferred from name) |
|---|---|---|
totalPaidFare | fareBreakdown | Total fare originally paid, before any refund logic. |
openFare | fareBreakdown | Portion of the fare still "open" (unused segments); consistent with the O/open coupon status in the lifecycle doc. |
usedFare | fareBreakdown, refundCandidateFulfillment | Portion of the fare already used/flown. |
nonRefundableFare | fareBreakdown, refundCandidateFulfillment | Fare portion not eligible for refund. Compare non_refundable_fare in §5; same concept, different casing, different object. |
refundableFare | fareBreakdown | Fare portion eligible for refund. |
totalPenaltyAmount | fareBreakdown | Total penalty withheld, computed inside fareBreakdown. Distinct from refundPenaltyAmount (top-level on refundCandidate, documented in the reconciliation page) and from totalPenalties below; three differently-named penalty totals appear across this one response. |
totalPenalties | refundCandidateFulfillment | Same value (60) as totalPenaltyAmount and refundPenaltyAmount in the one example available, but nothing confirms they always agree. |
totalTaxes, usedTaxes, nonRefundableTaxes | refundCandidateFulfillment | Tax-side counterparts to the fare fields above: total, already-used, and non-refundable tax amounts. |
fareBasis | per segment (:161) | Industry term: the fare basis code identifying the fare product for that segment. Not redefined for Deal Engine's specific use. |
4.5 Segment & routing / geography
Per-segment fields (extraParams.segments[], :144-193) and per-coupon geography fields (refundCandidateCoupons[].extraParams, :207-248).
| Field | Meaning |
|---|---|
destination, originCountry, destinationCountry | Segment-level route: destination airport/city code and the ISO-style country of origin/destination. |
stopovers, stopoversCountries | List of stopover points and the countries they're in for this segment. Empty in every example. |
departedAt | Segment departure timestamp. |
segmentStatus | Segment-level status string; appears to feed from the same normalized coupon-status vocabulary in Refund lifecycle & statuses §3 (OPEN in every example), though not explicitly tied to that table in prose. |
couponIdxs, couponStatuses | Parallel arrays: which coupon indices belong to this segment, and their statuses; same status vocabulary as above. |
iataAreaOrigin, iataAreaDestination | IATA traffic conference area codes (e.g., "2") for the coupon's origin/destination; industry-standard geography grouping, not redefined here. |
countryAreaOrigin, countryAreaDestination | Broader area name (e.g., "EUROPE") for origin/destination country. |
countryOfOrigin, countryOfOriginName, countryOfDestination, countryOfDestinationName | ISO country code and full name pairs for the coupon's origin/destination. |
cityIataCodeOrigin, cityIataCodeDestination | City-level IATA code (may differ from the airport code, e.g. metro-area codes). |
alternativeOrigins, alternativeDestinations | Lists of alternate airport/city codes considered equivalent to the origin/destination (e.g. ["CDG","PAR"]). |
4.6 Currency & FX
Recur at multiple nesting levels (segment and coupon extraParams, :170-190, :211-247).
| Field | Meaning |
|---|---|
currencyExchange | The converted amount + currency actually used. |
currencyExchangeDetails | Full FX detail: input (amount + currency before conversion), output (after), rate, date, source. |
originalCurrencyExchange | The pre-conversion amount + currency; appears to duplicate currencyExchangeDetails.input in every example; no stated reason for both to exist. |
originalRemit | Per tax line (:267, 297); a remittance description string (e.g. "fare complement", "transporting"). Compare remittance (documented nowhere either, same values). |
4.7 Dates & identifiers on the refund record / Document
DocumentFrom the documents query sample (FAQ/api-usage-integration.md:669-708).
| Field | Meaning |
|---|---|
authorizationDate | Presumably when the refund was authorized (as distinct from requested or executed), not defined relative to the other lifecycle dates in Refund lifecycle & statuses. |
rejectionDate | Date a refund was rejected; pairs with the REJECTED/rejection-note behavior documented in Refund lifecycle & statuses §4.2, though the field itself isn't named there. |
updatedDate | Generic last-updated timestamp on the executed refund record. |
currentDate | Inside refundCandidate.extraParams (:112); a Unix-millisecond timestamp, presumably when the quote was computed. |
quantity | Inside documents.quote.taxInfo.refundAmount.quantity (:683); sits next to currencyCode, so this is almost certainly the numeric refund amount for that tax, under an unusual name (quantity rather than amount). |
4.8 Filters, pagination & list operators
These are instances of a documented pattern, not undocumented mechanisms; GraphQL conventions documents the _contains, _in, etc. operator suffixes generically. They're listed here only because the checker flags the literal compound field name.
| Field | Operation | Meaning |
|---|---|---|
id_in | documents/quotes filters (FAQ/bi-reporting.md:43) | id field + the documented _in operator: match any ID in a list. |
pnr_contains | Same filters (:49) | pnr + documented _contains: substring match on PNR. |
status_in | Same filters (:55) | status + _in: match any of several statuses. |
ticketNum_contains | documents filter (Schema/what-is-a-document.md:70, GraphQL/common-practices.md:79) | ticketNum + _contains. |
roleFilter | roles query (FAQ/api-usage-integration.md:467) | The filter input object for the roles list query; same pagination/filter pattern as documents. |
nextToken | Webhook event history pagination (Functional/webhooks/deal-engine-webhook-api-reference.md:302-358) | Opaque pagination token, distinct from the limit/offset pattern used elsewhere; this API uses token-based paging instead. |
items | Webhook event history (Functional/webhooks/deal-engine-webhook-api-reference.md:302-358) | The array of result records under webhookEvents. |
locations | GraphQL error objects (FAQ/authentication-authorization.md:42) | Standard GraphQL spec field: line/column of the error in the query document. Not Deal-Engine-specific. |
4.9 Webhook configuration
From the Webhook API reference. Unlike most of this page, these fields are explained, but only via inline # comments inside GraphQL code fences and "Input Fields" tables, which the coverage checker doesn't count as prose (fenced-block comments get stripped along with the code). Meanings below are taken directly from that file, not inferred.
| Field | Meaning | Source |
|---|---|---|
apiConfig | Webhook authentication configuration (header name, secret reference, auth type). | :94-104 |
webhookFullConfig | Query returning the complete webhook configuration (auth + event subscriptions) for the account. | :119-128, 166-185 |
webhookEventTypes | Query listing all event types available to subscribe to. | :210-221 |
updateWebhookApiConfig | Admin-only mutation to set webhook auth settings. | :378-398 |
addWebhookEvent | Admin-only mutation to subscribe to an event type at a URL. | :461-480 |
deleteWebhookEvent | Admin-only mutation to remove an event subscription by uuid. | :506-514 |
responseCode | HTTP status code returned by the client's endpoint for a given delivery attempt. | :147, 309, 353 |
4.10 File upload & misc
| Field | Meaning |
|---|---|
uploadUrl, objectKey, expiresAt | Returned by createUploadUrl (GraphQL/common-practices.md:133-139): a presigned upload URL, the storage key to reference the uploaded object afterward, and when the URL expires. No description beyond the example, not explicitly linked to the attachments field in §4.3, though that's the likely use. |
mcpServers | Client-side MCP configuration key (AI/mcp.md:28-62), not a Deal Engine API field at all; it's the config schema of Cursor/Windsurf/Claude Desktop's own MCP client. Included here only because it matched the coverage checker's code-fence scan. |
roundDigits | Inside refundability (FAQ/api-usage-integration.md:123, 386, value 2); presumably how many decimal places refund amounts are rounded to. |
buildSegments, fetchFareRules, useFareRules | Inside refundability; boolean flags, presumably controlling internal quoting steps (segment construction, fare-rule fetch/use). |
taxCode | Per tax line (the tax code (e.g. "YQ", "FR")) industry-standard IATA tax codes, not redefined here. |
remittance | Per tax line; free-text remittance category ("fare complement", "transporting"). See §4.6 for its relationship to originalRemit. |
5. Shape defects worth flagging
These aren't missing definitions; they're inconsistencies in the documentation itself that make the fields harder to trust.
processFulfillmentRequest has no real example. The processRefund mutation's input type, processFulfillmentRequest, appears exactly once in these docs, and every field in it is null (FAQ/api-usage-integration.md:569-587). There is no example anywhere showing what a populated fulfillmentRequest looks like with real values, which means every field inside it (including the money flags refundMode and testingMode) has never been shown actually doing anything.
Casing inconsistencies:
isRequote(oncreateQuote,FAQ/api-usage-integration.md:18) vs.requote(onupdateQuote, used and exampled repeatedly,:402-442). These are parameters on two different mutations, so they may legitimately be separate fields rather than a casing bug, butisRequoteis never shown in an example, never explained, and its relationship torequote's well-documented semantics (settruefor a material change like adding/removing a waiver) is never stated.
snake_case fields sitting among camelCase ones. The GraphQL API is camelCase throughout with one exception: the contents of refundCandidate.extraParams.penaltyBreakdown (FAQ/api-usage-integration.md:135-143), which uses currency_code, fare_rules, non_refundable_fare, fixed_fees, vat_fees, admin_fees, historical_pricing_fee; all snake_case, in a response that otherwise uses currencyCode, nonRefundableFare (see §4.4), etc. everywhere else, including one line away in the sibling fareBreakdown object.
Separately, webhook payloads are not GraphQL and follow their own casing: the default delivery payload is snake_case (ticket_num), while the custom-payload field list is camelCase (ticketNum). That split is documented on the webhook API reference and is unresolved there too; do not assume the GraphQL casing rule above applies to delivered events.
The penaltyBreakdown split above is either (a) a real, separate part of the schema that genuinely uses snake_case; possibly sourced from a different internal system than the rest of the response, or (b) a documentation error where someone hand-typed this example and slipped into snake_case by habit. Given that currency_code and currencyCode appear four lines apart describing what looks like the same concept (a currency code), and non_refundable_fare duplicates the camelCase nonRefundableFare one object over, the doc-error explanation is at least as plausible as a genuine schema split; do not assume your GraphQL client should send snake_case fields based on this example alone; verify against your schema introspection first.
Updated about 18 hours ago
Did this page help you?