Integrating SAP With Modern Web Apps: APIs, OData, and BTP

Businesses increasingly want SAP's data and processes available in the same modern interfaces they use everywhere else: a responsive web portal, a mobile app for field staff, a customer self-service dashboard. The challenge is that SAP was not designed as a friendly web backend, and connecting it naively leads to brittle, insecure, or slow integrations. This guide covers how to do it properly.

The integration layers, top to bottom

A healthy SAP-to-web architecture has three layers:

1. The front end — your web or mobile app (React, Next.js, native mobile). It never talks to SAP directly.
2. The integration / API layer — a backend-for-frontend or services layer, typically on SAP BTP or your own cloud, that authenticates the user, calls SAP, shapes the data, and enforces security and rate limits.
3. SAP — exposing its business objects through OData services, RESTful APIs, BAPIs, or events.

Keeping these layers distinct is the single most important architectural decision. It is what lets the front end evolve quickly while SAP stays stable and secure.

OData: the primary doorway

OData is the standard way modern SAP exposes data. An OData service publishes an entity model and supports normal HTTP operations with rich query options:

GET /sap/opu/odata/sap/API_BUSINESS_PARTNER/A_BusinessPartner?$filter=Country eq 'JM'&$top=20&$select=BusinessPartner,BusinessPartnerName

A few things make OData pleasant to work with:

• $filter, $select, $expand, $top, $skip let the client request exactly the data it needs and paginate large sets, which keeps payloads small and the UI fast.
• A discoverable metadata document ($metadata) describes the entity model, so tooling can generate typed clients.
• Standard CRUD maps cleanly: GET to read, POST to create, PATCH/PUT to update, DELETE to remove.

S/4HANA ships a large catalogue of released OData APIs (the SAP API Business Hub documents them), covering most common business objects. Prefer these released APIs over custom ones where they exist — they are supported and upgrade-stable.

REST APIs and events

Beyond OData, two other doorways matter:

• RESTful APIs — some SAP capabilities and many BTP services expose plain REST/JSON, which web developers find natural to consume.
• Events — SAP can publish business events (an order created, a delivery shipped) onto the BTP Event Mesh. An event-driven integration reacts the instant something happens, instead of polling SAP on a timer. For real-time experiences — live order status, instant notifications — events are far more efficient than polling.

A mature integration uses synchronous APIs for request/response interactions and events for "tell me when something changes."

Authentication and security

This is where naive integrations get dangerous. The rules:

• Never embed SAP credentials in the front end. The browser is hostile territory; anything it holds can be read.
• Use OAuth 2.0 and token exchange. The integration layer authenticates the user (often via your identity provider and SAP Identity Authentication Service), then exchanges that identity for a token authorised to call SAP. Principal propagation carries the user's identity through to SAP so authorisations are enforced per user, not via a shared service account.
• Put SAP behind the integration layer. SAP systems should not be directly reachable from the public internet. The integration layer is the only thing that talks to SAP, over a private connection (for example, the SAP Cloud Connector for on-premise systems).
• Apply rate limiting and input validation at the API layer to protect SAP from accidental or malicious overload.

Performance: do not make SAP do the UI's work

SAP transactions can be expensive. A responsive app needs to be thoughtful:

• Request only what you need using OData $select and pagination — never fetch a whole entity set to display ten rows.
• Cache reference data (currencies, plants, material types) that changes rarely, in the integration layer or a fast store, rather than hitting SAP on every page load.
• Aggregate in the backend-for-frontend. If a screen needs data from three SAP services plus one external system, compose it server-side and send the UI one clean payload, rather than making the browser orchestrate four calls.
• Use events for freshness so the UI updates on change rather than polling SAP repeatedly.

A reference pattern

A common, durable pattern looks like this:

Web / mobile app
      │  (HTTPS, user's session token)
Backend-for-frontend on BTP
   - validates token, propagates identity
   - calls released OData/REST APIs
   - composes + caches responses
   - subscribes to Event Mesh for live updates
      │  (private connection / Cloud Connector)
SAP S/4HANA

This keeps the SAP core clean, secures every hop, gives the front end a fast purpose-built API, and leaves room to add new channels later without touching SAP.

It is also, broadly, the architecture we implement on SAP integration projects at Codememory: a dedicated integration layer between SAP and the apps, released APIs over custom ones wherever possible, identity propagated end to end, and events for anything that needs to feel real time.

Common pitfalls

• Calling SAP from the browser. Exposes credentials and the SAP system. Always route through a backend.
• Building custom OData services when a released one exists. Custom services are yours to maintain and may break on upgrade.
• Polling instead of subscribing to events. Wastes capacity and feels laggy. Use the Event Mesh for change notifications.
• No caching of reference data. Hammers SAP for values that almost never change.
• Treating SAP as a generic database. It is a system of record with business logic and authorisations; respect its APIs rather than reaching around them.

The bottom line

Integrating SAP with modern web and mobile apps comes down to a clean three-layer architecture: a fast front end, a secure integration layer on BTP, and SAP exposing its business objects through released OData and REST APIs plus events. Keep credentials and SAP itself behind that integration layer, propagate user identity end to end, request only the data you need, and use events for real-time freshness. Get the architecture right and SAP becomes a dependable backend for genuinely modern user experiences.