Detailed view of a ride

Control Center offers a detailed view of rides with the following tabs.

Overview
Inspect
Matching Logs
Request & Matching Details
Public Transport Alternatives
Ticket

Overview

The first tab gives a general overview of the ride. At the top, a live map shows the ride. Below it, a summary table lists the ride’s key details, followed by sections for the passengers, times, tasks, and any ratings, tips, payments, and documents. Rows and sections that don’t apply to a ride are hidden—for example, the cancellation rows appear only for a cancelled ride, and the fare rows only once the ride has a fare.

The map plots the assigned vehicle’s recorded positions for the ride, alongside the pickup and drop-off locations and the calculated route. Only high-accuracy positions from the ride’s own time window are shown:

For a prebooked ride, from 10 minutes before the pickup time until the ride reaches an end state (dropped off or cancelled).
For an ad hoc ride, from the moment the ride is matched until it reaches an end state.

Because vehicle positions are kept for a limited time, the map for an older ride may no longer show them.

The summary table can include the following.

State
Cancellation reason. Shown when the ride is cancelled. If the passenger gave a cancellation statement, its title is appended.
Canceller. Shown when the ride is cancelled. Displays the operator or driver who cancelled, or “User themselves” when the passenger cancelled.
Origin
Destination
Product. Links to the product.
User. Links to the passenger’s user profile.
Public transport ticket reminder. Shown for products that require a public transport ticket; indicates whether the reminder is displayed.
Vehicle. Shown when a vehicle is assigned; links to the vehicle.
Driver
Booking. Whether the ride is booked, shown together with the booking’s verification code, or that it is unbooked.
Time until driver accepted
Created by
Passenger note to driver. Shown when the passenger left a note for the driver.
Payment method. The payment method used for the booking.
Price. The booking price. Shown when the ride has a fare.
Final price. Shown when a final price exists, with a badge for the fare type.
Personal discount. Shown when a personal discount applies; links to the discount.
Payment state. The payment state of the booking.

Passenger

This section lists the passengers of the ride by passenger type and shows if any passenger options were selected.

Pickup and dropoff times

This section appears once both a pickup and a dropoff have been calculated. For each, it shows the calculated point—the station it resolves to, or the address when no station applies—the negotiation time window, and the final time window.

Tasks

The corresponding tasks are also summarized here and their state is indicated.

Rating

If the passenger has rated the ride, this section displays information on the rating.

Tips

Shown when the ride has tips. For each tip, it lists the amount, the driver who received it, and when it was given. If more than one tip exists, a warning highlights the possible duplicate.

Payment items

Shown when the booking has a payment method. This table lists the payment and refund items for the booking, each with its state, payment service provider data, payment method, amount, and date. Refunding an item requires the create_refunds permission.

Phone calls

This section lists calls between the driver and passenger. This allows for better tracking previous passenger interactions, for example, in the case of lost items or delays.

Purchases

Permissions: read_purchases

Shown when the ride has purchases. The table lists each purchase’s ID, what it is for, its type, state, gross and net amounts, VAT rate, payment method, and creation time.

Invoices

Permissions: read_invoices

This section lists the invoices for the ride and any related rides.

Receipts

Permissions: read_receipts

This section provides a table of receipts with the following columns: ID, Title, Created at, and Attachment. It includes receipts for the ride and any related rides.

Inspect

This tab shows the raw, technical, database-level record of the ride and the objects related to it. It is organized into collapsible sections, and each section presents the stored attributes of one object. Where an object keeps a change history, the section also offers a Show changes view listing its last 50 changes under a Last changes heading. Each row shows the following columns.

Event. The type of change, such as a create or an update.
Changed by. The identifier of whoever made the change, whether an administrator, a Platform API client, or a driver. This column is blank only when no authenticated actor made the change, such as system-initiated or console changes.
Time. When the change happened.
Changes. The exact fields that changed, with their previous and new values.

The following sections appear. Some are shown only when the ride has the corresponding data.

Overview. The ride’s own stored attributes and its last 50 changes.
Requested points. The requested points as the passenger asked for them, split into Origin and Destination.
Calculated points. The calculated points that matching settled on, split into Pickup and Dropoff. This section appears once both a pickup and a dropoff have been calculated. Each point also lists its time window revisions: the successive recalculations of the point’s time window, in order, so you can trace how it evolved.
Vehicle. The stored attributes and last 50 changes of the vehicle assigned to the ride. Shown when a vehicle is assigned.
Fare. The ride’s fare and its line items. Shown when the ride has a fare. See Fare below.
Payment method. The stored attributes of the payment method used for the booking. Shown when the booking has a payment method.

Fare

The Fare section shows the following details of the ride’s fare, followed by its line items.

ID. The unique ID of the fare.
Final price. Final price for the ride which is charged if payment is activated for the product.
Adapter options. Additional information for the fare calculation. This also holds the complete calculation input that the fare calculation adapter used.
Created at
Updated at
Version
Personal discount. Information on personal discounts that are applied to the fare.
Price. The fare which is calculated by the selected fare calculation adapter.
Booking price type. This is set to fixed when the price will not change anymore, max when the final price will be lower or equal to the booking price and estimate, when the final_price is unknown in advance.
Fare type. A fare always has one of the following types: default, no_show_fee , free_no_show, cancellation_fee, or free_cancellation.
VAT rate. Corresponding VAT rate. This is a provider setting.
Currency. The currency of the applied fare.

Fare line items

Below the fare details, a Fare line items table breaks the fare down into its individual parts, such as the base price, surcharges, and discounts, per passenger. Each row shows the line item’s ID, passenger index, title, type, amount, and creation time.

When the booking has been paid, a Purchase line items table also appears, listing each purchased item with its title, description, quantity, gross and net amounts, total gross amount, VAT rate, and creation time.

Matching Logs

The Matching Logs tab shows how the matching algorithm worked for this ride. Every stage of matching can be retraced: Task List Finder, Combinator, Sequencer, and Time Frame Builder. Information from the Validator and Decider also appears in the Planning List Logs.

Use this tab to investigate why a ride was matched, rejected, delayed, or filtered out during matching.

The tab is layered: everyone who can open it sees the message log of the matching run, while the detailed internal debug areas are reserved for ioki Super Admins.

Who can view matching logs

Permissions: read_rides

Opening the tab requires a product-scoped role with read_rides. Because the permission is product-scoped, a Product Admin can open it, but a Provider Admin alone cannot.

Every administrator with read_rides sees:

A banner stating whether the ride’s matching is still pristine—that is, whether the stored logs still reflect the ride’s current matching, or whether a later change (such as a rematch) means they no longer do.
The number of matching logs stored for the ride.
The messages log: the human-readable, timestamped message log of the matching run, with the time each step took and, where available, its memory usage.

For most administrators, the messages log is the entire tab.

Areas only Super Admins can see

The remaining, more technical areas of the tab are shown only to ioki Super Admins. They stay hidden for every other role, even one that holds read_rides:

Metadata for the newest matching log. Whether it is marked as an analyze run and whether it is preserved.
Planning List Logs, including the Planning List Summary (Ranking 1) and the detailed per-candidate table (round, ranking, ride variant, vehicle, index fingerprint, pickup and dropoff, estimated and final score, number of stages, last stage reached, and any error).
The additional internal tables—Task List Finder vehicles, best solutions per vehicle, Task List Finder positions, and the ride variants log (which also notes when no ride variant could be built, for example an intermodal setup with no suitable feeder alternative).
A CSV download button for each of these tables. The message log itself has no CSV export—only the Super Admin debug tables can be downloaded.
Offered solutions. Whether multiple booking solutions is active for the product, the ride’s current state, and the raw offered-solution output.

If you can see the detailed Planning List Logs, pay special attention to the fingerprint and the elimination or validation result:

The fingerprint shows the structural insertion pattern of a candidate.
When fingerprint subsampling is active, the same structural fingerprint can appear several times with different suffixes such as 3-4/-5m or 3-4/+5m. This means ioki Platform tested the same insertion again with the requested time shifted earlier or later. The suffix is displayed in rounded full minutes.
The elimination or validation result helps explain why a candidate was rejected or allowed to continue.

For terminology and broader background, see Matching.

Matching log tables

This section is a full reference for the Super Admin debug areas. Everything below the messages log is shown only to ioki Super Admins. Each of these tables can be downloaded as a CSV file; the messages log cannot.

The column and field names used below (dt, index_fingerprint, solution_type, waypoint_type, and so on) are the literal identifiers shown on screen and in the downloaded CSV files. They appear in code font throughout this section.

Example values such as plates, coordinates, and times are format illustrations only and do not represent real data.

`messages`

The human-readable, timestamped message log of the matching run. This is the one table every administrator with read_rides can see, and it is the only one without a CSV download.

Column	Type	Meaning
`dt`	Integer, milliseconds	Time elapsed since the matching run started. This is a duration, not a wall-clock timestamp.
`log_level`	Integer	Verbosity of the entry, adjusted for how deeply nested the step is: `1` marks the start or end of a phase, `2` a major operation, `3` a vehicle or task detail, and `4` a deep trace. Deeper nesting can push the value higher.
`message`	String	The log entry itself, describing a state change, progress, or a diagnostic.
`mem_usage`	Float, megabytes	Memory usage, rounded to two decimals. Sampled only at phase boundaries; otherwise empty.

`task_list_finder_positions`

A geospatial snapshot from the Task List Finder stage, with one row per evaluated vehicle. It records where each vehicle is assumed to be relative to the ride’s origin, which is how vehicles are ranked by proximity. Every point is formatted as lat,lng rounded to six decimals (for example, 52.520000,13.405000), and is empty when the point is missing.

Column	Type	Meaning
`task_list_id`	UUID	The task list, a vehicle’s shift assignment, being evaluated.
`vehicle_id`	UUID	The vehicle assigned to that task list.
`vehicle_license_plate`	String	The vehicle’s registration plate.
`vehicle_nickname`	String	The operator-assigned vehicle name.
`task_list_default_origin_point`	`lat,lng`	The task list’s start location, such as a base or depot.
`vehicle_last_known_point`	`lat,lng`	The vehicle’s most recent reported position. Empty when there is no recent position.
`vehicle_assumed_point`	`lat,lng`	The vehicle’s computed position at the ride variant’s origin time. This is interpolated and differs from the last-known position when the vehicle is moving.
`ride_variant_origin_point`	`lat,lng`	The origin of the first ride variant, where the on-demand portion begins.
`assumed_to_ride_origin_distance`	Integer, meters	The distance from the assumed vehicle point to the ride-variant origin, used to sort vehicles by proximity.

`task_list_finder_vehicles`

A pass or fail record from the Task List Finder stage, with one row per vehicle and the reason for the decision.

Column	Type	Meaning
`vehicle_id`	UUID	The vehicle.
`vehicle_license_plate`	String	The registration plate.
`vehicle_nickname`	String	The vehicle name.
`validation_result`	String	The pass or fail decision, with its reason.

validation_result holds one of the following:

Value	Meaning
`OK: Considered in matching`	Passed all checks and stayed within the candidate limit.
`Fail: No active task list for matching time`	No active task list in the ride’s time window.
`Fail: Negotiation ongoing`	The task list has an active negotiation, and concurrent negotiations are disabled.
`Fail: Requested ride does not satisfy lead-time constraints`	The booking is too close to the ride time for the lead-time rules.
`Fail: Vehicle cannot be used for prebooked ride`	The ride is prebooked but the task list is not prebookable.
`Fail: Vehicle cannot be used for ad hoc ride`	The ride is ad hoc but the task list is not ad-hoc bookable.
`Fail: Driver cancelled recently`	The vehicle’s driver recently rejected this ride.
`Fail: TaskList active and ride ad-hoc, but no connected driver and not autonomous`	An ad hoc ride needs a connected driver, and this non-autonomous vehicle has none.
`Fail: TaskList active and ride ad-hoc, but the vehicle has no current position`	An ad hoc ride needs a current position, and this vehicle has none.
`Fail: Not used (max_considered_vehicles reached)`	Passed validation but dropped because the candidate limit was already reached.

`best_solutions_per_vehicle`

The single most promising candidate per vehicle, logged after all matching rounds. Each row records how far that vehicle’s best candidate reached and how it ended.

Column	Type	Meaning
`task_list_id`	UUID	The task list of the vehicle’s best candidate.
`vehicle_id`	UUID	The vehicle.
`vehicle_license_plate`	String	The registration plate.
`vehicle_nickname`	String	The vehicle name.
`max_stage_num`	Integer, 0–5	The number of processing stages the candidate survived.
`max_stage`	String	The name of the deepest processing stage reached. Empty when no stage was reached.
`estimated_score`	Integer	The pre-ranking score estimate. Empty when the candidate was not scored yet.
`score`	Integer	The final score after full routing. Empty when the candidate was eliminated before final scoring.
`error`	String	The elimination reason if the candidate was rejected. Empty when it was retained.

Scores are weighted sums of penalties and gains in arbitrary units, where a lower score is better. The estimated score predicts the final score early in the run; the two can differ once routing is refined.

Processing stages

Both best_solutions_per_vehicle and the detailed planning_list_logs table count and name the same processing stages, always in this order:

Pre-routing validation—initial checks on shift tasks, air distance, pauses, overbooking, enclosed tasks, station order, area coverage, and tier order.
Estimation filter—drops unpromising candidates based on their estimated score.
Post-estimation routing validation—checks timing, walking, and cost after estimation routing.
Post-final routing validation—final timing and constraint checks after detailed routing.
Decider—final selection: limits the number of persisted solutions and drops inferior ones.

Elimination reasons

When a candidate is rejected, the reason appears in the error column here and in planning_list_logs. The possible values, grouped by the stage that produces them, are:

Pre-routing validation: multiple_start_of_shift_tasks_found, start_of_shift_task_must_be_first_unfinished_task, multiple_end_of_shift_tasks_found, end_of_shift_task_must_be_last, air_distance_too_small, pickup_inside_pause_task_tuple, dropoff_inside_pause_task_tuple, ride_spans_a_pause, overbooked_seats, overbooked_vehicle_resources, max_enclosed_tasks_exceeded, dropoff_after_pickup_on_pickup_station, pickup_before_dropoff_on_dropoff_station, calculated_pickup_outside_of_area, calculated_dropoff_outside_of_area, tier_order_broken.
Estimation filter: unpromising.
Routing validation: not_enough_time, task_order_broken, time_in_the_past, walking_times_too_high, pickup_walking_times_too_high, dropoff_walking_times_too_high, ride_duration_exceeded, time_deviation_exceeded, opportunity_cost_too_high. During the estimation run these are prefixed with estimating_. Final-only reasons are collides_with_deactivation, task_times_violate_deactivation, travel_combination_not_served, ride_not_in_served_product_area, and lead_time_conditions_not_met.
Routing setup: routing_error_setup_walking_durations_pickup, routing_error_setup_walking_durations_dropoff, and routing_error_setup_times_and_streaks_on_calculated_points.
Pedestrian routing: pedestrian_routing_error.
Decider: inferior_task_list_solution, inferior_matching_rank, not_chosen_by_decider.
Reference-list validation: planning_reference_list_invalid and routing_error_setup_times_on_calculated_points.
Solution triage and suppression: triage_multiple_booking_solutions_filter, prohibit_parallel_filter, overlapping_ride_filter, and suppressed_drt_only_solution.

`ride_variants_log`

The full slate of intermodal ride variants considered before filtering, with one row per variant. This table is always created, even when it is empty: if no variant can be built (for example, an intermodal setup with no suitable feeder alternative), the table exists with no rows.

Location values are formatted as location_name (lat/lng). Feeder columns are empty when that leg does not exist, such as on a pure on-demand variant.

Column	Type	Meaning
`label`	String	The variant identifier, formed as a letter followed by a service mode. The letter increments with build order (`A`, `B`, `C`, …). The service mode is `[DRT]` for a pure on-demand variant, `[PT:DRT]` for a first-mile feeder variant, or `[DRT:PT]` for a last-mile feeder variant.
`first_mile_feeder_pta_id`	UUID	The first-mile feeder public transport alternative. Empty when there is no first-mile feeder.
`first_mile_feeder_origin`	Location	Where the first-mile feeder starts. Empty when there is none.
`first_mile_feeder_destination`	Location	Where the first-mile feeder ends, where the on-demand pickup then begins. Empty when there is none.
`origin`	Location	The origin of the on-demand portion, the passenger pickup.
`destination`	Location	The destination of the on-demand portion, the passenger drop-off.
`last_mile_feeder_pta_id`	UUID	The last-mile feeder public transport alternative. Empty when there is none.
`last_mile_feeder_origin`	Location	Where the last-mile feeder starts, where the on-demand portion ends. Empty when there is none.
`last_mile_feeder_destination`	Location	Where the last-mile feeder ends, the final destination. Empty when there is none.

Variants are built on-demand first (when both ends can be served on demand), then one variant per eligible first-mile feeder, then one per eligible last-mile feeder. The log shows every variant considered, before the desired-variant strategy and the maximum-variant limit trim the list.

`planning_list_logs`

The most detailed table: one row per candidate insertion (planning list). The columns appear in the exact order below.

Column	Type	Meaning
`mode`	String	The matching mode of the run.
`pre_ranking`	Integer	The pre-ranking score, computed before final ranking.
`ranking`	Integer	The final rank, starting at 1. Rank 1 is the best candidate.
`round`	Integer	The matching round this candidate belongs to.
`ride_id`	UUID	The ride.
`ride_variant`	String	The ride variant identifier, matching `label` in `ride_variants_log`.
`vehicle_id`	UUID	The vehicle.
`vehicle_license_plate`	String	The registration plate.
`vehicle_nickname`	String	The vehicle name.
`vehicle_approaching_lat`	Float	The latitude of the vehicle’s approaching position at scenario time.
`vehicle_approaching_lng`	Float	The longitude of the approaching position.
`vehicle_approaching_source`	String	The origin of the approaching position, such as a reported, planned, or interpolated value.
`vehicle_last_known_lat`	Float	The latitude of the vehicle’s last known position. Empty when there is none.
`vehicle_last_known_lng`	Float	The longitude of the last known position. Empty when there is none.
`index_fingerprint`	String	The structural insertion pattern of the candidate (see below).
`num_tasks`	Integer	The number of relevant tasks in this planning list.
`index_fingerprint_desc`	String	A human-readable form of the fingerprint, for example `---P-D--- (3. and 4. of 8)`, where each dash is a task, `P` marks the pickup slot, and `D` marks the drop-off slot.
`pickup_station_id`	String	The pickup station, or `n/a` for an address-based pickup.
`dropoff_station_id`	String	The drop-off station, or `n/a` for an address-based drop-off.
`origin`	String	The requested origin location name.
`destination`	String	The requested destination location name.
`pickup`	String	The calculated pickup location name, which can differ from the origin when a station is selected.
`dropoff`	String	The calculated drop-off location name.
`estimated_score`	Number	The score estimated before final routing validation.
`score`	Number	The final score after routing, used for ranking. Lower is better.
`matching_rank`	Integer	The priority order of the original task list.
`valid_after_decider`	`YES` / `NO`	Whether the candidate survived the Decider stage.
`error`	String	The elimination reason, using the same values as in `best_solutions_per_vehicle`. Empty when the candidate was not eliminated.
`analyze_error`	String	On analyze runs, the prediction-analysis result recorded when the estimation prediction did not match the final outcome.
`num_stages`	Integer	The number of processing stages reached.
`last_stage`	String	The name of the last processing stage reached. Empty when none was reached.

The next 36 columns are the scoring components, followed by one final column:

Column	Type	Meaning
`estimated_scoring_<key>` and `scoring_<key>`	Number	The scoring components (see below).
`summary`	String	The full, multi-line text summary of the candidate. This is the same text shown in the Planning List Summary block described further down.

Scoring components

There are 18 scoring components. Each appears twice: once as estimated_scoring_<key>, using the values estimated before final routing, and once as scoring_<key>, using the values from full routing. The estimated_scoring_* columns show what the run predicted early; the scoring_* columns show what the refined routing produced. The two can differ.

Each component is a pair: a raw measurement (usually a duration or ratio) and the penalty or gain it contributes to the score. The pairs are:

waiting_time / waiting_penalty
walking_time / walking_penalty
driving_time / driving_penalty
passenger_time / passenger_gain
delay_duration / delay_penalty
driving_duration / driving_duration_penalty
empty_duration / empty_duration_penalty
loaded_duration / loaded_duration_gain
ride_duration / ride_duration_gain
passenger_duration / passenger_duration_gain
passenger_direct_routing_duration / passenger_direct_routing_duration_gain
additional_driving_duration / additional_driving_duration_penalty
additional_empty_duration / additional_empty_duration_penalty
additional_loaded_duration / additional_loaded_duration_gain
additional_ride_duration / additional_ride_duration_gain
additional_passenger_duration / additional_passenger_duration_gain
additional_passenger_direct_routing_duration / additional_passenger_direct_routing_duration_gain
cost_benefit_ratio / cost_benefit_ratio_penalty

The `index_fingerprint` format

The index_fingerprint describes where a candidate inserts the pickup and drop-off into the vehicle’s task sequence, and whether the requested time was shifted for the test:

The base is pickupIndex-dropoffIndex, the 1-indexed slots where the pickup and drop-off tasks are inserted (for example, 3-4).
A suffix follows the base. /~ means the requested time was used as-is. /±Nm means the same insertion was retested with the requested time shifted, where N is the offset in rounded full minutes. For example, 3-4/~, 3-4/+5m, and 3-4/-5m are the same insertion tested at the requested time, five minutes later, and five minutes earlier.
When fingerprint subsampling is active, the same base fingerprint appears several times with different ±Nm suffixes, one per shifted retest.

Planning List Summary (Ranking 1)

Above the planning_list_logs table, a multi-line text summary describes the single best candidate. It is the rank 1 candidate of the most recent matching round: rows are ordered by round (newest first) and then by ranking (best first), and the summary of the first row is shown.

The summary gathers, in order:

The matching mode.
The planning ride, with its direct travel distance and duration.
The ride variant, with its direct travel distance and duration.
The maximum ride duration and maximum detour duration allowed, and the time used for the ride.
The task list, the fingerprint, and the vehicle (plate, nickname, approach position, and approach distance in meters).
The pickup and drop-off stations (a name, or n/a).
The hop durations, from the vehicle to the first task and then task to task.
The free buffers, buffer fragmentation, and task-reuse figures.
The line connection, with the line and the pickup and drop-off line-stop details.
The round, matching rank, ranking, and pre-ranking.
Whether the vehicle is autonomous, and the estimated and final scores.
The projected statistics and projected reference statistics.
The number of processing stages and the last stage reached.
Prohibit-parallel-rides debug details.
The error, its supporting information, and whether the candidate was valid after the Decider stage.
The full scoring details and estimated scoring details, covering every component key.
A per-task breakdown of the task list: the vehicle’s earliest start, and for each task the hop distance and duration, free buffer, streak, task description, and the requested, calculated, reference, negotiated, inferred, rematching, and line-stop time windows.
A legend of every ride involved, with each ride’s creation time.

Offered solutions

The Offered solutions area shows whether multiple booking solutions is active for the product, the ride’s current state, and the raw offered-solution output.

The raw output is a JSON array of solution objects, with no wrapper. When multiple booking solutions is off, the array holds a single best on-demand or intermodal solution. When it is on, the array holds the merged set, limited per solution type.

Each solution object has these fields:

Field	Type	Meaning
`id`	String	The solution ID.
`created_at`	ISO 8601 datetime	When the solution was created.
`updated_at`	ISO 8601 datetime	When the solution was last updated.
`bookable`	Boolean	`true` when the solution is on-demand or intermodal and not already booked.
`default`	Boolean	`true` when the solution is bookable and current. This is the solution used when a booking does not name a specific solution.
`solution_type`	Enum string	One of `drt`, `intermodal`, or `public_transport`.
`fare`	Object	The fare object. `null` for public-transport-only solutions.
`hops`	Array	The ordered legs of the journey (see below).

Three internal fields are used to compute bookable and default but are not included in the output: relevance_score, booked, and current.

The `fare` object

Present only for on-demand and intermodal solutions:

Field	Type	Meaning
`id`	String	The fare ID.
`created_at`	ISO 8601 datetime	When the fare was created.
`updated_at`	ISO 8601 datetime	When the fare was last updated.
`booking_price`	Money	The booking price.
`booking_price_type`	Enum string	`fixed` when the price will not change, `max` when the final price will be at most the booking price, `estimate` when the final price is not yet known, or `external`.
`fare_type`	Enum string	`default`, `no_show_fee`, `free_no_show`, `cancellation_fee`, or `free_cancellation`.
`final_price`	Money	The final price, available at the end of the ride. `null` before then.
`line_items`	Array	The individual parts of the fare.
`personal_discount`	Object	The applied personal discount. `null` when none applies.
`custom_message_for_external_pricing`	String	A localized custom message for external pricing. `null` when there is none.
`booking_price_object`	Money	Deprecated. The booking price.
`final_price_object`	Money	Deprecated. The final price.
`show_custom_message`	Boolean	Deprecated. Whether to show a custom message.

A Money object has three fields: amount (an integer in minor currency units, such as cents), currency, and vat_rate.

The `hops` array

hops is an ordered array of typed legs. Every hop shares these fields:

Field	Type	Meaning
`duration`	Integer, seconds	The length of the hop.
`transport_mode`	Enum string	`drt`, `public_transport`, or `walk`.
`from`	Object	The start point of the hop (see hop endpoints below).
`to`	Object	The end point of the hop.
`track`	String	The hop’s route as a Google-encoded polyline. `null` when there is none.

Each hop type adds its own fields:

On-demand hop. Adds a vehicle object with the vehicle’s id, license_plate, manufacturer, model, nickname, fuel_type, range-budget fields (maximum_range_budget, current_range_budget, range_budget_unit, range_budget_calculation_adapter_name), autonomous, supports_open_door_requests, and door_control_available. The capacity fields seats, storage_spaces, walker_bays, and wheelchair_bays are deprecated.
Walking hop. Adds no extra fields.
Public transport hop. Adds a details object with direction (the connection’s destination), name (the line name, such as U5 or S1), and transport_type (one of long_distance_train, regional_train, suburban_train, bus, underground, or tram).

Hop endpoints

The from and to endpoints are polymorphic. Each is one of three types.

A calculated point carries matching’s calculated values:

Field	Type	Meaning
`id`	String	The point ID.
`created_at`, `updated_at`	ISO 8601 datetime	Timestamps.
`city`, `country`, `county`, `postal_code`, `street_name`, `street_number`	String	Address parts. `null` when unknown.
`formatted_address`	String	The most specific address available, falling back to coordinates.
`display_times`	Array	Zero to two datetimes to show the passenger.
`delay_state`	Enum string	`ok`, `slightly_delayed`, or `heavily_delayed`.
`fixed_location`	Boolean	Whether the location is fixed rather than changing over time.
`lat`, `lng`	Number	Coordinates.
`location_name`	String	The location name.
`negotiation_time`	Datetime	The time offered to and booked by the passenger; it never changes.
`negotiation_time_max`	Datetime	The latest time the pickup or drop-off may move to for reasons within ioki Platform’s control; fixed during matching.
`pause_id`	String	The pause, when the point is a pause boundary. `null` otherwise.
`station`, `station_id`	Object / String	The station, when the point resolves to one. `null` otherwise.
`time`	Datetime	The current calculated time. It can exceed `negotiation_time_max` when there is a real delay outside ioki Platform’s control.
`walking_duration`	Integer, seconds	The walking duration. `null` when none.
`walking_track`	String	The walking route as a polyline. `null` when none.
`waypoint_type`	Enum string	`origin`, `destination`, `pickup`, `dropoff`, `start_of_shift`, `end_of_shift`, `start_of_pause`, `end_of_pause`, `repositioning`, or `line_stop`.
`formatted_street`	String	Deprecated. A formatted address string.

A requested point carries what the passenger asked for:

Field	Type	Meaning
`id`	String	The point ID.
`created_at`, `updated_at`	ISO 8601 datetime	Timestamps.
`city`, `country`, `county`, `postal_code`, `street_name`, `street_number`	String	Address parts. `null` when unknown.
`formatted_address`	String	The most specific address available.
`display_times`	Array	Datetimes to show the passenger.
`lat`, `lng`	Number	Coordinates.
`location_name`	String	The location name.
`station_id`	String	The requested station, when there is one.
`time`	Datetime	The requested time.
`waypoint_type`	Enum string	`origin` or `destination`.
`formatted_street`	String	Deprecated. A formatted address string.

A public transport stop describes a public transport leg endpoint:

Field	Type	Meaning
`city`, `country`, `county`, `postal_code`, `street_name`, `street_number`	String	Address parts.
`formatted_address`	String	The most specific address available.
`location_name`	String	The stop name.
`lat`, `lng`	Number	Coordinates.
`display_times`	Array	Datetimes to show the passenger.
`dhid`	String	The stop’s public transport identifier.
`hafas_ext_id`	String	The stop’s external public transport identifier.
`scheduled_arrival`, `scheduled_departure`, `scheduled_platform`	Datetime / String	The scheduled arrival, departure, and platform.
`current_arrival`, `current_departure`, `current_platform`	Datetime / String	The real-time arrival, departure, and platform. `null` when no real-time data is available.

When multiple booking solutions is on, the array is shaped by three limits: a maximum number delivered per solution type (on-demand, intermodal, and public transport), an overall maximum delivered, and the order in which solution types are merged.

Preserve matching logs

Permissions: manage_matching_logs

Matching logs are kept for 30 days and then removed automatically. To keep a specific ride’s matching logs beyond that — for example, to investigate a matching decision later — preserve them.

From the ride’s ⚙️ dropdown menu:

Preserve matching logs flags this ride’s matching logs so they’re excluded from the automatic cleanup and kept indefinitely.
Unpreserve matching logs removes the flag, so the logs are subject to the 30-day retention again.

The dropdown reflects the current state. It offers Unpreserve matching logs (with a check mark) when the logs are already preserved, Preserve matching logs when they aren’t, and a note when the ride has no matching logs at all.

Preserving and unpreserving matching logs is gated by its own manage_matching_logs permission. This changed recently: the action used to be tied to update_rides, so anyone who could edit rides could also preserve logs. It now has a dedicated permission that can be granted independently of ride editing, so the ability to keep logs can be handed out on its own. Super Admins always have it.

Request & Matching Details

The Request & Matching Details tab gives a summary of how the ride was planned and how it actually happened by comparing initially calculated pickup and dropoff times and the initially calculated ride duration with the actual times. Specifically, the following fields are shown.

Ride/Matching Created at
Initially Calculated Pickup At
Initially Calculated Dropoff At
Initially Calculated Ride Duration
Actual Pickup Completed At
Actual Dropoff Completed At
Actual Ride Duration
Initially set up delayed dropoff buffer (Max. Hostage Duration): This shows the difference between negotiation_time_max and negotiation_time (in minutes). If one or both values are missing, it displays “n/a” instead.
Requested Time Window
Initially Negotiated Time Window
Currently Calculated Time Window

Public Transport Alternatives

Permissions: read_rides

If the product feature Public Transport Alternatives is active, this tab lists every public transport alternative (PTA) that ioki Platform calculated for the ride, grouped and ranked, so you can retrace which alternatives were offered and why each was kept or discarded.

A PTA is an external public transport journey between two points at a given time. It is used either as a full alternative to the on-demand ride or as a feeder for the first or last part of the trip. Each PTA is summarized by the same key figures: waiting time, walking time, travel time, overall time, and the number of asset (vehicle) changes. For the concept and how alternatives are ranked, see Public Transport Alternatives.

When alternatives have not been fetched

If alternatives have not been requested for this ride yet, the tab shows a warning instead of a list. Once they have been fetched, a summary line reports the adapter that was queried, the time of the search, and how many alternatives came back.

Application types

Alternatives are grouped by application type, because a PTA can play one of three roles for the ride:

end_to_end. A complete public transport journey from the ride’s origin to its destination, offered as an alternative to the on-demand ride.
feeder_first_mile. A public transport leg that brings the passenger from their origin to a feeder station, from where the on-demand ride continues.
feeder_last_mile. A public transport leg from a feeder station to the passenger’s destination, after the on-demand ride.

Overview by ranking

For each application type, a table lists the alternatives in ranking order with three columns:

Ranking. The position of the alternative within its group (1 is the best-ranked).
Leg summary. The chain of legs that make up the journey (for example, walk → bus → walk), shown as a sequence of hops.
Result. ✅ if the alternative was accepted, or ❌ together with the reason it was rejected.

An alternative can be rejected for one of the following reasons:

Reason	Meaning
`blocklisted`	The alternative matches a blocklist rule and is excluded.
`waiting_time_too_high`	The waiting time exceeds the configured limit.
`walking_time_too_high`	The walking time exceeds the configured limit.
`travel_time_too_high`	The travel time exceeds the absolute limit.
`travel_time_relatively_too_high`	The travel time is too high relative to the on-demand ride.
`overall_time_too_high`	The overall time exceeds the absolute limit.
`overall_time_relatively_too_high`	The overall time is too high relative to the on-demand ride.
`too_many_asset_changes`	The journey requires more vehicle changes than allowed.
`walking_only`	The alternative is a walk-only journey.
`outdated`	The alternative is no longer current.

Details

Below the overview, each alternative is expanded in full. For every alternative you see a short summary (the leg chain plus overall and waiting time), a leg-by-leg breakdown with the time window and origin and destination of each leg, and the complete stored data record for the alternative.

Ticket

If the product feature Supports Ticketing is active, the information of the corresponding public transport ticket can be found here.