OData Protocol in SAP — V2, V4 and How It Works
If you have ever looked at the network tab of an SAP Fiori app, you have seen OData requests. If you have worked with SAP APIs, you have consumed OData services. If you are building on SAP BTP, you are almost certainly either exposing or consuming OData.
OData is everywhere in the SAP world. But most people who use it daily cannot explain what it actually is — only what it looks like. This post fixes that.
🔗 Related context
OData is built on REST principles — if you are not familiar with those, REST API Design Principles is the right starting point. This post also connects directly to SAP Fiori Design Principles , SAP BTP — The Platform Explained and SAP Integration Patterns .
What OData is
OData — Open Data Protocol — is an open standard for building and consuming RESTful APIs. It defines not just the transport (HTTP) and format (JSON or XML) but also a standard query language, a standard way to describe data models, and standard operations for reading and modifying data.
In plain terms: OData gives you a structured, predictable way to ask a system for data — and to know exactly what you will get back. You do not just get an endpoint; you get a self-describing API with a metadata document that tells you everything about the data it exposes.
OData was standardised by the OASIS consortium. SAP adopted it as the protocol for SAP Fiori and S/4HANA APIs — which is why it is now central to the entire SAP landscape.
💡 OData vs plain REST
A plain REST API can return anything in any shape. OData is REST with rules — standard operations (CRUD), standard query options ($filter, $expand, $orderby), and a metadata document. This predictability is what lets Fiori Elements generate UIs automatically from an OData service without custom code.
How OData works — the basics
The service document and metadata
Every OData service has two special endpoints:
- The service root — returns a list of all entity sets the service exposes
- The metadata document ($metadata) — returns a full description of every entity, property, key, relationship and navigation in the service
This self-describing nature is what makes OData powerful. A client can read the metadata and know exactly what the service contains without documentation.
The standard query options
| Query option | What it does | Example |
|---|---|---|
| $filter | Filter records by condition | $filter=Country eq ‘DE’ |
| $select | Choose which fields to return — reduces payload | $select=OrderID,CustomerName,Amount |
| $expand | Include related entities in one request | $expand=OrderItems — fetches order with its line items |
| $orderby | Sort results | $orderby=Amount desc |
| $top | Return the first N records | $top=10 |
| $skip | Skip N records — used for pagination | $skip=20&$top=10 — page 3 of 10 |
| $count | Return the total record count | $count=true — includes total alongside results |
| $search | Full-text search (V4 only) | $search=laptop |
V2 vs V4 — the real differences
OData V4 is not a minor update to V2. They are architecturally different. SAP’s current direction is V4 for all new development — but V2 is still deployed everywhere in existing SAP landscapes and will be for years.
| Area | OData V2 | OData V4 |
|---|---|---|
| Default format | XML (JSON supported but not default) | JSON (JSON-first, cleaner payloads) |
| Update method | POST with X-HTTP-METHOD: MERGE header | HTTP PATCH — standard semantics, simpler |
| Query on related entities | Limited — cannot filter on expanded entities | Full — filter, sort and select on any expanded navigation |
| Delta / change tracking | Not supported | Delta queries — fetch only changes since last request |
| Full-text search | Not supported | $search query option supported |
| Type system | Basic types — DateTime, Float | Richer types — Date, TimeOfDay, Enum, plus inheritance |
| Actions and functions | Limited | First-class support — server-side operations exposed via API |
| Metadata format | XML only | JSON metadata format available |
| UI5 model binding | sap.ui.model.odata.v2.ODataModel | sap.ui.model.odata.v4.ODataModel — incompatible with V2 model |
| SAP development model | SEGW (Service Builder) | RAP — ABAP RESTful Application Programming Model |
📌 V4 and RAP have evolved together
SAP’s RESTful ABAP Programming Model (RAP) is the recommended way to build OData V4 services in S/4HANA. RAP defines business objects with managed behaviour, and OData V4 is the automatic API layer on top. This is why all new SAP-delivered APIs in S/4HANA are V4 — and why V4 and Fiori Elements work so naturally together.
Why V2 is still everywhere
SAP has thousands of delivered V2 services in ECC and early S/4HANA. Most Fiori apps that existed before 2019 are built on V2. Migrating them to V4 is a significant effort — and SAP continues to support V2.
The rule of thumb in 2026: use V4 for anything new. Do not migrate working V2 services unless there is a clear functional reason. When you do encounter V2, understand it — it will be part of SAP landscapes for a long time.
OData in the SAP landscape — where you encounter it
| Where | How OData is used |
|---|---|
| SAP Fiori apps | Every Fiori transactional and analytical app calls an OData service on the backend. The app is the consumer; the OData service is the data layer. |
| SAP Gateway | The SAP component that hosts OData V2 services — handles registration, activation and request routing. SU01, SEGW and /IWFND/ transactions live here. |
| CDS Views | Core Data Services are used to define OData V4 service structures in S/4HANA — the CDS annotation @OData.publish: true exposes a view directly as an OData endpoint. |
| RAP | The ABAP RESTful Application Programming Model is the standard way to build OData V4 services — business object definition, behaviour and OData exposure in one framework. |
| SAP BTP API Management | OData services from S/4HANA are published, versioned and secured via API Management on BTP — adding OAuth, rate limiting and a developer portal. |
| SAP Integration Suite (CPI) | CPI flows consume OData services to read or write SAP data as part of integration scenarios. |
| External applications | Any system with an HTTP client can consume SAP OData — third-party apps, mobile apps, Power BI, and custom portals all use OData to integrate with SAP. |
A practical OData request — reading sales orders
Here is a real OData V4 request to retrieve confirmed sales orders from S/4HANA, fetching only the fields needed and including the line items:
GET /sap/opu/odata4/sap/api_sales_order/srvd_a2x/sap/salesorder/0001/SalesOrder ?$filter=OverallSDProcessStatus eq ‘C’
&$select=SalesOrder,SoldToParty,NetAmount,TransactionCurrency
&$expand=to_Item($select=SalesOrderItem,Material,RequestedQuantity)
&$top=50
&$orderby=CreationDate desc
Accept: application/json
Authorization: Bearer
What this does: fetches the 50 most recent confirmed sales orders, returns only four header fields, and expands each order to include its line items with three fields each. One request, structured payload, no unnecessary data.
The response comes back as JSON with a standard structure. The @odata.context field at the top identifies the metadata document. The @odata.count field contains the total record count when $count=true is included. The value array contains the actual records. Every OData V4 response follows this envelope — once you know it, you can parse any OData response without documentation.
Common questions
How is OData different from a plain REST API?
A plain REST API is a set of endpoints with whatever structure the designer chose. OData is REST with a standard on top — standard query options, a metadata document, standard CRUD operations. The trade-off: more structure means less flexibility but more predictability and tooling support.
Should I use OData or REST for a new SAP BTP service?
If the service is consumed by a Fiori app or needs Fiori Elements support — use OData V4 via RAP. If the service is a general-purpose API for external consumption or system integration — plain REST may be simpler and more flexible. Both are valid; the use case determines the choice.
Why does my Fiori app use V2 when V4 is current?
Because the app was likely built before V4 became the standard, or it was built on a delivered SAP service that is still V2. This is not wrong — V2 works correctly. SAP will continue supporting it. New Fiori Elements apps should use V4.
OData annotations — metadata that drives UI behaviour
One more concept worth knowing: OData annotations. Annotations are metadata added to an OData service that describe how the data should be displayed, validated and behave in the UI — without writing UI code. In SAP Fiori Elements, the framework reads annotations to generate the app automatically.
| Annotation | What it does |
|---|---|
@UI.lineItem | Defines which fields appear as columns in a list |
@UI.selectionField | Defines which fields appear as filter options |
@UI.fieldGroup | Groups fields together on an object page |
@Consumption.valueHelpDefinition | Links a field to a value help popup |
Two annotation vocabularies you will encounter in SAP: UI annotations (from the ODATA_V4_UI namespace) — control how fields are displayed in Fiori Elements apps. Consumption annotations — control value helps, search and field-level behaviour. RAP business objects use CDS annotations to publish these to the OData layer automatically. This is why Fiori Elements apps can be generated with almost no UI development — the metadata does the work.
At a glance — OData essentials
| Concept | One-line summary |
|---|---|
| OData | Open Data Protocol — a REST-based standard for building self-describing, queryable APIs |
| $metadata | The service’s self-description — entities, properties, relationships, types |
| $filter | Server-side filtering — only matching records are returned |
| $expand | Fetch related entities in one request instead of multiple |
| $select | Choose which fields to return — reduces payload size |
| OData V2 | Older version — XML-first, SEGW-based, still widely deployed in SAP landscapes |
| OData V4 | Current version — JSON-first, RAP-based, richer queries, required for new development |
| SAP Gateway | The S/4HANA and ECC component that hosts OData V2 services |
| RAP | The ABAP RESTful Application Programming Model — the standard for building OData V4 services |
What to take away
OData is the data language of the SAP Fiori world. Once you understand the query options, the difference between V2 and V4, and where each shows up in the stack — a lot of things that felt opaque start to make sense: why Fiori Elements generates UIs automatically, why CPI flows look the way they do, why API Management sits in front of OData services.
V4 is the future. V2 is still the present in most landscapes. Knowing both is what the job requires in 2026.
🔗 Related posts on this site
REST API Design Principles — OData is REST with structure on top — the REST principles apply in full. SAP Fiori Design Principles — every Fiori app is an OData consumer — the two are inseparable. SAP BTP — The Platform Explained — API Management on BTP publishes and secures OData services for external consumption. SAP Integration Patterns — OData is one of the core SAP integration technologies alongside RFC, BAPI and IDoc.
Published on rakeshnarayan.com — Articles
URL: https://rakeshnarayan.com/articles/odata-protocol-in-sap/
