Trip Profiles

Taxi & Private Hire › Products › Trip › Trip Profiles

Generally available

Operator-defined categories that classify trips based on a JSON decision tree (e.g. "School Run", "Medical Transport", "Corporate", "Late-Night"). Profile assignment feeds into downstream behaviour — pricing rules can target a specific profile, dispatch queues can filter on profile, reporting groups trips by profile. Profiles are evaluated per-segment at trip creation/modification time, highest-priority match wins.

Example request

POST /client/{clientId}/tripprofile ▷ Try it

{
  "name": "<string>",
  "priority": 0,
  "matchMode": "ALL",
  "decisionTree": {}
}

Example shape, derived from the TripProfile fields — indicative, not the authoritative schema (that arrives with the API reference).

Endpoints

Method	Path
POST	/client/{clientId}/tripprofile · primary	▷ Try it
DELETE	/client/{clientId}/tripprofile/{tripProfileId}	▷ Try it
GET	/client/{clientId}/tripprofile/{tripProfileId}	▷ Try it
POST	/client/{clientId}/tripprofile/{tripProfileId}	▷ Try it

Full request/response schemas and an interactive explorer will live in the API reference (coming soon).

Use cases

Operator flows that exercise this feature.

Save a trip template

config risk: low

Save a reusable trip profile (accounts, route, capabilities) for fast re-booking.

1. POST /client/{clientId}/tripprofile

Related

• Trips
• Backup Zones
• Pricing Modifiers

Fields

Field	Type	Description
name	string	Display name for the profile ("School Run", "Medical Transport", "Late-Night"). Surfaced on the operator dispatch board + pricing-rule editor.
priority	smallint	Match priority. When multiple profiles' decision-trees evaluate true for the same segment, the lowest-priority profile wins. Lets specific profiles override generic ones.
matchMode	TripProfileMatchMode · ALL | ANY	How multiple matching profiles compose: ALL (segment can carry several profiles), or single-mode (only the highest-priority match attaches). Drives downstream pricing + dispatch behaviour.
decisionTree	JsonStorage	JsonCondition decision tree evaluated per-segment at creation / modification. Returns boolean — true means the segment carries this profile.
clientId	bigint	Tenant scope. Every tenant-aware entity carries this; `ClientFilter` enforces row-level isolation on read; the multi-tenancy routing layer (`/client/{clientId}`) sets it at create time. Surfaced only under `admin` / `tripLog` groups — never to end users.
internalKey	string	Optional client-supplied external reference / idempotency key. When present, lets external systems correlate platform-side records back to their own source-of-truth ids. Not persisted to a column — populated by the request handler when the caller sets it.
__objectType	string	Discriminator string (entity class short-name) emitted alongside the id in serialized output. Resolved at read time by `getObjectType()`; lets the FE dispatch entity-specific rendering without inspecting the URL.
id	bigint	Snowflake-style primary key (unsigned BIGINT). Generated by `IdFactory` at create time; surfaced to the FE / API as a `G`-prefixed string and stripped back to plain bigint server-side before Doctrine lookup.
createdDate	integer	Unix timestamp the row was first persisted. Set in the entity's PrePersist hook; never rewritten on subsequent updates.
updatedDate	integer	Unix timestamp the row was last touched. Bumped on every commit that hits the Doctrine UoW for this entity; drives FE invalidation + the listing change cursor.
passiveUpdatedDate	int	Read-through alias for `updatedDate` exposed under different serializer groups. Lets the FE distinguish "real edit" from "background touch" projections without changing the underlying column.
listingUpdatedDate	int	Listing-projection timestamp surfaced only under the `listMode` group. Driven by `TripCache` and other listing-shape refreshers separately from `updatedDate` so a listing rebuild doesn't trigger detail-page invalidation.