Types

Get all possible journeys between origin and destination on given date

See: https://docs.allaboard.eu/tickets/

This will check live availablity with the train operators and return the given journey with priced offers. Call this when the user has requested prices.

See: https://docs.allaboard.eu/tickets/journey-offer

This will check live availablity for an outbound and an inbound journey priced together as a round trip. Where a provider sells true return fares they surface in the matched legs' offers; otherwise prices match two independent journeyOffer calls.

See: https://docs.allaboard.eu/tickets/journey-offer

This will return a journey constructed from a predefined Blueprint.

Blueprints are created in the Agent Dashboard and can be either a short connection or a multi‑leg trip with overnight stopovers along the way.

See: https://docs.allaboard.eu/blueprints/

Get applicable pass bundles for the given passengers

See: https://docs.allaboard.eu/passes/

Get applicable pass bundles for given journey offer

Get comparative rating for journeys

Get fee for issuing tickets

The orders the caller can see, newest first unless sort says otherwise, optionally narrowed by filter.

Cursors are opaque, so do not parse or construct one, and a cursor only continues the list it came from: present it with the same filter and sort. totalCount counts the orders the filter leaves. Pages hold 10 orders by default and 100 at most.

Every location we can search and book from, optionally narrowed and ordered by filter.

Without filter.query and filter.near the order is ascending on an internal sequence and carries no meaning beyond being stable: it is the order to walk when retrieving all of them. A location that is listed for the whole walk is neither skipped nor repeated, however many are added or withdrawn while it runs. One that joins the list mid-walk is yielded only if it sorts after the cursor reached — and a location that has existed for years can join it, because a location is listed from the day we can sell a journey from it, not from the day the row was created. Repeat the walk to pick those up.

With filter.query the order is relevance, and with filter.near alone it is distance. Those lists are ranked when a page is read, so a location added or withdrawn between two pages can shift the ones after it by a place; they are for finding a location, not for retrieving all of them.

Cursors are opaque, so do not parse or construct one, and a cursor only continues the list it came from: present it with the same filter. totalCount counts the locations the filter leaves. Pages hold 25 locations by default and 100 at most.

Use this query to get anything that implements the Node interface. It's the recommended way to get entities based on their id.

See: https://docs.allaboard.eu/intro/node

Get available travel card options.

Returns the list of supported travel cards that can be attached to passengers. Use the returned code when constructing TravelCardInput and consult inputFields to determine which additional data is needed.

Get sales agent details

The sales agents the caller has been granted access to act on behalf of, never the caller's own agent.

Without filter.query the list is in uid order. With it, the order is relevance, ranked when a page is read, so a sales agent granted or revoked between two pages can shift the ones after it by a place.

Cursors are opaque, so do not parse or construct one, and a cursor only continues the list it came from: present it with the same filter. totalCount counts the sales agents the filter leaves. Pages hold 25 sales agents by default and 100 at most.

Passenger profiles the caller may book for, found by filter.query: an agency's key reaches the profiles of every company it has access to, a company reaches its own.

Requires the passenger_profiles:read scope, else FORBIDDEN. A caller whose sales agent keeps no profile directory gets NO_PROFILE_DIRECTORY; a directory that could not be searched, UPSTREAM_UNAVAILABLE.

Each page is one read of the directory. Pages hold 25 profiles at most, a larger first is read as 25, and a page can hold fewer than asked, or none, while hasNextPage is still true (see PassengerProfileConnection). Cursors are opaque, so do not parse or construct one, and a cursor only continues the search it came from: present it with the same filter and first, else INVALID_ARGUMENT.

Get the authenticated end user.

Requires a user token (JWT) in the Authorization header. A request without one has no end user and fails with the USER_TOKEN_MISSING error code. Note that an api-key header takes precedence over Authorization, so send only the user token when querying this field.

The sales campaigns available to the authenticated caller, ordered by code.

Every code returned is one the caller may sell under, so a client can offer the list as-is. The baseline terms a sale falls back to when no campaign is given are not a campaign to select and are never listed. Campaigns are not named here — a code has no display copy — so pair the codes with your own labels.

A campaign runs for a period and drops out of the listing once it ends, so re-read this rather than caching codes indefinitely. A booking already taken under a campaign is unaffected by its ending and can still be completed.

Which campaigns are available depends on who the request is authenticated as. An api-key header takes precedence over Authorization, so send only the user token (JWT) to list what an end user may sell under.

Get a map of places for a given offer and part

Returns a list of refundable items that can be refunded

List all executed refunds for an order

Given a journey offer id, this will create a booking with the given journey offer. A booking is a temporary entity that holds the selected offers and passenger details.

See: https://docs.allaboard.eu/tickets/book-tickets, https://docs.allaboard.eu/passes/booking

Select offers and update passenger details

Given a booking id and an offer id, this will select the offer in the booking. This is useful when the user has selected an offer and wants to add it to the booking.

Given a booking id and an array of passenger details, this will update the passenger details in the booking. See booking.requirements for required passenger fields. At least one passenger must be marked as the contact person with `isContactPerson: true` and `email` and `tel` must be provided.

Update an offer part of a booking

Set values of the booking's custom fields, by key. Fields not sent keep their values, and if any field is refused, none is saved. Not allowed once the booking's order is paid or confirmed.

Record how the tickets for one offer should be delivered.

Returns the updated offer. Nothing else about the booking changes — no price, no selection, no other field — so there is nothing to refetch beyond the one case below.

One call covers the whole offer: every cost center of a multi-cost-center booking, and both halves of a return whose inward direction is priced into the outward fare. That inward half is a separate Offer with its own id, and it is the only offer other than the returned one that a call can change, so refetch it through the booking if you are displaying it. Its selectedOption takes the same method when that method is among its own availableOptions, and is cleared to null when it is not — a linked half is never left holding a delivery its own options do not list.

Two separately selected single offers are set separately, even when the operator goes on to deliver them together — in that case it settles one delivery for both at purchase.

Initialise payment for an order through All Aboard.

The recommended flow is to first create an order with `createOrder` and then pass its `id` here as `orderId`. Once the payment has been succesfully processed, the user will be redirected to the successUrl with the `{order}` placeholder replaced by the order id. If the payment is canceled, the user will be redirected to the cancelUrl.

For backwards compatibility a `booking` may be passed instead of `orderId`, in which case an order is created automatically before payment is initialised.

See: https://docs.allaboard.eu/payments/

This will create an order from a booking. An order is a temporary entity that holds the selected offers and passenger details and prebooks the tickets.

It is normally after creating an order that you would collect payment.

See: https://docs.allaboard.eu/docs/orders

This will finalize an order and start issuing tickets.

See: https://docs.allaboard.eu/docs/orders

Execute refunds for selected refundable items

Mint an access token for one order.

Returns the token with its secret on token, the only time that value is ever readable. Present it in the api-key header to read that order, and — with WRITE — to refund it and to pay for it by card.

Minting is refused with NOT_AUTHORIZED unless the caller could itself do everything the token is asked for: reading the order for READ, and refunding it and paying for it by card for WRITE. A request authenticated by an access token cannot mint another one, so a token's lifetime cannot be extended by minting from behind it.

An order that does not exist, and one the caller may not read, both fail with NOT_FOUND. Empty restrictions fails with INVALID_RESTRICTIONS, and a ttlSeconds outside 1..86400 with INVALID_TTL.

Revoke an access token, so it stops authenticating anything immediately.

Idempotent: revoking an already-revoked token succeeds and leaves the original revokedAt alone, so the trail keeps saying when the credential actually stopped working.

Allowed for the agency that minted the token, or any agency above it in the agent tree; anything else fails with NOT_AUTHORIZED. An id that names no token fails with NOT_FOUND. The returned token carries token: null — the secret is unreadable here as everywhere else.

Get all possible journeys between origin and destination on given date

Journeys will be streamed as the routing algorithm resolves the best routes.

See: https://docs.allaboard.eu/tickets/

This will check live availablity with the train operators and return the given journey with priced offers. Call this when the user has requested prices.

The response is streamed, meaning that as operators return offers for parts of the journey, the result will update with more data for every payload.

See: https://docs.allaboard.eu/tickets/journey-offer

This will check live availablity for an outbound and an inbound journey priced together as a round trip. Where a provider sells true return fares they surface in the matched legs' offers; otherwise prices match two independent journeyOffer calls.

The response is streamed, updating as each direction's legs resolve.

See: https://docs.allaboard.eu/tickets/journey-offer

This will return a journey constructed from a predefined Blueprint.

Blueprints are created in the Agent Dashboard and can be either a short connection or a multi‑leg trip with overnight stopovers along the way.

The journey is streamed as the blueprint is being resolved into a journey.

See: https://docs.allaboard.eu/blueprints/

A credential that reaches one order and nothing else.

Presented in the api-key header, or as Authorization: Bearer, in place of the agency's own API key — which is what makes it safe to put on a page the public can open. Every request it authenticates is attributed to the agent and user that minted it.

What an access token is narrowed to. See AccessTokenRestrictionsInput.

Accommodation details for a journey segment.

Describes the type of seating or sleeping arrangement available on a train/bus/ferry, including comfort level and specific features. Used to help passengers choose their preferred travel experience.

The description field provides human-readable details about the accommodation (e.g. "1 person sleeper cabin"), while subType contains a standardized code representation of the same information (e.g., "SINGLE").

The admission (tariff) part of an offer.

Represents the right to travel for the covered segments (the fare/tariff). Contains the conditions the operator stated for the ticket and the flexibility level, as well as the normalized serviceClass and (operator-specific) comfortClass.

An ancillary service that can be selected for a reservation.

Additional services or add-ons that passengers can purchase beyond the basic fare. These enhance the travel experience and may include meals, insurance, or special assistance.

Common types and examples:

• "BREAKFAST": On-board breakfast, pre-ordered meals
• "MEAL": On-board dining, pre-ordered meals
• "INSURANCE": Travel insurance, cancellation protection
• "LUGGAGE": Extra baggage allowance, bike transport
• "UPGRADE": Seat upgrades, priority boarding
• "ENTERTAINMENT": WiFi access, entertainment packages

The price field indicates the additional cost, while selections track which passengers have chosen this service.

A selection of an ancillary service

A station where stops may be made but journeys cannot be planned from/to

A bed assignment for a passenger

A journey constructed from a predefined itinerary blueprint.

Uses a curated sequence of segments and optional stopovers defined by a blueprint. Blueprints are suitable for editorial or productized routes (e.g. scenic itineraries, recommended routes, or multi-city trips) and can include planned overnight stopovers.

Typical use cases:

• Publishing recommended routes with fixed or suggested stopovers
• Recreating saved or shared itineraries
• Ensuring specific paths or operators are used

A the part of a booked offer that is the admission

A part of a booked offer that is the reservation

Represents a temporary booking that holds selected offers, pass bundles, and passenger information before payment and confirmation. Bookings have a limited lifespan and must be confirmed before expiration.

If expiresAt is reached without confirmation, or if the booking fails for any reason, the booking is automatically canceled and offers are released back to inventory. An expired or failed booking cannot be used again and will need to be recreated from scratch.

A bookable fare offer for a journey

A sales campaign: an alternative set of terms and products to sell under.

Only campaigns the authenticated caller may use are returned, so any code listed here can be passed wherever a campaign code is accepted.

Describes whether a specific field is required for a travel card type.

Each entry maps a field name (e.g. "identifier") to a requirement level indicating if and when it must be provided.

Resource that can be accessed for check-in and ticket issuing

An outbound and an inbound journey priced together as a round trip, so providers that sell true return fares can return them. Offers hang off each direction's SegmentCollections, exactly as on a single JourneyOffer.

A compartment type for a fare, e.g. Sleeper or Couchette

A corporate agreement code: a company's negotiated rate with an operator, priced into the passenger's offers at search.

A cost center belonging to a sales agent, used for billing and payment routing

A custom field: one of the fields configured in a profile directory, with the value it holds here.

Generic file resource that can be accessed or downloaded.

Represents digital assets associated with orders, such as tickets, boarding passes, receipts, and other travel documents. Resources are typically accessed via URLs and may have different formats.

Common resource types:

• application/pdf: PDF tickets, receipts, and documentation
• image/png: QR codes, boarding passes, and visual elements
• text/plain: Plain text instructions and confirmations
• application/json: Structured data and API responses

Resources may have access restrictions or expiration times depending on the type and operator policies.

All passenger details

An unspecified item in an order

Coordinates of a given location in GeoJSON Point format.

Follows the GeoJSON specification (RFC 7946) using WGS84 coordinate system. Coordinates are stored as [longitude, latitude] array (note the order).

Examples:

• London: [-0.1278, 51.5074] (longitude, latitude)
• Rome: [12.4964, 41.9028] (longitude, latitude)
• Stockholm: [18.0686, 59.3293] (longitude, latitude)
• Berlin: [13.4050, 52.5200] (longitude, latitude)

Note: The type field is always "Point" for this implementation.

A fare offer for a journey

The composite offer for a journey: the journey itself (with itinerary) carrying the bookable Offers that go together, grouped per SegmentCollection. Compose a booking from whichever offer ids you choose (createBooking). Produced by journeyOffer (single) and combinedJourneyOffer (round trip).

Selected journey offer that is part of a booking

A booked journey from a journey offer, containing segments, tickets and other resources

The journey selected for an offer

Known location from and to which journeys can be planned

Paginated locations list result

A location edge in a paginated list

Monetary sum using CLDR (Common Locale Data Repository) format.

The amount field represents the monetary value in the smallest currency unit:

• For currencies with decimal places (USD, EUR, GBP, etc.): amount is in cents (e.g., 1000 = $10.00, 1250 = €12.50)
• For currencies without decimal places (JPY, KRW, etc.): amount is in whole units (e.g., 1000 = ¥1000, 1250 = ¥1250)

Users are advised to consult the CLDR specification for proper currency formatting and display. The currency field contains the ISO 4217 currency code (e.g., "USD", "EUR", "JPY").

Examples:

• USD 1000 = $10.00 (1000 cents)
• EUR 1250 = €12.50 (1250 euro cents)
• JPY 1000 = ¥1000 (1000 yen, no decimal places)
• KRW 5000 = ₩5000 (5000 won, no decimal places)

Payment type used when no payment is required.

This payment type is used in cases where the order has a total price of 0.

The URL field will redirect to the provided successUrl.

A direct journey with no planned stopovers.

Represents the optimal (fastest) end-to-end route from origin to destination without overnight stopovers. Transfers between trains may still occur, but the itinerary does not intentionally include long breaks or multi-day segments.

While this optimizes for speed, it may result in less comfortable connections that require transfers at inconvenient times.

Use when passengers want the fastest connection in a single travel day where possible.

A priced, bookable combination of entitlements for a journey.

An offer bundles everything needed to travel on a ticketable segment of an itinerary. It is made up of one or more parts:

• AdmissionPart: the right-to-travel/tariff entitlement (admission to board)
• ReservationPart: optional seat/berth reservations and add-ons

Pricing and composition:

• price: total price for all included parts in the requested currency
• parts: per-part breakdown with their own price and the segments they cover

Usage:

• returned by journey pricing endpoints and attached to itinerary results
• selected when creating a booking (see JourneyOfferSelection and OfferSelectionInput)
• per-part options (e.g., placeProperties, ancillaries) are configured on ReservationPart items

Notes:

• Some connections can be traveled without a reservation; such offers only have an AdmissionPart
• Sometimes reservations are included, in which case a ReservationPart with no price is returned
• Long or mixed-operator journeys may include multiple AdmissionPart and ReservationPart items, each covering different segments

A set of offers sold, and bookable, only as one product: every leg it covers is booked, each with an offer from the set.

It carries no offers of its own; it is an identity and nothing more. Two offers belong to the same product when their memberOf.id matches.

An onboard service or facility that may be available on a Segment.

Available onboard amenities may vary depending on service class, comfort class and accommodation.

Operator details

Finalized order with confirmed bookings and issued tickets.

Represents a completed transaction where payment has been processed, offers have been confirmed, and tickets have been or are being issued. Orders are the final state of a booking and contain all travel documentation.

The reference field is typically used for customer service inquiries.

Paginated orders list result

Who created an order

An order edge in a paginated list

Pagination information

Bundle of rail passes and similar travel products.

Represents a collection of travel passes that can be purchased together, typically for multiple passengers or extended travel periods. These bundles provide access to train networks across multiple countries.

Pass structure:

• class: "1stclass" (first class travel) or "2ndclass" (second class travel)
• product: "interrail-global-pass" (33 countries), "interrail-one-country-pass-sweden" (single country). A legacy "eurail-" key is accepted as an alias for its "interrail-" counterpart
• travelDayCount: Number of days the pass can be used for travel within the validity period
• validityPeriod: Overall time window when the pass is valid

Pass types:

• Continuous passes: travelDayCount is null (unlimited daily travel during validity period)
• Flexi passes: travelDayCount specifies exact number of travel days within validity period

A booked rail pass from a pass bundle offer, containing passenger details and pass information

Selected Interrail bundle that is part of a booking

Passengers grouped by type for fare calculation and pass bundle allocation.

Represents a count of passengers of the same type that will be traveling together. This grouping is used to:

• Calculate group fares and discounts
• Allocate rail passes and other travel products

The count field represents the number of passengers of this specific type.

The minium passenger details

A traveler's persistent details, offered to prefill a passenger.

Every detail is nullable: a directory profile is data we do not control, and a detail it does not hold (or that we could not read) is simply absent rather than fatal. Only id, salesAgent, costCenter and travelCards (possibly empty) are always set. It deliberately carries no passenger type and no age — both depend on a travel date as well as a birth date, and a profile has no journey. Name the profile with passengerProfileId when searching and booking, and the API derives them from birthDate at the travel date.

A page of passenger profiles. There is no total: the directory keeps none. A page may hold fewer profiles than asked for, or none, while pageInfo.hasNextPage is still true, because profiles of companies the caller may not book for are left out after the page was read; keep paging from pageInfo.endCursor until hasNextPage is false.

A passenger profile edge in a paginated list

Details required for all passengers on a specific booking.

Defines which passenger information fields are mandatory for a particular booking. Requirements are determined by ticketing providers and vary depending on the operator being used.

Ticket issued in PDF format for download

Possible place preferences

Option relating to the seating arrangement and other aspects of the journey.

Allows passengers to specify preferences for their travel experience, such as seat location, cabin type, or special requirements. These properties can be required (mandatory selection) or optional (preference-based).

Common property types:

• "GENDER": Segregated cabin by gender
• "PLACE_OR_COMPARTMENT_LOCATION": Location of the place or compartment
• "SPECIAL_COMPARTMENT_TYPE": Special compartment type

The availableOptions list shows all possible choices, while selectedOption indicates the passenger's current preference.

An option for a place property.

Represents a specific choice within a place property category. These options are what passengers can select from when choosing their preferences.

Examples by property type:

• GENDER: "MEN", "LADIES", "MIXED"
• PLACE_OR_COMPARTMENT_LOCATION: "WINDOW", "AISLE", "FRONT", "BACK"
• SPECIAL_COMPARTMENT_TYPE: "EASY_ACCESS", "WITHOUT_ANIMALS", "QUIET_ZONE"

The value field contains the standardized identifier for the option, while the id field provides a unique reference for selection tracking.

Period for which a serivce is scheduled to run

A product we sell, such as a particular rail pass.

An amount with its unit, a symbol such as "km" or "kg" meant for display.

Rate limit imposed for an agent to prevent API abuse.

Implements rate limiting to ensure fair usage of the API across all agents and to protect system resources from excessive requests.

When remaining reaches 0, requests are rejected until resetAt. Specific limits are determined by the commercial agreement with each agent.

A refund record capturing the execution of refund items for an order.

Contains the corresponding offer part of the refundable item

Contains the corresponding pass item of the refundable item

Contains the corresponding offer part of the refund item

Contains the corresponding pass item of the refund item

The reservation part of an offer.

Represents the seat/berth reservation(s) and related options for the covered segments. May expose configurable placeProperties (e.g., window/aisle, quiet-zone) and optional ancillaries (e.g., luggage, meals). price reflects the reservation cost for the part; the offer total is on Offer.price.

A refund or exchange rule for the ticket. type says which of the two it is, timeframe until when the rule applies, and description is the rule in words.

An authorized agent interacting with the API

Paginated sales agents list result

A sales agent edge in a paginated list

A seat assignment for a passenger

A map of seats for each coach

A coach with seats

A facility marked on a coach's floor plan

The floor plan of a coach, drawn landscape with the direction of travel to the left. Seats and features are positioned by their top-left corner in the plan's pixels.

A seat on a coach

Individual train segment representing a single physical train journey between two stops.

A segment is the atomic unit of travel - it represents one train/bus/ferry that travels from origin to destination, possibly with intermediate stops but no change of transport. Multiple segments can be combined to form an individual journey leg, see SegmentCollection.

A collection of connected segments that form a logical journey leg.

Represents a sequence of segments that:

• Share the same availability status
• Can be booked together
• Have common offer options
• Form a continuous path between major stops

Used to group related segments together for pricing and booking purposes.

The selected fare of a journey offer

Resource that provides a self-service link for customers to manage their booking on the provider's website

The brand of the service

A journey that optimizes for comfort by limiting daily travel time.

For short distances, provides direct connections when available. For longer routes, automatically segments the journey into multiple days to avoid excessively long travel times. This ensures passenger comfort and builds in buffer time in case of disruptions.

Segmentation logic considers factors like night trains, connection times, and time of day to determine whether splitting into multiple days would improve the overall experience.

This is the default journey type returned by the API.

Typical use cases:

• Long-distance trips that would be exhausting in a single day
• Routes where overnight breaks improve reliability
• Itineraries benefiting from night trains or natural break points

Location for an overnight stopover

Payment using Stripe

The ticket delivery choice for an offer.

Record a pick with the setTicketDelivery mutation, before creating the order.

One way an offer's tickets can be delivered.

Ticket which can be retrieved on departure

A travel/discount card held by a passenger.

Represents loyalty, discount, or rail cards that may entitle the passenger to reduced fares. Examples include BahnCard (Germany), Halbtax (Switzerland), Carte Avantage (France), or Interrail.

Use the travelCardOptions query to discover available cards and their required input fields.

An available travel card type that passengers can hold.

Use the code field when constructing a TravelCardInput and consult inputFields to determine which additional fields are needed.

A rule about how the ticket may be used, other than the dates it is valid on (those are a ValidityCondition). type says what kind of rule it is, description is always the complete text, and url is set when a web page holds the full wording of this specific rule. Render description; when url is present, make it a link.

The authenticated end user, as identified by their user token (JWT)

The dates on which the ticket may be used. validFrom and validUntil are inclusive calendar dates in the operator's local time zone, and they are definite: travel may start on validFrom and no later than validUntil. There is deliberately no time of day. Operators let the last valid day run on into the following morning — UK National Rail until 04:29, Deutsche Bahn Flexpreis until 10:00 — and they differ on what that overrun permits (starting a journey, or only finishing one), so it is never encoded in these dates; where a provider states it, it is in description. Do not convert the dates to timestamps or shift them between time zones. A part with a TRAIN_BOUND TravelCondition never has a ValidityCondition: the booked departure is its validity. A part with neither has a provider that did not state a validity window; it is not valid indefinitely.

One part that makes up a booked offer.

Each part references the exact segments it applies to. The optional price reflects the original cost of this part.

A rule attached to an offer part about using, refunding or exchanging the ticket. Every condition carries description: complete, human-readable text that is always safe to show on its own. Tell the kinds apart by __typename and read their typed fields through inline fragments (... on ValidityCondition { validFrom validUntil }). New kinds may be added over time: render description for any __typename you do not recognize rather than dropping the entry. The list holds only what the provider stated — the absence of a kind (no ValidityCondition, no TRAIN_BOUND) means the provider did not say, never that the rule does not apply.

type and timeframe sit on the interface only so that selections written against the previous [ReturnCondition!]! shape keep validating; see their deprecation reasons.

Fare offer for given itinerary item

Journey result produced by any given search algorithm

Any unique resource with an ID

One part that makes up an offer.

Each part references the exact segments it applies to. The optional price reflects the cost of this part; the overall total is reported on Offer.price.

A passenger with minimal details

Represents a payment that needs to be processed to complete an order. The payment interface defines the common fields shared across different payment methods:

• id: Unique identifier for the payment
• url: URL where the customer can complete the payment

Different payment implementations (like StripePayment or NoChargeRedirect) may provide additional fields specific to their payment flow.

The payment URL typically redirects to a payment page hosted by All Aboard where the customer can securely enter their payment details.

A place assignment for a passenger

A placement on a coach, eg. a seat or a bed

Represents a potential refund opportunity before execution

Represents a refund line item after execution has been initiated

Generic train stop

What an access token may do on the order it is bound to.

READ is implied by WRITE, so a token minted with [WRITE] comes back carrying both — a credential that may refund an order may read it.

The type of accommodation available

Transitional union of ReturnType and the travel-condition kinds, present only while Condition.type exists on the interface. Each concrete type returns only its own values: ReturnCondition REFUND, EXCHANGE or UNKNOWN; TravelCondition ROUTE, TRAIN_BOUND or RESTRICTION; ValidityCondition has no meaningful type and returns UNKNOWN. The end state removes type from Condition, narrows ReturnCondition.type back to ReturnType and TravelCondition.type to TravelConditionType, and retires this enum. Do not write new code against it: select type through ... on ReturnCondition or ... on TravelCondition.

The kind of value a custom field holds, as configured in the profile directory.

Whether a travel card field is required

Flexibility of a fare

The current status for a journey result

Type of journey

A version of an operator or service brand logo.

Categories of amenities describing onboard services and facilities

Current status of an order

The resulting product type definition for a passenger

The perferred title of a passenger

The type of passenger

Valid agent payment method

The availability of a place, eg. seat or bed

The unit for a given rate limit

State of a refund item

State of a refund

Indicates if, and during what timeframe, an offer part is returnable/exchangeable. Use this field to signal:

• If the offer part is refundable/exchangeable or not
• If so, the relevant period (e.g. only before departure, or at any time) Consult the accompanying description for refund/exchange details (e.g. % refunded, fees).

Type of return covered by a return policy

The kind of facility a floor plan marks, named after OSDM's Graphics Items code list. Expect values to be added.

Status indicating whether a segment collection was successfully loaded or encountered an error

Normalized class of service

Sort direction for ordering results

How the tickets for an offer are handed to the traveler

The mode of transport

Selections that can be part of a booking

Items that can make up the itinerary of a Journey

Items that can be part of an order

A resource associated with an order

A map of places on e.g. a leg of a journey

The Boolean scalar type represents true or false.

A custom field's value, typed by the field's type: a Boolean for BOOLEAN, a date as a YYYY-MM-DD String for DATE, and a String for INPUT, TEXTAREA and TEL.

Date string (ISO 8601 – YYYY-MM-DD)

Naive date and time string, seconds omitted (ISO 8601 – YYYY-MM-DDThh:mm)

ISO 8601 formatted string, e.g. PT2H15M, P2D, P1M

The Float scalar type represents signed double-precision fractional values as specified by IEEE 754.

The ID scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as "4") or integer (such as 4) input value will be accepted as an ID.

The Int scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.

The JSONObject scalar type represents JSON objects as specified by ECMA-404.

The String scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.

A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the date-time format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.

What an access token is narrowed to. Exactly one order today; the shape is an object so a later narrowing is an added field rather than a breaking change.

Ancillary to add to a booking for a given passenger

Selection for a booking

Input for attaching a corporate agreement code to a passenger

Selects a cost center to bill this passenger's travel against

A new value for a custom field, named by its key.

Selection of fare for a journey

Full passenger details required to complete a booking.

Represents the complete set of passenger data that may be required by ticketing providers and operators. Exactly one passenger per booking must be marked as the contact person using isContactPerson: true. The contact person must provide both email and tel so they can receive operational updates.

Notes:

• Only one passenger should be marked as contact person per booking
• When isContactPerson is true, email and tel must be provided
• Other fields may be required depending on operator (see PassengerRequirements)

A point in GeoJSON format, following RFC 7946 and using the WGS84 coordinate system.

Coordinates are given as [longitude, latitude] (note the order), and type is always "Point".

Examples:

• London: { type: "Point", coordinates: [-0.1278, 51.5074] }
• Stockholm: { type: "Point", coordinates: [18.0686, 59.3293] }

Filter for journey search results by journey type.

Use this to restrict which journey variants are returned. Supported types:

• SMART: Comfort-optimized journeys; may split long routes across days. Default journey type returned by the API.
• BLUEPRINT: Journeys based on predefined itinerary blueprints (curated or editorial routes), can include planned stopovers.
• NON_STOP: Fastest end-to-end journeys without planned overnight stopovers.

You can combine multiple types to retrieve several variants at once.

Identifies a location.

Holds the location's uid today. Future identifiers will be added as further optional fields rather than as new arguments.

Narrows and orders locations. Every field is optional, and which of query and near are given decides the order: query ranks by relevance, near without query orders by distance, and neither keeps the stable walk order. countryCode and isMeta only narrow.

Selection of offer for a journey

Narrows orders. Every field set must match.

Filter for filtering pass bundles by various criteria.

Supported filters:

• product: Filter by specific pass product type, e.g. "interrail-global-pass"
• class: Filter by travel class (e.g. "1stclass" or "2ndclass")
• campaignCode: Filter by promotional campaign code, e.g. "INTERRAIL_2025"

Use this to narrow down pass bundle results when searching for available passes.

Input type for basic passenger details. When specifying a passenger's age, either:

1. Provide the birthDate field with their date of birth, OR
2. Provide the age field with their age at time of travel

For passenger types YOUTH and SENIOR, one of these age fields must be provided to validate eligibility for age-based fares and discounts.

For the ADULT passenger type, age fields are optional.

What to search passenger profiles by. query is required.

Passenger details for passholder

Place property to update

A place selection for a passenger

Ancillary selection to remove from a booking

Narrows a list of sales agents. Every field set must match.

A seat selection for a passenger

Input for attaching a travel card to a passenger

Via stopover for a journey to break up long trips.

Allows passengers to specify intermediate locations where they want to stop and spend time before continuing their journey. This is useful for long-distance travel where passengers want to explore cities along the way or break up overnight journeys.

Field requirements:

• uid: Required - the location UID where the stopover occurs
• duration: Optional - how long to stay (e.g., "P2D" for 2 days) If not specified, the journey will simply route via that location with a change of trains (no extended stopover)