Search across 390 schema types in the Beckn Protocol registry.
Payment methods accepted by a payee
Live-priced offer attributes for one room-rate combination within a 20-minute search session.
Booking lifecycle record for an accommodation reservation on the ONT network.
Static catalog attributes for an accommodation unit type at a property. Carries no pricing or live availability.
New v2.0 Ack format carrying an HTTP Counter-Signature proving the receiver authenticated, received, and processed the inbound request.
Request received but no callback will follow (e.g. agents not found, inventory unavailable, provider closed, context.try preview complete).
Schema definition for AckResponse in the Beckn Protocol
A digitally signed authentication credential transmitted in the HTTP `Signature` response header on every synchronous Beckn response, proving that the responding NP received and authenticated the specific inbound request. The responding actor produces this by signing a four-line canonical signing string with its Ed25519 private key: (created): {unix_timestamp} (expires): {unix_timestamp} digest: BLAKE2b-512={base64_response_body_hash} request-signature: {incoming_request_raw_base64_signature} The fourth line (`request-signature`) contains the raw Base64 Ed25519 signature value extracted verbatim from the `signature="..."` field of the incoming request's `Authorization` header. This binds the Ack cryptographically to the specific signed request that triggered it. The `headers` attribute MUST be `"(created) (expires) digest request-signature"`. The `keyId` identifies the responding NP. The algorithm MUST be `ed25519`. The body digest covers the response body using BLAKE2b-512. Used for: all synchronous HTTP responses across all Beckn endpoints. For request signing, see Signature. For PN solicited callback signing, see CallbackSignature. See NFH-004 Authentication and Trust §5 for the full response signing procedure.
Add-on to a catalog resource
**Postal address** aligned with schema.org `PostalAddress`. Use for human-readable addresses. Geometry lives in `Location.geo` as GeoJSON.
A reference to a transport line that is affected by a service disruption or alert.
Schema definition for Alert in the Beckn Protocol v2.0.1
An optional or additional service available for purchase alongside base transport, such as extra baggage or lounge access.
Error returned asynchronously during a callback. Wraps the base `Error` schema with JSON-LD type annotations to allow linked-data processing.
JSON-LD aware container for domain-specific attributes of an Item. MUST include @context (URI) and @type (compact or full IRI). Any additional properties are allowed and interpreted per the provided JSON-LD context.
A governmental or administrative body responsible for planning, regulating, and overseeing transport services within a jurisdiction.
The quantity and weight of baggage a passenger is permitted to carry or check in without incurring additional charges.
Pagination state for a single message in a multi-message collection delivery. Sibling to the paginated array, NOT a wrapper around it.
Sidecar array — one entry per signal the seller commits to report.
Reference to a content-addressed, BPP-hosted JSON document. Receivers fetch `uri`, canonicalize the body per JSON Canonicalization Scheme (RFC 8785), compute SHA-256, and reject on mismatch with `contentHash`.
A time-series payload. `intervalPeriod` sets the default temporal bounds; each `interval` carries one or more typed `payloads` (valuesMap rows). `payloadDescriptors` declare units/currency/ reading-type for each `payloadType` referenced in the rows; every type used in `intervals` SHOULD be declared in `payloadDescriptors`. `payloadType` follows OpenADR's open-string convention — consumer profiles (e.g. `DemandFlexPerformance`) MAY restrict it to a domain-specific set and add cross-field membership checks.
An indicator specifying whether bicycles are permitted on board a particular route or vehicle journey.
A set of rules governing how and when a demand-responsive transport service must be booked in advance.
Schema definition for Buyer in the Beckn Protocol
DEPRECATED. This schema is structurally invalid and does not validate any payloads — the oneOf keyword was incorrectly nested inside properties, which is not valid JSON Schema. The $id also lacked a version segment. Use https://schema.nfh.global/BecknAction/v2.0 instead. BecknAction is the unified envelope for all Beckn actions (both request and callback directions). Callback actions are those with on_ prefixed endpoints (e.g. beckn/on_discover, beckn/on_confirm) and are validated by the same BecknAction schema via if/then dispatch on context.action. This schema will be removed in a future major version.
A digitally signed authentication credential transmitted in the HTTP Authorization header of PN solicited callbacks to CN `/on_*` endpoints. Extends the standard Signature by chaining the PN's signature to the CN's original request signature, allowing the CN to verify that the callback is a genuine response to a request it sent. The PN produces this by signing a four-line canonical signing string with its Ed25519 private key: (created): {unix_timestamp} (expires): {unix_timestamp} digest: BLAKE2b-512={base64_callback_body_hash} request-signature: {cn_raw_base64_signature} The fourth line (`request-signature`) contains the raw Base64 Ed25519 signature value extracted verbatim from the `signature="..."` field of the CN's original `Authorization` header. This binds the callback cryptographically to the triggering request. The `headers` attribute MUST be `"(created) (expires) digest request-signature"`. The `keyId` identifies the PN signer. The algorithm MUST be `ed25519`. The body digest covers the callback body using BLAKE2b-512. Used for: PN→CN solicited callbacks only. For PN-initiated notifications (no preceding CN request), use the standard Signature schema instead. For synchronous response signing, see components/headers/AckSignatureHeader. See NFH-004 Authentication and Trust §6 for the full callback signing procedure.
Beckn /beckn/cancel message payload. Sent by a BAP to a BPP to request cancellation of an active contract. Set context.try to true to first retrieve cancellation terms and fees before committing. (Context wrapper stripped; only the message-content portion is inlined.)
Schema definition for CancellationOutcome in the Beckn Protocol v2.0.1
Schema definition for CancellationPolicy in the Beckn Protocol v2.0.1
Schema definition for CancellationReason in the Beckn Protocol v2.0.1
Binding cancellation policy confirmed at the pre-commit check. Normalises Format 1 (hours-based) and Format 2 (datetime windows) into one vocabulary. Also used for cancel quote in on_cancel_quote.
Domain-specific extension attributes for a candidate availability offer. Defines when and how a candidate is available for engagement, rate expectations, and terms the employer BAP must meet to initiate hiring.
A single skill entry with optional VC attestation. Supports graceful degradation: attested=false for self-declared skills, attested=true with proof_request_url for VC-backed skills.
A value governed by an external classification authority, e.g. ISIC industry codes, NSQF qualification levels.
Domain-specific extension attributes for a candidate profile resource. Describes professional background, skills, preferences, and availability for employer discovery. Zero PII — no name, contact, or identity fields. preferred_location and current_location use the shared hiring-common JobLocation type (supports both city/region text and GeoJSON geo-spatial queries) rather than an inline CandidateLocation sub-schema, ensuring consistent location semantics across job listings and candidate profiles. relocation_willing is a direct property (not nested inside location) so it remains independently queryable by BAPs without unpacking the location sub-object.
A Carrier is a transport service provider responsible for moving goods across distances. Carriers operate fleets of vehicles and may own/manage logistics hubs. Maps to beckn:Provider.
A structured representation of the resources, offers, and provider information that a PN makes available on the network for discovery, selection, and commitment by CNs. Catalogs appear in the discovery phase of the value-exchange lifecycle. The PN produces them and publishes them to the CS (Cataloging Service) via CatalogPublishAction; the CS indexes them and synchronizes them to the DS, which serves them to CNs in OnDiscoverAction responses. Fabric context: Catalogs are managed by the CS, which indexes them for discovery and synchronizes them to the DS for delivery to subscribing CNs. The CS also stores and serves canonical master catalog items. Relationship: Composes Provider, Resource, and Offer schemas. MUST include at least one of a resources array or an offers array. The validity field constrains the temporal window during which the catalog is active, expressed as a TimePeriod.
Catalog publish processing results from CDS to BPP.
Processing result for a single catalog submission.
Catalog publish request payload.
Beckn /beckn/on_catalog_publish message payload. Sent by a CDS back to a BPP after processing a catalog publish request. Contains per-catalog processing results indicating success, failure, or partial indexing.
Message payload for catalog/pull This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
The real-world act by which the CS (Cataloging Service) delivers the results of a previously accepted /catalog/pull request to the subscriber's (DS) /catalog/on_pull callback endpoint. This schema appears in the Catalog Pull phase. The CS produces it as the message payload of the async callback; the subscriber (DS) consumes it to retrieve the requested catalog data. Fabric context: Produced by the CS after processing the pull request. When the result is small it is returned inline in `catalogs`; when the result is too large to return inline the callback carries a `downloadManifest` for downloading the result. Relationship: Composed as the message payload of the /catalog/on_pull callback. The DS MUST use context.messageId to correlate this callback with the originating /catalog/pull request.
The real-world act by which a caller queries the CS (Cataloging Service) for indexed catalogs, applying optional catalog type, network, and schema type filters with pagination control. This schema appears in the Catalog Search phase. The PN produces it as the message payload of a POST /catalog/search request; the CS consumes it to filter and return matching catalogs with pagination metadata. Fabric context: Processed by the CS, which queries its catalog index and returns matching items synchronously. Relationship: Composed as the message payload of the /catalog/search request body.
Message payload for catalog/subscription. At least one of `networkIds` or `schemaTypes` must be non-empty. An empty `schemaTypes` array is treated as the wildcard sentinel `"*"`, matching all schema types for the specified networks.
Full subscription record
The response envelope returned synchronously by the CS (Cataloging Service) for subscription management operations — create, update, list, and deactivate. This schema appears in the Catalog Subscription phase. The CS produces it as the synchronous response to POST /catalog/subscription (creation or update), GET /catalog/subscription (listing), and DELETE /catalog/subscription (deactivation). The DS consumes it to confirm subscription state. Fabric context: Produced synchronously by the CS; no async callback is delivered for subscription management operations. The context.action is always catalog/on_subscription. Relationship: Composes one or more CatalogSubscription records in the message.subscriptions array, and an optional Pagination object for list responses.
Schema definition for CategoryCode in the Beckn Protocol v2.0.1
The checkout terminal where the consumer makes the payment
A channel through which communication or support takes place. The enumerated values are derived from SupportInfo.channels (https://schema.nfh.global/SupportInfo/v2.0).
Beckn /beckn/confirm message payload. Sent by a BAP to a BPP to confirm a contract, finalising the transaction terms agreed during the select-init negotiation cycle. (Context wrapper stripped; only the message-content portion is inlined.)
Generalized representation of value exchanged under a Contract. Consideration is domain-neutral and may represent: - Monetary value - Credits / tokens - Asset transfer - Service exchange - Compliance artifact
A Consignment is a collection of packages or shipments grouped together under a single commercial transaction between a shipper and consignee. Maps to beckn:Order.
Schema definition for Constraint in the Beckn Protocol v2.0.1
Schema definition for Consumer in the Beckn Protocol v2.0
Contact information for sender, receiver, driver, or operator.
The message envelope header that accompanies every Beckn API call, carrying network addressing, protocol version, action identification, transaction correlation identifiers, timing constraints, and optional cryptographic metadata required to route, authenticate, and correlate messages across the asynchronous Beckn communication pattern. Context appears in every request and callback across all phases of the value-exchange lifecycle. The CN assigns bapId, bapUri, transactionId, messageId, and timestamp when originating a request; the PN assigns bppId and bppUri when it is the receiving actor. Fabric services such as the CS (Cataloging Service) and DS (Discovery Service) validate the version, action, and signature fields as part of request authentication. Relationship: Composes the RequestDigest schema via the requestDigest property, which carries the BLAKE2b-512 hash of the originating request body for non-repudiation of the asynchronous callback leg.
This is a JSON-LD compliant, linked-data schema that specifies a generic multi-party, digitally signed Contract between a set of participants. based on the vocabulary defined in the @context. By default, it is the most generic form of contract i.e beckn:Contract. However, based on the mapping being used in @context, it could take values like retail:Order, mobility:Reservation, healthcare:Appointment, and so on, which will be defined as sub-classes of beckn:Contract. Alternate description A digitally agreed commitment between two or more participants governing the exchange of economic or non-economic value. Contract is the canonical contract object in the generalized Beckn v2.1 protocol. It replaces the commerce-specific Order construct as the canonical transaction object at the API layer. A Contract binds: - Commitments (what is agreed) - Consideration (value promised) - Performance (how execution occurs) - Settlements (how consideration is discharged) The model is domain-neutral and supports commerce, hiring, energy markets, carbon exchanges, data access, mobility, subscriptions, and other use cases.
A line item within a Contract, linking an accepted Offer and ordered Item with quantity and price.
A signed receipt transmitted in the synchronous `Ack` response body, proving that the receiver authenticated, received, and processed the inbound request. `CounterSignature` shares the same wire format as `Signature` but differs: - **Signer**: the response receiver (not the request sender) - **Location**: transmitted in the `Ack` response body (not in the `Authorization` header) - **`digest`**: covers the Ack response body (not the inbound request body) - **`(request-digest)`** and **`(message-id)`** MUST be included in the signing string Signing string format: ``` (created): {unixTimestamp} (expires): {unixTimestamp} digest: BLAKE-512={base64DigestOfAckBody} (request-digest): BLAKE-512={base64DigestOfInboundRequestBody} (message-id): {messageId} ```
A Courier is an individual delivery agent responsible for last-mile pickup and delivery of packages, typically in hyperlocal or urban delivery contexts. Maps to beckn:Agent.
Commercial and availability terms under which a course is offered. The proposedConsideration on the core Offer carries the headline fee; this extension provides pricing type context and enrollment window.
Intrinsic attributes of a training course or program Resource. Domain-generic: applicable to any skilling vertical — vocational training, professional certification, higher education, government skill schemes, etc.
A credential artifact that is either (a) a W3C Verifiable Credential (opaque JSON object) or (b) a document attachment reference requiring manual/offline verification.
A single credential requirement or prerequisite. Specifies what a candidate or enrollee must hold. Category is a broad class; subtype is the specific credential within that class.
PII section — fullName, installationAddress, serviceConnectionDate. fullName appears ONLY here — never in customerProfile or resource entries. Defined in CustomerDetails/v1.0.
Attributes for digital dataset fulfillment attached via beckn:deliveryAttributes.
Dataset metadata aligned with schema.org Dataset plus Beckn dataset extensions.
A classification of a day (e.g., weekday, weekend, public holiday) used to define when a service pattern is valid.
Callback delivery retry configuration This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
A DeliverySlot is a time window offered or agreed upon for delivery of a shipment. Maps to beckn:TimeSlot.
Buyer-authored demand-flex procurement schedule as an OpenADR-aligned time series — one interval per tranche. This is the single, unified Need shape for every demand-flex market, from full price discovery (uc2 pay-as-clear auction: many aggregators bid, market clears) down to its monopsony degenerate (uc1: a single buyer, the DISCOM, fixes one clearing price for any quantity — a flat, self-cleared curve). The column set is intentionally NOT fixed by this schema. Each market profile carries different columns, and the governing CONTRACT POLICY REGO imposes the exact required set as a hard const: uc1 (deg.contracts.demand_flex) — CAPACITY_REQUESTED, PRICE, SHORTFALL_PENALTY uc2 (deg.contracts.demand_flex_pac) — CAPACITY_REQUESTED
Performance attributes for demand-flex M&V (Measurement & Verification). Attached to Performance.performanceAttributes in on_status callbacks.
A real-time message containing predicted departure times for vehicles at a stop, as used in VDV real-time standards.
Schema definition for Descriptor in the Beckn Protocol v2.0.1
The direction of travel of a transport service along a route, typically expressed as inbound or outbound.
Beckn /beckn/discover message payload as published at schema.nfh.global. Requires all discover qualifiers to be nested inside an `intent` container object. (Context wrapper stripped; only the message-content portion is inlined.)
Schema definition for DisplayedRating in the Beckn Protocol v2.0.1
A Dispute is a formal disagreement raised by one node (the claimant) against another (the respondent) over any piece of information published on the network. Anything can be disputed — a Contract, an Invoice, a Settlement, a Performance, a Consideration, contract terms, or any other published object. A dispute itemises one or more cases, each backed by a reason and supporting evidence, and tracks its lifecycle from unresolved through to resolved or withdrawn. Resolution is a tri-party process - the claimant and respondent agree on a neutral online dispute resolution (ODR) provider. A Dispute is exchanged over the dispute / on_dispute endpoints, wrapped in a DisputeAction. It may be created, updated, status-tracked, and cancelled (withdrawn).
Container for the dispute / on_dispute messages exchanged between nodes. A DisputeAction carries the Dispute object being created, updated, status-tracked, or cancelled (withdrawn). The action being performed is conveyed by the endpoint (dispute / on_dispute) and the lifecycle state of the carried Dispute.
A document, that can be parsed, printed, download or displayed. This has intentionally been kept separate from MediaFile as they may contain additional attributes like signature, schema etc.
A person who operates a transport vehicle and is responsible for the safe delivery of passengers during a mobility service trip.
Driver-specific extension of CandidateProfileResource. Adds driver role types, vehicle categories, home location (using shared JobLocation), reputation summary, credential summary, training summary, and stage-gated passport reference. Inherits all generic candidate profile fields from CandidateProfileResource. Contains zero PII — identity managed at beckn:parties level.
Driver-specific extension of HiringJobResource. Adds role type, required vehicle categories, credential requirements, and training requirements. Inherits all generic job fields (job_title, job_type, work_mode, location, shift_type, working_hours, contract_duration, experience_level, etc.) from HiringJobResource — only driver-domain delta properties are defined here.
A set of rules governing the locations and conditions under which passengers may be dropped off at the end of a ride-hailing or on-demand transport service.
External identity reference for the customer. Defined in IdRef/v1.0.
Discriminated union of all typed EnergyResource kinds. Dispatched by the 'type' field. Each kind lives in its own schema at schema.nfh.global/<Kind>/v1.1. EnergyResourceCommon (id, type, subResources, parentResources, attributes) and EnergyResourceCommonAttributes (make, model, ratedPower, maxExport, maxImport, telemetryProvider, commissioningDate, location) are defined in EnergyResourceCommon/v1.1 and inherited by all kinds via allOf external $ref.
Schema definition for Eligibility in the Beckn Protocol v2.0.1
A critical safety or operational event requiring immediate response, such as an accident, vehicle breakdown, or passenger emergency.
Domain-specific extension attributes for an employer hiring contract. Records the agreed engagement terms, hiring stage, start date, and verification outcomes for the candidate hired.
Verifiable Credential containing aggregated billing period data using ESPI/Green Button types (UsageSummary, SummaryMeasurement, LineItem). Subclass of EnergyCredential. The credential subject combines a customer profile with billing summary data within a W3C VC 2.0 envelope.
ESPI/Green Button billing summary data for a single meter. Uses native ESPI types and enum codes.
Core customer identity for energy credentials — links a utility account to a physical meter.
ESPI/Green Button meter reading data for a single meter. Uses native ESPI types and enum codes.
Structural envelope inherited by every typed EnergyResource kind via allOf. Defines top-level fields common to all kinds: id, type, topology (subResources, parentResources), and the attributes bag.
Order attributes for P2P energy trading. Attached to Order.orderAttributes to identify BAP and BPP participants involved in a trade. NOTE: Utility IDs for inter-discom trading are captured in EnergyCustomer (buyerAttributes.utilityId and providerAttributes.utilityId).
Fulfillment attributes for energy trade deliveries. Attached to orderItemAttributes.fulfillmentAttributes to track physical transfer of energy including delivery status, meter readings, and energy allocation data. consumedEnergy = energy TO customer (imported), producedEnergy = energy FROM customer (exported to grid).
A contractually granted, policy-governed right that allows a specific party to access, use, or claim a defined economic resource within stated scope and validity constraints. It represents the enforceable permission created by an order, independent of the credential used to exercise it.
A selector that identifies which transport entities (routes, trips, stops, or agencies) are affected by a given alert.
Schema definition for Error in the Beckn Protocol v2.0.1
Canonical Beckn Protocol v2 error code enum. The prefix indicates the protocol stack layer at which the error originated. Error.code MUST be one of these values. Defined by NFH-008 (Handling Exceptions and Errors).
Schema definition for ErrorResponse in the Beckn Protocol v2.0.1
A real-time data delivery providing predicted departure and arrival times for a set of vehicle journeys.
Locations in a transport network where fixed-route and flexible services connect, enabling passenger interchange.
The monetary cost of travel for a specific journey or service, calculated based on applicable fare rules and passenger categories.
A detailed breakdown of the total fare into its constituent components, including base fare, taxes, surcharges, and discounts.
A component of an air travel fare that applies to a specific flight segment or leg, used in aviation pricing.
An estimated fare for a requested trip, typically returned in response to a search before the booking is confirmed.
A rule defining how a fare is applied to a single leg of a journey based on origin, destination, network, and time.
The physical or digital medium used to carry or present a fare product, such as a contactless card, mobile app, or paper ticket.
A purchasable entitlement to travel defining conditions of use, validity, and applicable passenger categories.
The calculated fare for a requested trip, returned as part of a trip planning or fare enquiry response.
A rule defining how fares from different legs are combined when a passenger makes a transfer between services.
A data publication providing transit or mobility information in a standardised format for consumption by applications or planners.
A single non-stop flight operated between two airports, forming a unit of an air travel itinerary.
Describes a form
A user's submitted response to a Beckn form. Captures the filled-in field values keyed by form field names. Typically attached to a RatingInput to convey feedback form answers alongside a rating.
A headway-based service specification indicating how often a vehicle runs on a route within a given time window.
Schema definition for Fulfillment in the Beckn Protocol v2.0.1
The entity directly involved in fulfilling the order. It could be a person, an organization, a machine, a software application, or an AI Agent.
Describes the mode of fulfillment. This is an extensible container allowing domain-specific fulfillment modes to be expressed via attributes.
Schema definition for FulfillmentStage in the Beckn Protocol v2.0.1
A credential/document/proof relevant to authorization at a fulfillment stage endpoint. This may be a token to be verified (QR/OTP/URL) or a document to be inspected manually.
A stage boundary endpoint (entry or exit) within a fulfillment, such as pickup, handover, warehouse in/out, border crossing, gate entry/exit, security check, etc. May require one or more proofs/permits/tokens/documents.
A specific location associated with a fulfillment (trip or journey) at which passengers board, alight, or transfer between services.
A real-time delivery of textual messages or alerts related to service disruptions or passenger information.
Minimal GeoJSON geometry fragment. Supports Point, Polygon, and other GeoJSON geometry types as used by Beckn SpatialConstraint operators.
A virtual geographic boundary used to define service areas, restricted zones, or operational boundaries for mobility assets.
A virtual geographic boundary used to define operational areas, speed limits, parking rules, or restrictions for shared mobility services.
Per-room guest manifest for an accommodation booking. Contains PII. Bound to a single commitment (one room); the commitment structure provides the room context.
Commercial and contractual terms under which a job vacancy is offered. Uses SalarySpecification from hiring-common for structured salary data (supports ranges and multiple currencies/periods in a single sub-object). Duration fields (probation_period, notice_period, contract_duration, offer_validity) use ISO 8601 duration strings (e.g. P3M, P1Y) rather than integer-day counts, enabling unambiguous machine processing across calendar systems and localisation requirements. insurance_provided and accommodation_provided are explicit booleans here (not buried in a benefits list) because they are primary filtering criteria for many hiring verticals (transport, construction, hospitality).
Intrinsic metadata about a job vacancy. Compensation terms live in HiringJobOffer. JobLocation is sourced from hiring-common to support both city/region text filters and GeoJSON spatial queries — see hiring-common/JobLocation for design rationale. Shift and schedule fields are placed here rather than in the Offer because they describe the nature of the work, not the compensation package, and must be visible at discovery (on_discover) for effective job-seeker filtering.
Domain-specific extension attributes for a single hiring process performance step. Records what was done, when, by whom (role only, not identity), and the outcome. Zero PII.
A Hub is a logistics fulfillment center, sorting facility, or distribution point where goods are consolidated, sorted, and dispatched for onward delivery. Maps to beckn:Location.
A Beckn domain schema for hyperlocal (same-city, typically sub-2-hour) physical delivery of goods or prepared food from an origin to a destination within a short radius. HyperlocalDelivery is a concrete, domain-specific fulfillmentAttributes value for a beckn:Fulfillment entry. It is fully aligned with schema:ParcelDelivery. schema.org alignment: schema:ParcelDelivery (subtype of schema:Intangible) Use in: beckn:Fulfillment.fulfillmentAttributes
A reported event on the transport network that affects normal service operations, such as a disruption, roadblock, or infrastructure failure.
Beckn /beckn/init message payload. Sent by a BAP to a BPP to initialise a contract with consumer details (billing address, fulfillment preferences, etc.). (Context wrapper stripped; only the message-content portion is inlined.)
Schema definition for Instruction in the Beckn Protocol v2.0.1
A declaration of an intent to transact
A planned transfer connection point where passengers switch between two or more transport services, with defined timing constraints.
An Invoice is a financial statement issued by a creditor to a debtor that itemises the amounts owed and records how they are settled. Each line item is a billed financial entry — an order, refund, commission, finder fee, or adjustment — rather than a product or service. The invoice tracks its lifecycle status, the agreed settlement terms, and the proofs of settlement (payment actions) that discharge the amount due. An invoice may be issued, updated, settled, cancelled, or disputed over its lifecycle.
Schema definition for Item in the Beckn Protocol v2.0.1
A complete planned trip containing an ordered sequence of legs, including transfer points, durations, and timing.
A component of an aviation itinerary such as a flight segment, ground transport leg, or ancillary service.
Pipeline state and lifecycle metadata for a job application contract. Models the full arc from application submission through offer acceptance to onboarding. Structured document tracking (submitted_documents) replaces free-text document notes to enable automated checklist verification. The offer_status and onboarding_status fields are explicit enumerations so BAP and BPP can drive workflow state machines without parsing free text. employee_id is disclosed only post-acceptance (MUST NOT appear before ACCEPTED stage).
Performance attributes for evaluation steps in a hiring contract. lifecycle_stage is a free string (not an enum) so that each network can define its own stage vocabulary without requiring a schema update — the base protocol remains stable while networks extend freely. The evaluation_steps array replaces the single-step model, enabling a BPP to report multiple completed steps in one on_update message and supporting multi-step assessment pipelines (e.g. CV review → telephonic → technical → driving test) within a single Performance object. Legacy single-step fields (screening_type, scheduled_at, etc.) are retained for backward compatibility with v2.0 implementations.
Flexible hiring location. Supports city/region text filtering (most common use case) and GeoJSON geo-spatial queries. Either geo or at least one address field must be present; both may coexist for richer indexing.
A complete travel itinerary from origin to destination, potentially comprising multiple legs using different transport modes.
A single uninterrupted segment of a journey made using one transport mode or service between two consecutive locations.
A floor or vertical level within a multi-level transit station or facility, used to define internal navigation paths.
A named, branded public transport service identified by a number or name, typically operating over one or more routes.
A causal attribution record asserting that the Beckn transaction in which this entry appears was triggered by a specific upstream Beckn interaction. Used in Context.lineage at transaction boundaries — when a new transaction is initiated as a direct consequence of an upstream interaction. MUST NOT be included within subsequent steps of the same transaction, and MUST NOT be propagated by downstream responses.
A generic, domain-agnostic collection of elements. Each element carries an id, a descriptor, and an extensible listElementAttributes bag. The order property indicates whether the elements are ranked ascending, descending, or are unordered. List is designed to be extended by more specific list types.
A place represented by GeoJSON geometry and optional address. Source: main/schema/core/v2/attributes.yaml#Location
A set of geographic locations (stops or areas) that can collectively serve as an origin or destination for flexible transit services.
An association between a stop and a location group, used in flexible transit service planning.
A request for details about a specific geographic location, stop, or point of interest in the transport network.
An Alert is a notification or warning related to a shipment, such as delays, exceptions, damage reports, or SLA breaches. Maps to beckn:Event.
Defines terms under which a shipment booking can be cancelled.
A Driver is an individual who operates a vehicle for logistics delivery. Drivers are assigned to shipments and responsible for physical transport. Maps to beckn:Agent.
Total cost charged for a logistics service including base freight, surcharges, taxes.
A single line item in the fare breakup for a logistics service.
Qualitative feedback from sender or receiver about a logistics experience.
Entity operating a logistics network or fleet, responsible for end-to-end delivery service.
A geographic location relevant to logistics such as origin, destination, hub, or waypoint. Includes structured address and GPS coordinates. Maps to beckn:Location and schema:Place.
A numeric score given by a user for a logistics service, driver, or carrier.
Digital acknowledgment of payment and delivery for a logistics service.
A Route is the planned path for a shipment from origin to destination, potentially passing through multiple hubs and waypoints. Maps to beckn:Journey.
Customer support ticket for shipment issues — loss, damage, delay, or billing.
A Vehicle is a transport asset used for logistics operations. Vehicle types range from bicycles for hyperlocal delivery to heavy trucks for long haul freight. Maps to beckn:Asset.
A Package is a physical unit of goods prepared for transport within a shipment. Maps to beckn:Item.
Proof of delivery or pickup evidence, including photos, signatures, OTP confirmations, or digital receipts. Maps to beckn:Document.
Defines conditions for returning goods and reverse logistics workflows.
A Shipment represents the movement of one or more packages from an origin to a destination. It is the top-level fulfillment entity in a logistics transaction and maps to beckn:Fulfillment.
A TrackingUpdate is a real-time or periodic update on the status and location of a shipment during transit. Maps to beckn:Event.
A Waypoint is an intermediate stop or checkpoint on a logistics route, such as a sorting hub, relay station, or customs checkpoint. Maps to beckn:Stop.
An item that has been reported lost or found in connection with a transport service.
Message payload for catalog/master_search This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
A image, audio, or video typically intended for display purposes
Reference to an image, audio clip, or video used for multimodal search.
How the discovery engine should use the provided media inputs.
Open payload container for Beckn action messages. The specific content of the message object is determined by the action value in the accompanying Context. BecknAction constrains message content based on context.action via if/then dispatch rules. Direct use of this schema provides no payload constraints — use BecknAction for validated action payloads.
Tariff and regulatory load profile for one meter connection point. meterId links to a METER entry in energyResources[]. CIM: UsagePoint (IEC 61968-9).
Attributes for the Mobility entity in the Beckn Mobility domain.
A real-time arrival or departure prediction for a specific vehicle at a specific stop within a monitored journey.
A real-time representation of a vehicle journey being actively tracked, including position and schedule adherence data.
NACK — Bad Request: Malformed or invalid request; the server could not parse or validate the payload.
The synchronous rejection body returned when the request conflicts with existing state — for example, a subscription with the same criteria already exists for this subscriber. NackConflict appears as the response body for 409 responses on synchronous endpoints where the conflict is with persisted resource state, not with callback processing. The implementing actor produces it; the calling actor MUST resolve the conflict (e.g., update the existing resource) before retrying. Relationship: Extends the Ack schema with status constrained to NACK and adds an error field describing the conflict.
The synchronous rejection body returned when a responding NP exercises its protocol-level agency to decline engagement for policy-governed reasons — insufficient caller trust, capacity limits, scheduled inactivity, or general refusal — without an underlying exception in the received message. The caller MUST NOT expect an on_* callback. NackDiscretionary appears as the response body for 403 responses on action endpoints. The responding NP produces it; the calling NP MUST treat it as a terminal response for the current request. NFOs MAY restrict or prohibit discretionary NACKs for specific actions, domain contexts, or transaction lifecycle stages per CON-008-20 in NFH-008. Relationship: Extends the Ack schema with status constrained to NACK and adds an error field whose code MUST be one of the POL_ENGAGEMENT_* discretionary refusal codes.
The synchronous rejection body returned when the caller is authenticated but does not have permission to access or modify the requested resource. NackForbidden appears as the response body for 403 responses. The implementing actor produces it; the calling actor MUST NOT retry without correcting its authorization. Relationship: Extends the Ack schema with status constrained to NACK and adds an error field describing the authorization failure.
The synchronous rejection body returned when the requested resource does not exist in the system. NackNotFound appears as the response body for 404 responses. The implementing actor produces it; the calling actor MUST NOT retry without correcting the resource identifier. Relationship: Extends the Ack schema with status constrained to NACK and adds an error field describing why the resource was not found.
The synchronous rejection body returned when the responding NP has exceeded a request rate limit (AUT_RATE_LIMITED) or a policy-governed engagement capacity limit (POL_NP_CAPACITY_EXCEEDED). The caller MUST apply back-off before retrying. Implementations SHOULD include a Retry-After header on 429 responses. NackTooManyRequests appears as the response body for 429 responses on all endpoints. Relationship: Extends the Ack schema with status constrained to NACK and an error code constrained to the two retryable capacity/rate-limit codes.
Invalid or missing authentication credentials; signature could not be verified.
A grouping of routes and lines operated under a common brand or authority, used for fare and operational management.
Rules governing the consequences and fees applied when a passenger fails to appear for a confirmed transport service booking.
An indicator of the current passenger load level of a vehicle, such as empty, many seats available, or full.
A generalized, cross-domain Offer that captures the terms under which one or more Resources may be committed. Core intent: - Support multiple terms/eligibility/constraints/price points for the same Resource(s) - Support dynamic / on-the-fly offers (e.g., bundling, combinational discounts, eligibility changes, capacity-aware pricing) This mirrors the role of Offer in current Beckn (and schema.org patterns), but keeps the shape minimal and composable via `beckn:offerAttributes`.
Beckn /beckn/on_cancel message payload. Sent by a BPP to a BAP in response to a /beckn/cancel call, returning the contract with status set to CANCELLED and any applicable cancellation outcome. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_confirm message payload. Sent by a BPP to a BAP in response to a /beckn/confirm call, returning the confirmed contract with status set to CONFIRMED. (Context wrapper stripped; only the message-content portion is inlined.)
The on_discover response payload containing matching catalogs.
Beckn /beckn/on_init message payload. Sent by a BPP to a BAP in response to a /beckn/init call, with the updated contract including payment terms and billing confirmation. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_rate message payload. Sent by a BPP to a BAP in response to a /beckn/rate call, optionally returning rating forms to collect structured feedback from the consumer. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_select message payload. Sent by a BPP to a BAP in response to a /beckn/select call, with updated contract terms. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_status message payload. Sent by a BPP to a BAP in response to a /beckn/status call (or as an unsolicited status push), returning the current state of the contract. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_support message payload. Sent by a BPP to a BAP in response to a /beckn/support call, returning support contact details and available channels. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_track message payload. Sent by a BPP to a BAP in response to a /beckn/track call, returning a Tracking handle with the URL and/or WebSocket endpoint for real-time fulfillment tracking. (Context wrapper stripped; only the message-content portion is inlined.)
Beckn /beckn/on_update message payload. Sent by a BPP to a BAP in response to a /beckn/update call (or as an unsolicited update push), returning the updated contract state. (Context wrapper stripped; only the message-content portion is inlined.)
An organization that provides and operates public transport or shared mobility services under a defined service agreement.
Schema definition for Order in the Beckn Protocol
Schema definition for OrderItem in the Beckn Protocol
An organization such as a company, non-profit, or governmental institution. Modeled after schema.org/Organization.
Pagination metadata returned with list responses This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
A person who travels using a transport service and is identified in a booking or travel document.
The measured number of passengers currently aboard a vehicle, used for real-time capacity and load management.
A collection of passengers traveling together as a group, with a group size and a designated lead passenger.
A connection between two points within a transit station (e.g., stairway, elevator, walkway) used for indoor navigation and accessibility routing.
A unique sequence of stops visited by trips on a route, grouping trips with identical stop sequences and timing structures.
Schema definition for Payment in the Beckn Protocol
Schema definition for PaymentAction in the Beckn Protocol v2.0.1
A single payment instruction for an order. Represents one line item in the paymentTerms array of an Order — e.g., a pre-order UPI payment, a cash-on-delivery amount, or an instalment.
Schema definition for PaymentTerms in the Beckn Protocol v2.0.1
Describes when in the order lifecycle a payment flow should be triggered. Typically useful for initiating checkouts and settlement flows.
Generalized execution/performance unit. This is where downstream objects bind: - Fulfillment-like details (where/when/how) - Tracking handles - Support touchpoints - Status updates A minimal envelope that carries identity, status, and a performanceAttributes bag that holds the concrete domain-specific delivery schema. Domain specification authors can attach rich context and types via `performanceAttributes`. For example, Hyperlocal delivery details (pickup/delivery locations, items shipped, agent, etc.) are placed inside performanceAttributes using a well-known domain schema such as HyperlocalDelivery. Use the generic Attributes schema when no well-known domain schema exists.
A person (alive, deceased, or fictional). Modeled after schema.org/Person.
A designated location used as a pickup or dropoff point for passengers in a ride-hailing or demand-responsive transport service.
A set of rules governing the locations and conditions under which passengers may be picked up for a ride-hailing or on-demand transport service.
A request for a specific accommodation or seat assignment within a transport service during the booking process.
A journey planning response containing one or more itinerary options for a given trip request.
The output of a MaaS platform planning request, listing available transport options for a requested trip.
Schema definition for Policy in the Beckn Protocol v2.0.1
A single line item within a PriceSpecification breakup, such as a base charge, tax, delivery cost, discount, fee, or surcharge. Beyond the monetary amount, a PriceComponent MAY carry a JSON-LD componentAttributes bag that richly describes why the component applies, how it is calculated, and any governing terms. This lets a receiving node render or act on the line without performing any price computation of its own.
Schema definition for PriceSpecification in the Beckn Protocol v2.0.1
Schema definition for ProcessingNotice in the Beckn Protocol v2.0.1
A real-time prediction of a vehicle's arrival or departure time at a stop, including an indication of prediction confidence.
A registered entity on the Beckn network that makes resources and offers available through one or more catalogs, operating from one or more physical or virtual locations. Providers appear in the discovery phase of the value-exchange lifecycle as part of a Catalog, and persist through the negotiation phase as the counterparty identified in Offers. The PN produces provider records; the CN consumes them to identify and display the source of the resources and offers being considered. Relationship: Composed within the Catalog and Offer schemas. The availableAt field composes one or more Location schemas representing the provider's physical operating sites. The providerAttributes field extends the core schema with domain-specific attributes via the Attributes schema.
JSON body of `GET /catalog/pull/result/{requestId}/catalogs.json`. Same structure as the inline `catalog` array in the callback payload — a list of distribution-envelope catalog objects. This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
Schema definition for Quantity in the Beckn Protocol v2.0.1
A specific platform, bay, or boarding area within a Stop Place at which passengers board or alight from a vehicle.
A price quote generated by a BPP for a specific selection of offers and fulfillment options. Returned in on_select, on_init, and on_confirm responses. Aggregates item prices, taxes, delivery charges, and discounts into a total.
Beckn /beckn/rate message payload. Sent by a BAP to a BPP to submit one or more rating inputs for entities in a completed contract (order, fulfillment, item, provider, agent, support). (Context wrapper stripped; only the message-content portion is inlined.)
Aggregated rating information for an entity. Aligns with schema.org/AggregateRating semantics.
A form designed to capture rating and feedback from a user. This can be used by both BAP and BPP to fetch ratings and feedback of their respective users.
A form designed to capture rating and feedback from a user. This can be used by both BAP and BPP to fetch ratings and feedback of their respective users.
Defines a recurring temporal schedule such as operating hours or serviceability timing windows. Supports day-based recurrence and optional holiday exclusions.
Schema definition for RefundTerms in the Beckn Protocol v2.0.1
Attestation-based reputation capsule. No centralised score — rating_value is attested by the named rating_agency.
DEPRECATED. This schema is structurally invalid and does not validate any payloads — the oneOf keyword was incorrectly nested inside properties, which is not valid JSON Schema. Use https://schema.nfh.global/BecknAction/v2.0 instead. BecknAction is the unified envelope for all Beckn actions (both request and callback directions). The request/callback distinction is encoded in context.action (e.g. beckn/discover for requests, beckn/on_discover for callbacks). This schema will be removed in a future major version.
A cryptographic binding that explicitly ties a callback to the specific inbound request that triggered it. Establishes bilateral non-repudiation for the asynchronous leg of a Beckn interaction. Use `lineage` (on `Context`) for cross-transaction causality. Verification steps: 1. Recompute BLAKE2b-512 digest of the original request body; compare to `digest`. 2. Confirm `messageId` matches the `messageId` from the original request `Context`. This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
A minimal, domain-neutral abstraction representing any discoverable, referenceable, or committable unit of value, capability, service, entitlement, or asset within the network. Examples: - A retail product SKU, a mobility ride, a job role, a carbon credit unit, a dataset/API entitlement, a training course, a clinic service slot. Designed for composability through `resourceAttributes` where domain packs can plug in their specific fields without changing the core.
Container for retail contract attributes (migrated from v2 orderAttributes)
Container for retail performance execution attributes (migrated from v2 fulfillmentAttributes)
A specific ride-hailing vehicle category and pricing option presented to a passenger in response to a ride request.
A passenger's request for an on-demand transport service between two points, specifying origin, destination, and travel preferences.
A person using a shared mobility service (such as a bike-share, scooter, or car-share) who has a registered account with the provider.
A classification of passenger type (e.g., adult, child, senior, student) used to determine applicable fare entitlements.
The physical or logical path followed by a transport service, defined as an ordered sequence of stops or waypoints.
A set of rules, protocols, and standards governing safety requirements for drivers, vehicles, and passengers on a mobility platform.
A salary range or fixed value with currency and payment period. For a fixed salary set salary_min == salary_max, or provide only salary_min.
A combination of one or more fare products bundled for sale through a specific distribution channel.
A specific seat position reserved or assigned to a passenger on a flight, train, or other transport service.
A portion of a rail journey operated continuously by a single carrier between two consecutive stops or stations.
Beckn /beckn/select message payload. Sent by a BAP to a BPP to select items and offers from a catalog, initiating the negotiation cycle. (Context wrapper stripped; only the message-content portion is inlined.)
Internal failure on the network participant's application; the request could not be processed. The response body MAY contain an `error` object with additional details.
A schedule defining on which dates a transport service operates, including regular service days and exceptional dates.
A classification of the level of service offered by a transport service, such as economy, business, or first class.
The top-level response container in SIRI encapsulating one or more real-time data delivery types.
Schema definition for SettlementSchedule in the Beckn Protocol v2.0.1
Describes the terms of settlement associated with a given transaction. This is not to be confused with the PaymentAction as it describes all the places where the money gets disbursed after reconciliation.
The geographic path traced by a vehicle along a route, represented as an ordered sequence of geographic coordinates.
Total cost charged for a logistics service including base freight, surcharges, taxes.
A single line item in the fare breakup for a logistics service.
A digitally signed authentication credential in the HTTP `Authorization` header. Follows draft-cavage-http-signatures-12 as profiled by BECKN-006. Format: ``` Signature keyId="{subscriberId}|{uniqueKeyId}|{algorithm}",algorithm="{algorithm}",created="{unixTimestamp}",expires="{unixTimestamp}",headers="{signedHeaders}",signature="{base64Signature}" ``` | Attribute | Description | |-----------|-------------| | `keyId` | `{subscriberId}\|{uniqueKeyId}\|{algorithm}` — FQDN, registry UUID, signing algorithm | | `algorithm` | MUST be `ed25519` | | `created` | Unix timestamp when the signature was created | | `expires` | Unix timestamp when the signature expires | | `headers` | Space-separated signed headers. MUST include `(created)`, `(expires)`, `digest` | | `signature` | Base64-encoded Ed25519 signature over the signing string | Signing string: `(created): {value}\n(expires): {value}\ndigest: BLAKE-512={digest}` where `digest` is a BLAKE2b-512 hash of the request body, Base64-encoded.
Schema definition for Skill in the Beckn Protocol v2.0.1
**Spatial predicate** using **OGC CQL2 (JSON semantics)** applied to one or more geometry targets in an item. This is where clients express spatial intent. Key ideas: - `targets`: one or more **JSONPath-like** pointers that locate geometry fields within each item document (e.g., `$['availableAt'][*]['geo']`). - `op`: spatial operator (CQL2). Common ones: • `S_WITHIN` (A is completely inside B) • `S_INTERSECTS` (A intersects B) • `S_CONTAINS` (A contains B) • `S_DWITHIN` (A within distance of B) - `geometry`: **GeoJSON** literal used as the predicate reference geometry. - `distanceMeters`: required for `S_DWITHIN` when using a GeoJSON Point/shape. - `quantifier`: if a target resolves to an array, choose whether **ANY** (default), **ALL**, or **NONE** of elements must satisfy the predicate. CRS: unless otherwise stated, all coordinates are **EPSG:4326**.
Schema definition for State in the Beckn Protocol v2.0.1
A major transit facility serving as a hub for one or more transport modes, typically offering waiting areas, ticketing, and interchange facilities.
Static descriptive information about a shared mobility docking station, including its location, capacity, and features.
The real-time operational state of a shared mobility station, including the number of available docks and vehicles.
Beckn /beckn/status message payload. Sent by a BAP to a BPP to query the current state of a contract/order by its identifier. (Context wrapper stripped; only the message-content portion is inlined.)
A designated location where vehicles stop to allow passengers to board or alight from a transport service.
A group of stops that collectively define a zone from which a demand-responsive service may pick up or drop off passengers.
A departure or arrival event at a stop, used to retrieve the next or previous vehicle movements at a specific location.
A real-time data service providing predicted arrivals and departures of vehicles at a specific stop.
A physical location serving as a transit stop facility, comprising one or more quays, entrances, and associated infrastructure.
An abstract or scheduled point in a public transport network at which passengers can board or alight from a service.
The scheduled arrival and departure times for a vehicle at a specific stop within a vehicle journey.
A real-time update to the predicted arrival or departure time of a vehicle at a specific stop within a journey.
Describes a support session info
Beckn /beckn/support message payload. Sent by a BAP to a BPP to request support contact information or to open a support ticket for an existing order/contract. (Context wrapper stripped; only the message-content portion is inlined.)
A domain-agnostic customer support ticket used to record an issue raised between parties — its category, priority, lifecycle status, supporting attachments, and support interaction sessions. It is independent of any particular domain; domain-specific values are carried via the category descriptor and the extensible attribute bags.
Canonical support contact for an entity, mapped to schema.org ContactPoint.
Support request by a user. If no field is set, the user can expect a public support contact info
Support response payload returned by a BPP to a BAP in the /beckn/on_support callback. Contains the support ticket reference, available contact channels, SLA commitment, and optional consumer acknowledgement details.
A support ticket raised against an order
A dynamic pricing factor applied during periods of high demand that increases base fares proportionally to balance supply and demand.
A pricing plan defined by a shared mobility system, describing costs and billing rules for vehicle use.
A geographic zone used to define and apply fare structures, within which a single fare or set of rules applies.
A document or digital record granting the holder the right to travel on a specific transport service or within a defined validity scope.
Represents a moment or duration in time. Can express a timestamp, a duration, or a time range.
Time window with date-time precision for availability/validity This schema is part of the Long Term Support of Beckn Protocol V2.0 API specification and MUST NOT be extended. Any domain-specific extension must use the property of this schema which is of type Attribute.
A structured schedule listing planned arrival and departure times for vehicles at each stop along a route.
Details required to initiate real-time tracking (if relevant) for an ongoing transaction
Information regarding live tracking of the fufillment of a contract
Schema definition for TrackingRequest in the Beckn Protocol v2.0.1
Beckn protocol transaction endpoint identifier.
A defined connection rule between two routes or services at a common stop, specifying minimum transfer time or transfer type.
A generic transport entity in the OSLO mobility ontology representing any object involved in transport operations.
A document (physical or digital) issued to a passenger proving entitlement to travel, used for validation or inspection.
A confirmed and booked journey from an origin to a destination, representing a completed mobility service order.
An identifier that uniquely references a specific vehicle journey in a real-time transit feed.
A request submitted to a journey planning system specifying origin, destination, travel time, and preferences.
The result of a trip planning request, containing one or more journey options with leg details and timing.
A description of the desired journey used as input to search and price transport options.
A multi-dimensional update to an in-progress or upcoming mobility trip, covering contract modifications (added/removed services, route changes), status notifications (driver arriving, trip started), and real-time tracking endpoint information.
Beckn /beckn/update message payload. Sent by a BAP to a BPP to request changes to an active contract (e.g., update fulfillment address, add items, change quantities). The context.try flag must be true during negotiation. (Context wrapper stripped; only the message-content portion is inlined.)
A motorized or human-powered mobility asset used to carry passengers or goods between locations.
A broad classification of vehicles by their physical type, such as two-wheeler, three-wheeler, four-wheeler, or bus.
An identifier that uniquely references a specific vehicle in a real-time transit feed.
A specific operational instance of a vehicle traveling a defined route at a scheduled time on a given service day.
A real-time data delivery providing current positions and operational states of a set of vehicles.
The current real-time geographic position, bearing, and speed of a vehicle operating a transport service.
The real-time operational state of a vehicle or mobility asset, such as available, in use, reserved, or disabled.
A class or category of vehicle defined by its mode of transport, capacity, propulsion type, and accessibility features.
Transaction-level metadata for a verification request contract. Captures who is being verified, why, under what consent, and the aggregate outcome of all verifications in the contract.
Commercial terms under which a verification service is offered. Covers pricing, turnaround guarantees, result validity, and any eligibility constraints on who can request the verification.
Execution details for a single verification check within a contract. Each Performance unit corresponds to one verification type being executed (e.g., one driving licence check, one identity check). Contains the verification result, evidence, and structured output.
Attributes describing a verification service type. Captures what is verified, what inputs are required, which jurisdictions are supported, and the verification method used.
Summary of a credential verification check. Contains the overall result, reason codes for any failures, and which credential categories were successfully verified. No VC or VP payloads are included.
Rules governing the maximum time a driver is required to wait for a passenger at the pickup location before being permitted to cancel the booking.