Search across 313 schema types in the Beckn Protocol registry.
Payment methods accepted by a payee
Synchronous receipt acknowledgement returned for every accepted Beckn request. Supports both the v2.0 format (status + signature CounterSignature) and the v2.0-rc1 legacy format (ack_status + transaction_id + timestamp) via oneOf for backward compatibility.
Schema definition for AckResponse in the Beckn Protocol
**Postal address** aligned with schema.org `PostalAddress`. Use for human-readable addresses. Geometry lives in `Location.geo` as GeoJSON.
Schema definition for Alert in the Beckn Protocol v2.0.1
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.
Unified Beckn action envelope. All Beckn API requests and callbacks conform to this schema. The context identifies the action being performed; the message carries the action-specific payload. Message content is validated via if/then dispatch based on context.action. For unknown or extension endpoints, no if/then branch applies and message remains unconstrained. This schema supersedes RequestAction and CallbackAction, both of which were structurally invalid. The request/callback distinction is encoded in the context.action value (e.g. beckn/discover vs beckn/on_discover), not in a separate schema type.
A Beckn protocol endpoint identifier. Must start with the prefix "beckn/" followed by one or more lowercase segments (letters and underscores only) separated by forward slashes. Standard endpoints are listed in the oneOf below with their descriptions. New actors may define extension endpoints without modifying this schema — the pattern accepts any conforming beckn/ prefixed string.
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.
Beckn /beckn/cancel action envelope. 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.
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
Catalog schema for Beckn Protocol v2.0.1
Schema definition for CatalogProcessingResult in the Beckn Protocol v2.1
Beckn /beckn/catalog_publish message payload. Sent by a BPP to a CDS (Catalog Discovery Service) to publish or update one or more catalogs. The CDS indexes the catalogs and makes them discoverable.
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.
Schema definition for CategoryCode in the Beckn Protocol v2.0.1
The checkout terminal where the consumer makes the payment
Beckn /beckn/confirm action envelope. Sent by a BAP to a BPP to confirm a contract, finalising the transaction terms agreed during the select–init negotiation cycle.
Schema definition for Constraint in the Beckn Protocol v2.0.1
Schema definition for Consumer in the Beckn Protocol v2.0.1
Every API call in Beckn protocol has a context. It provides a high-level overview to the receiver about the nature of the intended transaction. Typically, it is the BAP that sets the transaction context based on the consumer's location and action on their UI. The context object contains four types of fields: (1) demographic information about the transaction using fields like domain, country, and region; (2) addressing details like the sending and receiving platform's ID and API URL; (3) interoperability information like the protocol version implemented by the sender; and (4) transaction details like the method being called at the receiver's endpoint, the transaction_id that represents an end-to-end user session at the BAP, a message ID to pair requests with callbacks, a timestamp to capture sending times, a ttl to specify the validity of the request, and a key to encrypt information if necessary.
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.
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 credential artifact that is either (a) a W3C Verifiable Credential (opaque JSON object) or (b) a document attachment reference requiring manual/offline verification.
Schema definition for Descriptor in the Beckn Protocol v2.0.1
Beckn /beckn/discover action envelope. Sent by a BAP to a BPP (or registry) to discover catalogs matching a given intent.
Schema definition for DisplayedRating in the Beckn Protocol v2.0.1
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.
Schema definition for Eligibility in the Beckn Protocol v2.0.1
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.
Schema definition for Error in the Beckn Protocol v2.0.1
Schema definition for ErrorResponse in the Beckn Protocol v2.0.1
Feedback collected from a user (consumer, provider, or fulfillment agent)
A Beckn schema for a food and beverage item in retail F&B ordering. FnBItem v2.1 extends beckn:RetailItem with comprehensive food-specific attributes covering classification, allergens, additives, nutritional information, cuisine, and preparation guidance. Inheritance: beckn:RetailItem ← beckn:FnBItem Use in: beckn:Commitment.commitmentAttributes for F&B orders
A Beckn schema for food and beverage offer attributes. FnBOffer extends beckn:RetailCoreOfferAttributes with F&B-specific offer customization groups — the structured mechanism by which a food item's configurable options (size, crust, toppings, add-ons) are declared and priced within an offer. A CustomizationGroup represents one dimension of configurability (e.g. pizza size, crust type, topping selection). Each group has one or more options with optional price deltas. Inheritance: beckn:RetailCoreOfferAttributes ← beckn:FnBOffer Use in: beckn:Offer.offerAttributes for F&B catalog items
A price specification for food and beverage (F&B) delivery orders. FnBPriceSpecification specializes beckn:PriceSpecification for the specific price calculation structure of a food ordering and delivery transaction. It is derived from extensive research into how food delivery platforms (Domino's, Zomato, Swiggy, UberEats) model itemised bills, including: - Size-dependent item and topping pricing (a topping on a Regular pizza costs less than on a Large pizza; add-on price = f(size, topping_type)) - Crust upcharges (premium crusts like Cheese Burst or Pan cost more) - Combo discount mechanics (bundle savings expressed as negative values) - Delivery and packaging fees distinct from item charges - Platform convenience charges **Component type codes:** Item-level charges (may appear multiple times — once per line item): - BASE_ITEM — Base price of a food or beverage item at its selected size - SIZE_UPCHARGE — Premium for selecting a larger size over the base size (e.g. Regular → Medium) - TOPPING — Individual topping or ingredient add-on; price varies by item size - ADDON — Optional add-on item (dip, sauce, condiment packet) - CUSTOMIZATION — Surcharge for a special preparation request - SIDE — A side dish added to the order Combo and offer adjustments (typically negative): - COMBO_SAVINGS — Discount from applying a bundle/meal combo deal (negative) - COMBO_UPCHARGE — Premium for upgrading within a combo (e.g. regular to medium pizza) - OFFER_DISCOUNT — Time-limited promotional discount applied at order level (negative) - COUPON_DISCOUNT — Discount from a promo/coupon code (negative) - LOYALTY_DISCOUNT — Discount from loyalty points redemption (negative) Order-level charges: - DELIVERY_FEE — Delivery charge (flat, distance-based, or surge-adjusted) - PACKAGING_FEE — Restaurant packaging charge (boxes, insulated bags, eco-packaging) - SMALL_ORDER_FEE — Surcharge applied when order value is below the minimum - PLATFORM_FEE — App/platform convenience service charge Gratuity: - TIP — Customer gratuity (added voluntarily by the consumer) Notes: - Tax components (GST, VAT, etc.) are jurisdiction-specific and MUST be modelled using PriceSpecificationComponent variants, not as codes in this schema. - For TOPPING components, referenceItemId SHOULD be set to the ID of the base item to which the topping belongs, since topping price varies by item size. - Negative values MUST be used for COMBO_SAVINGS, OFFER_DISCOUNT, COUPON_DISCOUNT, and LOYALTY_DISCOUNT. Inheritance: beckn:PriceSpecification ← beckn:FnBPriceSpecification schema.org alignment: schema:PriceSpecification (via inheritance) Use in: beckn:Consideration.considerationAttributes for F&B orders
A Beckn schema for a food and beverage item in retail F&B ordering. FoodAndBeverageItem v2.1 extends beckn:RetailItem with comprehensive food-specific attributes covering classification, allergens, additives, nutritional information, cuisine, and preparation guidance. Inheritance: beckn:RetailItem ← beckn:FoodAndBeverageItem Use in: beckn:Commitment.commitmentAttributes for F&B orders
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 minimal Fulfillment envelope. Carries identity, status, and a fulfillmentAttributes bag that holds the concrete domain-specific delivery schema. Domain-specific delivery details (pickup/delivery locations, items shipped, agent, etc.) are placed inside fulfillmentAttributes using a well-known domain schema such as beckn:HyperlocalDelivery. Use the generic Attributes schema when no well-known domain schema exists.
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.
**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 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
Beckn /beckn/init action envelope. Sent by a BAP to a BPP to initialise a contract with consumer details (billing address, fulfillment preferences, etc.).
Schema definition for Instruction in the Beckn Protocol v2.0.1
A declaration of an intent to discover catalogs.
Schema definition for Invoice in the Beckn Protocol v2.0.1
Schema definition for Item in the Beckn Protocol v2.0.1
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 **place** represented by **GeoJSON geometry** (Point/Polygon/Multi*) and optional human-readable `address`. This unifies all Beckn location fields into a single, widely-adopted representation (GeoJSON).
A image, audio, or video typically intended for display purposes
Reference to an image, audio clip, or video used for multimodal search.
Container for multimodal search inputs and configuration. Supports searching through **images, audio notes, and videos** alongside text, filters, and spatial predicates. For GET, this object should be JSON-encoded and URL-escaped.
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.
Schema definition for Offer in the Beckn Protocol v2.0.1
Beckn /beckn/on_cancel callback envelope. 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.
Beckn /beckn/on_confirm callback envelope. Sent by a BPP to a BAP in response to a /beckn/confirm call, returning the confirmed contract with status set to CONFIRMED.
Beckn /beckn/on_discover message payload. Sent by a BPP or CDS to a BAP in response to a discover request. Contains matching catalogs.
Beckn /beckn/on_init callback envelope. Sent by a BPP to a BAP in response to a /beckn/init call, with the updated contract including payment terms and billing confirmation.
Beckn /beckn/on_rate callback envelope. 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.
Beckn /beckn/on_select callback envelope. Sent by a BPP to a BAP in response to a /beckn/select call, with updated contract terms.
Beckn /beckn/on_status callback envelope. 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.
Beckn /beckn/on_support callback envelope. Sent by a BPP to a BAP in response to a /beckn/support call, returning support contact details and available channels.
Beckn /beckn/on_track callback envelope. 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.
Beckn /beckn/on_update callback envelope. 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.
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.
Schema definition for Participant in the Beckn Protocol v2.0.1
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.
A person (alive, deceased, or fictional). Modeled after schema.org/Person.
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
Schema definition for Provider in the Beckn Protocol v2.0.1
Schema definition for Quantity in the Beckn Protocol v2.0.1
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 action envelope. 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).
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.
Retail-specific fulfillment attribute pack extending Beckn core Fulfillment. Used as the value of Fulfillment.fulfillmentAttributes for retail domain fulfillments. Covers supported fulfillment types, delivery endpoint, operating schedule, SLA semantics, and handling constraints.
Retail-specific item attribute pack, used as the value of Item.itemAttributes for retail domain items. Covers physical properties, food classification, regulatory declarations, and verifiable credentials.
Retail-specific offer attribute pack, used as the value of Offer.offerAttributes for retail domain offers. Covers return/cancellation/replacement policies, payment constraints, serviceability (distance + timing), daily time window, and holidays.
Retail-specific order-level attributes that extend core Beckn Order. Used as the value of Order.orderAttributes for retail domain orders. Captures transaction-instance metadata relevant to retail domains without duplicating core Order semantics.
A minimal retail item schema for use in Contract.commitments[].commitmentAttributes. RetailItem is the foundational schema for items in retail transactions. It extends beckn:Resource with the core retail item properties: price, quantity, and verifiable credentials. Domain-specific schemas (e.g. FoodAndBeverageItem) extend RetailItem with additional domain-specific attributes. Inheritance: beckn:Resource ← beckn:RetailItem Use in: beckn:Commitment.commitmentAttributes for retail orders
Beckn /beckn/select action envelope. Sent by a BAP to a BPP to select items and offers from a catalog, initiating the negotiation cycle.
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.
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
Beckn /beckn/status action envelope. Sent by a BAP to a BPP to request the current status of an existing contract/order, identified by its id.
Support request payload sent by a BAP to a BPP in the /beckn/support call. Used to request support contact information, report an issue, or open a support ticket for an existing order.
Beckn /beckn/support action envelope. Sent by a BAP to a BPP to request support contact information or to open a support ticket for an existing order/contract.
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
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
Beckn /beckn/track action envelope. Sent by a BAP to a BPP to request a real-time tracking handle for a fulfillment within an active contract.
Non-streaming tracking handle per legacy semantics (url/transport/status).
Schema definition for TrackingRequest in the Beckn Protocol v2.0.1
Beckn protocol transaction endpoint identifier.
Beckn /beckn/update action envelope. 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.
Verifiable Credential for electricity connection and consumption characteristics. Issued by distribution utilities to consumers and prosumers for load management and tariff determination purposes. ConsumptionProfileCredential is a subclass of EnergyCredential (which is a subclass of beckn:Credential). The credential subject contains connection-specific attributes including premises type, connection type, sanctioned load, and tariff category.
EnergyContract is a subclass of beckn:Contract representing energy-specific contracts on the DEG (Digital Energy Grid) network. It serves as a semantic subclass marker for energy contracts and is the parent of P2PTrade and other DEG energy contract types. This schema introduces no additional properties beyond those inherited from beckn:Contract. Domain-specific properties are defined in concrete subclass schemas (e.g., P2PTrade).
Base class for all DEG energy-sector Verifiable Credentials issued by electricity distribution utilities. EnergyCredential is a subclass of beckn:Credential that adds the common envelope properties shared by all DEG energy credentials: a structured issuer object (with regulatory licenseNumber), issuance/expiration dates, DeDi registry-based revocation status, and a W3C-style cryptographic proof. Concrete credential types (ConsumptionProfile, GenerationProfile, StorageProfile, ProgramEnrollment, UtilityCustomer) subclass EnergyCredential and add domain-specific credentialSubject properties.
Customer attributes for energy flows. Used for consumers, producers, or prosumers in: - orderItemAttributes (init request): Contains meterId for delivery destination - orderItemAttributes (responses): Contains meterId for delivery destination - buyerAttributes (enrollment): Contains meterId and sanctionedLoad for customer identification
⚠️ DEPRECATED — Use EnergyProgramEnrollment/v2.0 instead. This schema is preserved for backward compatibility. See deg:EnergyEnrollment owl:equivalentClass deg:EnergyProgramEnrollment in vocab.jsonld. Attribute schema for program enrollment (Fulfillment.fulfillmentAttributes and Contract.orderAttributes). These attributes support the onboarding flow where BPP verifies credentials, checks for conflicts, and issues enrollment credentials. Used in init requests (fulfillmentAttributes) and init/confirm responses (Contract.orderAttributes).
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.
Gift parameters for P2P energy gifting. Enables a prosumer (gifter) to make an energy offer available at 0 price on the catalog, discoverable by the SHA-256 hash of the recipient's phone number and claimable via a secret shared out-of-band from the gifter to the recipient.
Order item attributes for P2P energy trading. Wraps customer information and optional fulfillment tracking data. Use this schema for beckn:orderItemAttributes in P2P energy trading flows.
Attribute schema for program enrollment (Fulfillment.fulfillmentAttributes and Contract.orderAttributes). These attributes support the onboarding flow where BPP verifies credentials, checks for conflicts, and issues enrollment credentials. Used in init requests (fulfillmentAttributes) and init/confirm responses (Contract.orderAttributes). EnergyProgramEnrollment is the successor to EnergyEnrollment (v0.2, v2.0). OWL migration: deg:EnergyProgramEnrollment owl:equivalentClass deg:EnergyEnrollment.
Item attributes for energy resources. Attached to Item.itemAttributes to provide energy-specific characteristics including source type and meter identifiers.
Offer attributes for P2P energy trading. Attached to Offer.offerAttributes to provide pricing models, availability windows, and delivery details. NOTE: Price (beckn:price) is specified on the parent Offer object, not here. The price.applicableQuantity specifies the max energy quantity for this delivery window.
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).
⚠️ DEPRECATED — Use P2PTrade/v2.0 instead. This schema is preserved for backward compatibility. See deg:EnergyTrade owl:equivalentClass deg:P2PTrade and beckn:Order owl:equivalentClass beckn:Contract in the OWL vocabulary. JSON Schema for P2P energy trading contracts. EnergyTrade is a subclass of Contract that specialises the base beckn Contract for energy delivery between prosumers. An EnergyTrade brings together: - An energy resource (the item being traded — see EnergyResource) - An energy trade offer with pricing model and delivery window (see EnergyTradeOffer) - A trade delivery tracking meter readings and status (see EnergyTradeDelivery) - Customer identity for buyer and provider sides (see EnergyCustomer) - A contract item wrapper linking customer and delivery data (see EnergyOrderItem) - Optional gifting metadata (see EnergyGift) The seven domain schemas are defined in $defs and are also published independently at https://schema.beckn.io/<SchemaName>/v2.0.
Attribute schema for EV charging offers (Offer.attributes). Provides tariff details beyond core price fields including per-kWh or time-based pricing, idle fee policies, and accepted payment methods.
Attribute schema for EV charging point operators (Provider.attributes). Provides operator identifiers, statutory registrations, and extended contact details for the charging provider.
Attribute schema for EV charging services (Item.attributes). Provides technical and contextual details of a charging connector or station including connector type, power capacity, socket count, reservation capability, and amenities. NOTE: This schema only defines attributes NOT already modeled by core Beckn schemas. Core fields (name/descriptor, images/URL, category, availableAt/location, validity windows, eligibility, order state, fulfillment start/end times, etc.) should be taken from the core Beckn objects (Catalog/Item/Offer/Order/Fulfillment).
Attribute schema for EV charging sessions (Order.fulfillments[].attributes). Tracks real-time or completed charging session data including session status, energy consumed, duration, total cost, telemetry intervals, and tracking links.
Verifiable Credential for DER (Distributed Energy Resource) generation capability. Issued by distribution utilities to prosumers with solar, wind, micro-hydro, or other generation assets. GenerationProfileCredential is a subclass of EnergyCredential. The credential subject captures generation-specific attributes including generation type, installed capacity in kW, and commissioning date.
JSON Schema for Peer-to-Peer energy trading contracts on the DEG network. P2PTrade is a subclass of EnergyContract (which is itself a subclass of beckn:Contract) and represents the current recommended schema for P2P energy trading agreements between prosumers. P2PTrade supersedes the deprecated EnergyContract schema. It inherits all Contract properties and is associated with the EnergyTrade domain schema which defines the full set of P2P-specific attributes (offer, order, delivery, resource, customer, orderItem).
Verifiable Credential for energy program enrollment. Issued by distribution utilities when consumers enroll in programs such as P2P energy trading, demand flexibility, virtual power plants, or time-of-use tariffs. ProgramEnrollmentCredential is a subclass of EnergyCredential. The credential subject captures enrollment-specific attributes: the program name and code, enrollment date, and optional expiry date.
Verifiable Credential for battery/energy storage capability. Issued by distribution utilities to customers with home batteries, EV batteries, or other energy storage assets. StorageProfileCredential is a subclass of EnergyCredential. The credential subject captures storage-specific attributes including storage capacity in kWh, power rating in kW, commissioning date, and optional storage technology type.
Barebones identity credential for privacy-preserving customer identification. Issued by distribution utilities as the base identity anchor for DEG energy customers. UtilityCustomerCredential is a subclass of EnergyCredential. The credential subject captures core customer identity attributes: consumer number, full name, installation address, meter number, and service connection date. An optional masked government ID enables additional privacy-preserving verification.