Search Schemas

Payment methods accepted by a payee

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.

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.beckn.io/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

Availability and compensation expectation terms under which a candidate profile is offered to employers. The proposedConsideration on the core Offer carries the candidate's headline desired salary; this extension provides the full range, notice period, and contract type preferences.

Discoverable profile attributes of a candidate Resource. Captures what the candidate brings (skills, experience, availability) and what they seek (location preference, work mode, job type). Designed for privacy: no name, contact, or identity data. Credentials are referenced via SkillEntry with optional VC attestation URLs.

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 single code drawn from an external or administrative coding authority. The triple (@context, @type, code) uniquely identifies the value within the authority's namespace.

A channel through which communication or support takes place. The enumerated values are derived from SupportInfo.channels (https://schema.beckn.io/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.

Base context schema for all Beckn API calls. Contains addressing information (BAP/BPP identifiers and API URLs), protocol version, the action being called, transaction and message IDs, timestamp, TTL, and optional encryption key. This schema defines all possible properties but imposes NO required-field constraints. Endpoint-specific validation is defined inline in operation request schemas.

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.

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.

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.beckn.io. 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.

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.

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.

Contract-level metadata for an employer-to-candidate hiring offer. Captures the specific role details being offered, compensation amount (as distinct from the candidate's desired range), proposed joining date, offer expiry, and candidate response state.

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.

**GeoJSON geometry** per RFC 7946. Coordinates are in **EPSG:4326 (WGS-84)** and MUST follow **[longitude, latitude, (altitude?)]** order. Supported types: - Point, LineString, Polygon - MultiPoint, MultiLineString, MultiPolygon - GeometryCollection (uses `geometries` instead of `coordinates`) Notes: - For rectangles, use a Polygon with a single linear ring where the first and last positions are identical. - Circles are **not native** to GeoJSON. For circular searches, use `SpatialConstraint` with `op: s_dwithin` and a Point + `distanceMeters`, or approximate the circle as a Polygon. - Optional `bbox` is `[west, south, east, north]` in degrees.

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.

Commercial and availability terms under which a job opportunity is offered. The proposedConsideration on the core Offer object carries the midpoint or headline compensation figure; this extension provides the full range and period breakdown for display and filtering.

Intrinsic attributes of a job opportunity Resource. Domain-generic: applicable to any hiring vertical (tech, construction, logistics, healthcare, gig economy, etc.).

Execution state of the hiring process service. Covers the pipeline from initial screening through to offer acceptance or withdrawal. Includes optional credential verification triggered by the employer during the hiring process.

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.

Transaction-level metadata for a job application contract. Captures the application reference, aggregate verification outcome, and reverification state. No credential payloads are stored here.

Execution metadata for the verification and routing service performed during a job application. Includes the verification method used, per-requirement results, proof integrity reference, and routing outcome. No VC or VP payloads are stored.

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.

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

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.

Schema definition for Provider in the Beckn Protocol v2.0.1

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

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.beckn.io/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.

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 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.

Physical location where the service is or was delivered

Geographic area where the service is available

Time slot for service availability on a specific day of week

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

A single skill, qualification, or credential held by a candidate. The attested flag and proof_request_url are optional — allowing the schema to function in early-stage ecosystems where VC infrastructure is not yet universal. As VCs become available for specific skills, the proof_request_url can be populated without any schema change.

**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.

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.

Container for retail contract attributes (migrated from v2 orderAttributes)

Container for retail performance execution attributes (migrated from v2 fulfillmentAttributes)

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.

OpenADR3 `reportPayloadDescriptor` augmented with a `cardinality` field. Required fields and value enums otherwise match OpenADR3.

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.

Resource attributes describing a demand-flex need. Attached to Resource.resourceAttributes to describe what the utility needs from the network. Captures the direction (increase/reduce), event timing, capacity, and location.

Performance attributes for demand-flex M&V (Measurement & Verification). Attached to Performance.performanceAttributes in on_status callbacks.

Non-PII customer identity and asset list. No PII — safe to share without customerDetails. Supports arbitrary topologies: a single customerNumber may have multiple METER entries (different premises, sub-meters, parallel meters) each with their own child DERs.

Tariff and regulatory load profile for one meter connection. meterId links to a METER entry's id in energyResources[].

PII section. fullName appears ONLY here — never in customerProfile or any resource entry.

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.

Represents a W3C Verifiable Credential (https://www.w3.org/TR/vc-data-model-2.0/) used in enrollment flow. This is a wrapper/reference object that contains the credential data (as JWT or JSON-LD), metadata, and URLs. The actual credential follows W3C VC Data Model v2.0 structure. Can be a meter ownership credential, program eligibility credential, DER certification credential, or program enrollment credential.

Details of a credential that has been verified by the BPP. Returned in credentialVerification.verifiedCredentials array.

Details of a conflicting enrollment that prevents the requested enrollment from proceeding. Returned in conflictCheck.conflictingEnrollments array.

User authentication request - sent by BAP to BPP in init/confirm requests. Supports OTP-based or OAuth2/OIDC token-based authentication.

User authentication response - returned by BPP to BAP in on_init/on_confirm responses. Contains verification results and extracted user identity.

OTP authentication request from BAP. - Init request: Send mobile number to initiate OTP - Confirm request: Send mobile + nguid + otp for verification

OTP authentication response from BPP. - On_init response: Returns nguid and message ("OTP sent") - On_confirm response: Returns verification result

OAuth2/OIDC authentication request from BAP. Contains JWT tokens for BPP to validate. BPP extracts claims from token.

OAuth2/OIDC authentication response from BPP. Contains verification results and extracted user identity from token.

Meter details for enrollment in an energy program. Contains meter identifier (UMID) and optional utility information. Used in the meters array within orderAttributes during confirm request. At least one meter must be specified for enrollment to be confirmed.

Verifiable Credential containing historical time-series interval meter readings using ESPI/Green Button types (ReadingType, IntervalBlock, IntervalReading). Subclass of EnergyCredential. The credential subject combines a customer profile with meter data within a W3C VC 2.0 envelope.

ESPI/Green Button meter reading data for a single meter. Uses native ESPI types and enum codes.

Canonical energy-asset class. Exactly four top-level fields: id, type, subResources, parentResources. All other attributes — dimensioning, location, type-specific data — live in `attributes`. No field is required at the schema level. Domain profiles enforce their own cross-field rules.

Dimensioning fields common to all EnergyResource types. These live inside EnergyResource.attributes alongside any type-specific fields. No field is required.

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).

Contains information about a Third Party Application requesting access to the DataCustodian services. Information requested may include items such as Organization Name, Website, Contact Info, Application Name, Description, Icon, Type, default Notification and Callback endpoints, and may also include agreement with terms of service. Atom Links: self link to this resource

[extension] Represents a permission granted by an owner for access to a resource. Atom Links: self link to this resource rel corresponding ApplicationInformation (if this is the client access containing token instance) rel corresponding to the authorized resource (if this is the access_token containing instance for a customer resource) Note: for privacy there is no identifier of the RetailCustomer in this structure but an implementation will have consider how to maintain a correspondence between a RetailCustomer and his authorization.

Time sequence of Readings of the same ReadingType.

Characteristics associated with all Readings included in a MeterReading.

Logical point on a network at which consumption or production is either physically measured (e.g., metered) or estimated (e.g., unmetered street lights).

A summary of power quality events. This information represents a summary of power quality information typically required by customer facility energy management systems. It is not intended to satisfy the detailed requirements of power quality monitoring. All values are as defined by measurementProtocol during the period. The standards typically also give ranges of allowed values; the information attributes are the raw measurements, not the "yes/no" determination by the various standards. See referenced standards for definition, measurement protocol and period.

[DEPRECATED] Summary of usage for a billing period

[extension] Summary of usage for a billing period

[extension] Contains attributes related to the configuration of the time service.

[extension] List of programIDmappings

Specific value measured by a meter or other asset. Each Reading is associated with a specific ReadingType.

Quality of a specific reading value or interval reading value. Note that more than one Quality may be applicable to a given Reading. Typically not used unless problems or unusual conditions occur (i.e., quality for each Reading is assumed to be 'Good' (valid) unless stated otherwise in associated ReadingQuality).

Category of service provided to the customer.

An aggregated summary measurement reading.

Includes elements that make it possible to include multiple transactions in a single (batch) request.

[extension] Service Delivery Point is representation of revenue UsagePoint attributes

Interval of date and time. End is not included because it can be derived from the start and the duration.

This is a root class to provide common naming attributes for all classes needing naming attributes

Superclass of all object classes to allow extensions. Inheritance from Object provides an inherent extension mechanism permitting custom data to be included in a separate namespace.

Contains the current status of the service.

[extension] Rational number = 'numerator' / 'denominator'.

[extension] Interharmonics are represented as a rational number 'numerator' / 'denominator', and harmonics are represented using the same mechanism and identified by 'denominator'=1.

[extension] List of resource URIs that can be used to GET ESPI resources

[extension] Line item of detail for additional cost

[extension] Sequence of references to Pnodes assoicated with a UsagePoint.

[extension] References to associated AggregateNodes.

[extension] References to associated Tariff Riders.

[extension] Reference to a Pnode.

[extension] Reference to an AggregateNode (could be a load aggregation point which is a specialization of AggregateNode).

[extension] Reference to a Tariff Rider.

[extension] Information about source of billing charge

Phase code indicating number and type of wires (IEC 61970 Core::PhaseCode).

State of a UsagePoint with respect to physical/logical connection to the network (IEC 61968 Metering).

Lifecycle state of the metering installation with respect to AMI billing readiness (IEC 61968 Metering).

Kind of meter multiplier (IEC 61968 Metering).

Winding connection type for a transformer end (IEC 61970 Wires).

Source that provided a measurement value.

Domain component of an end-device event code (IEC 61968-9 Annex E).

Communication technology used by end devices (IEC 61968 Metering::ComFunction.technology).

Communication direction capability of an end device (IEC 61968 Metering::ComFunction.direction). biDirectional = two-way AMI; fromDevice = one-way AMR.

Reason for a meter reading (IEC 61968 Metering::ReadingReasonKind).

Overall period of interest for a reading type (IEC 61968 Metering::MacroPeriodKind).

Time attribute of the base measurement interval (IEC 61968 Metering::MeasuringPeriodKind). Includes simple intervals, fixed blocks, and rolling blocks.

Aggregation operation applied to a reading type (IEC 61968 Metering::AggregateKind).

Quality classification for a reading value (IEC 61968-9). Format: system.category.subcategory

Boolean flags describing inherent capabilities of an end device (IEC 61968 Metering::EndDeviceCapability).

End device nameplate / datasheet data — represents typical information for a class of meters (IEC 61968 Metering::EndDeviceInfo).

Asset container that performs one or more end device functions. A meter is one type of EndDevice (IEC 61968 Metering::EndDevice).

Physical asset that performs the metering role of a usage point. Extends EndDevice with meter-specific attributes (IEC 61968 Metering::Meter).

Multiplier applied at the meter, typically for instrument transformer ratios (IEC 61968 Metering::MeterMultiplier).

A single path for the collection or reporting of register values over a period of time (IEC 61968 Metering::Channel).

A device that indicates or records units of the commodity or other quantity measured (IEC 61968 Metering::Register).

Structured event classification for end-device events. Codes follow the format: type.domain.subDomain.eventOrAction (IEC 61968-9 Annex E).

Name-value pair providing additional detail for an end-device event (IEC 61968 Metering::EndDeviceEventDetail).

Event detected by a device function associated with an end device (IEC 61968 Metering::EndDeviceEvent). Covers outage, tamper, firmware, diagnostic, and demand-response events.

CIM-enriched UsagePoint with attributes beyond what ESPI provides. Represents a logical or physical point in the network to which readings or events may be attributed (IEC 61968 Metering::UsagePoint).

Quality flags for a measurement value (IEC 61970 Meas::MeasurementValueQuality).

Base type for any measured, calculated, or non-measured quantity at a point in the network. Subtyped as Analog, Discrete, or Accumulator (IEC 61970 Meas::Measurement).

A continuous-valued measurement — e.g., bus voltage, line MW, transformer loading (IEC 61970 Meas::Analog).

A single timestamped analog measurement value (IEC 61970 Meas::AnalogValue).

An integer-valued measurement — e.g., breaker position, tap changer step (IEC 61970 Meas::Discrete).

A single timestamped discrete measurement value (IEC 61970 Meas::DiscreteValue).

A single timestamped accumulator (counter) value — e.g., energy register reading (IEC 61970 Meas::AccumulatorValue).

Current transformer (CT) nameplate data (IEC 61968 Assets / IEC 61970 Meas::CurrentTransformer).

Potential / voltage transformer (PT/VT) nameplate data (IEC 61968 Assets / IEC 61970 Meas::PotentialTransformer).

One winding/end of a power transformer, with electrical characteristics (IEC 61970 Wires::PowerTransformerEnd).

Basic identification and characteristics of a power transformer, sufficient to contextualize transformer-level meter readings (IEC 61970 Wires::PowerTransformer).