How to Export Data from SAP S/4HANA: Extraction Methods, API Limits, Portability

How to Export Data from SAP S/4HANA: Extraction Methods, API Limits, Portability

Getting data out of SAP S/4HANA is harder than it should be—and the right approach depends entirely on whether you're running Cloud Public Edition, Cloud Private Edition, or On-Premise. Each deployment model exposes different interfaces, imposes different constraints, and requires different tooling. This guide covers every supported extraction method, the real API limits SAP publishes, traceable references for numeric claims, and what data portability actually looks like when you need to move your data somewhere else.

Three deployment models, three different extraction surfaces

SAP S/4HANA is available in three deployment models: Cloud Public Edition (multi-tenant SaaS), Cloud Private Edition (single-tenant managed), and On-Premise (customer-managed). The extraction methods available to you are fundamentally different depending on which model you're running.

Cloud Public Edition is the most restrictive. Direct access via IDoc, BAPI, or database tables is not supported. SAP Data Services (BODS) cannot extract data through Cloud Connector or RFC in this edition. Your extraction options are limited to OData APIs, CDS views, and SAP-provided Fiori apps.

On-Premise gives you the widest range of options: transaction SE16 for table-level exports, RFC/BAPI calls, direct database queries, CDS views, ODP-based extraction, and the full OData API surface.

Cloud Private Edition sits between the two—you get more access than Public Cloud but within a managed infrastructure.

Capability and version matrix by extraction method

The following table consolidates which S/4HANA release introduced each extraction capability. Scattered release references are a common source of planning errors; this matrix is intended as a single reference point.

What are the main ways to extract data from SAP S/4HANA?

The six primary extraction methods are: OData APIs, CDS views (standard and custom), the Customer Data Return app, the Customer Data Browser app, the ODP framework, SAP Integration Suite, and direct table/RFC access (on-premise only). Here's how they compare:

OData APIs: the primary programmatic interface

OData (Open Data Protocol) is the primary programmatic extraction interface for SAP S/4HANA. The API surface is built on the SAP Gateway framework (V2) and the ABAP RESTful Application Programming Model, known as RAP (V4). SAP exposes a rich catalog of OData V4 APIs on the SAP Business Accelerator Hub at api.sap.com.

SAP's direction: starting in 2025, all new APIs are OData V4 exclusively. However, many business objects still only have V2 APIs as of early 2026, so always check the API catalog before assuming V4 availability. SAP Note 2836302 tracks the deprecation schedule for OData V2.

How to paginate large OData result sets

OData pagination in S/4HANA uses $skip/$top (client-driven) and server-driven pagination via @odata.nextLink. The default and maximum page sizes are API-specific—SAP does not enforce a single universal number.

Documented page sizes from SAP Help and API specifications:

• Product APIs: default page size 100 records, maximum 5,000 with $top (SAP Help: Product API)
• Purchase Order OData API: default page size 1,000 records, maximum 5,000 with $top (SAP Help: Purchase Order API)
• Custom OData APIs: maximum 5,000 records per fetch, not configurable by the caller
• Server-driven pagination on-premise: enforced at approximately 1,000 records per page by default; configurable via SAP Gateway profile parameter icm/max_message_size

If your extraction target exceeds 50,000 records, OData is typically the wrong tool. SAP's own architecture guidance recommends IDoc or file-based approaches for datasets above that threshold.

What are the OData API rate limits for S/4HANA Cloud?

SAP does not publish a single universal numeric rate limit for S/4HANA Cloud OData APIs. Limits are API-specific and tenant-context-specific. For tenant-specific hard limits, open an SAP incident (component BC-ESI-WS-REST or the relevant API component) and request service specifications for your tenant.

What SAP does document:

• Journal Entry Post API: SAP explicitly recommends no more than 15 parallel synchronous calls and 30 parallel asynchronous calls (SAP Help: Journal Entry Post API Performance Guidelines). SAP states these are guidelines that may change depending on resource usage by other tenants.
• OData V4 URL length limit: 8,000 characters (SAP Note 2736234)
• Maximum payload size, S/4HANA Cloud Public Edition: 500 MB per request
• Maximum payload size, SAP BTP ABAP Environment: 400 MB per request (SAP Note 3165079)
• Batch operations: processed sequentially within a batch request, not in parallel—do not assume high-throughput bulk behavior from OData $batch

HTTP error handling for OData rate limits

When SAP S/4HANA Cloud throttles a request, it returns HTTP 503 (Service Unavailable) rather than HTTP 429. The response does not consistently include a Retry-After header in all scenarios. SAP OData V4 error payloads follow this structure:

{
  "error": {
    "code": "SERVICE_UNAVAILABLE",
    "message": "Service is temporarily unavailable",
    "target": null,
    "details": []
  }
}

OData V2 error responses use a different envelope:

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
  <code>SERVICE_UNAVAILABLE</code>
  <message xml:lang="en">Service is temporarily unavailable</message>
</error>

Engineering recommendation: implement exponential backoff starting at 2 seconds, doubling up to a maximum of 60 seconds, with jitter. Do not rely on Retry-After header presence. Log the full error payload including the x-vcap-request-id response header—SAP support requires this value when diagnosing throttling incidents.

CDS views: the strategic extraction method

CDS (Core Data Services) views are virtual data models on SAP HANA that provide a semantic abstraction layer over raw database tables. CDS-based extraction is SAP's recommended and strategic method for getting data out of S/4HANA, especially for analytics and data warehouse integration.

The CDS-based DataSource approach replaces the older S-API (service API) extractors for BW integration. The first CDS-based DataSources shipped with S/4HANA 1809 on-premise (SAP Note 2232584). In S/4HANA Cloud, ODP_CDS is the strategic core interface for BW/4HANA extraction because the Cloud edition uses HTTP/SOAP-based connections rather than RFC.

For a CDS view to be extraction-enabled, it requires specific annotations:

@Analytics.dataCategory: #FACT
@Analytics.dataExtraction.enabled: true
@Analytics.dataExtraction.delta.byElement: {
  name: 'LastChangedDateTime',
  maxDelayInSeconds: 1800
}

Delta extraction is available in two flavors:

• Date/Timestamp-based delta: available since SAP S/4HANA 2018 (SAP Help: CDS Delta Extraction)
• CDC-based delta (Change Data Capture using database triggers): available since SAP S/4HANA 2019 (SAP Note 2890171)

What if a CDS view isn't extraction-enabled?

Before release 2302, if a standard CDS view wasn't marked as extraction-enabled, you had to raise a feature request via the Customer Influence Portal and wait for a future release. Since the 2302 release, the Custom CDS Views app lets key users create custom CDS views enabled for mass data extraction (SAP Help: Custom CDS Views, SAP Note 3326270).

Documented constraints for the Custom CDS Views app:

• Maximum 50 custom CDS views per tenant
• Maximum 100 fields per custom view
• Supported base views are restricted to the set exposed in the app's view browser—not all standard CDS views are available as a base
• The key user must be assigned business role including catalog SAP_CORE_BC_EXT_CCV ("Extensibility – Custom CDS Views"); the "Analytics Specialist" role (SAP_BR_ANALYTICS_SPECIALIST) includes this catalog

The ODP framework: full and delta extraction at scale

Operational Data Provisioning (ODP) is the unified technical infrastructure for extraction and replication of SAP data. It supports extraction with corresponding APIs and queues, enabling ETL to targets including SAP BW, SAP BW/4HANA, SAP Data Services, and SAP HANA SDI (Smart Data Integration).

In on-premise scenarios, consuming systems like BW call an RFC provided by the ODP framework. In S/4HANA Cloud, the same API is available via a SOAP service wrapping the RFC—this is the mechanism used by BW/4HANA Cloud when connecting to S/4HANA Cloud Public Edition. CDS-based extraction is also possible through the Cloud Data Integration (CDI) API (SAP Note 2873666), which provides an OData-based extraction interface built on top of ODP, available since S/4HANA Cloud 2020.

For delta extraction, ODP uses trigger-based change data capture: database triggers are created on the underlying tables, and whenever records are created, deleted, or updated, change information is written to change log tables. This is architecturally equivalent to the mechanism used by SAP Landscape Transformation (SLT), though they operate independently.

ODP vs. OData selection criteria:

SAP Integration Suite: middleware-orchestrated extraction

SAP Integration Suite (formerly SAP Cloud Platform Integration / CPI) is a significant omission in most extraction guides and deserves explicit coverage. It is available on SAP BTP and provides pre-built integration content (iFlows) for connecting S/4HANA to external systems.

For data extraction purposes, SAP Integration Suite operates as an orchestration layer rather than a direct extraction mechanism—it calls S/4HANA OData APIs or IDoc/SOAP endpoints on your behalf, transforms the payload, and routes to target systems. Key characteristics:

• Pre-built content: SAP Integration Content Catalog includes hundreds of pre-built iFlows for S/4HANA integration scenarios
• Supported protocols: OData, SOAP, RFC (via on-premise connectivity through Cloud Connector), IDoc, AMQP, Kafka
• Event-driven extraction: SAP Integration Suite supports SAP Event Mesh integration, enabling trigger-based extraction when S/4HANA business events fire (e.g., sales order created)
• Throughput constraints: SAP Integration Suite message processing limits depend on the service plan (see SAP BTP Service Description for current plan specifications—these change with SAP pricing updates and should be verified at help.sap.com/docs/integration-suite)

When to use SAP Integration Suite for extraction: when you need transformation logic between S/4HANA and the target, when you're already licensed for BTP, or when the target system has a pre-built connector in the catalog. When not to use it: for bulk extraction of millions of records, where ODP-to-BW/Datasphere or SLT is more appropriate.

SAP BTP data services for Datasphere-targeted extractions

For organizations routing S/4HANA data into SAP Datasphere (formerly SAP Data Warehouse Cloud), the recommended ingestion paths are:

1. SAP HANA Smart Data Integration (SDI) with the ABAP Adapter: enables real-time replication from S/4HANA via ODP. Requires Data Provisioning Agent deployment.
2. SAP Datasphere Data Integration (formerly Data Builder Flows): uses the CDI API (OData-based, SAP Note 2873666) for scheduled or real-time extraction from S/4HANA Cloud.
3. SAP BTP Data Ingestion Service: a managed ingestion pipeline service for high-volume streaming to SAP HANA Cloud. Relevant for IoT or high-frequency transactional data, less common for standard S/4HANA business object extraction.

For SAP Analytics Cloud consumers: SAC supports both live connections (real-time query pushdown to S/4HANA HANA views or CDS views—no data moved) and import mode (scheduled data replication into SAC's own store). Live connections require the S/4HANA system to be reachable via SAP Cloud Connector and are subject to query timeout limits (default 120 seconds, configurable). Import mode uses the CDI API or ODP. Choose live connection when query latency is acceptable and data residency in SAC is undesirable; choose import mode when offline availability or complex blending with non-SAP sources is required.

Customer Data Return: bulk export for decommissioning

Customer Data Return is an SAP-provided Fiori app that lets customers download all S/4HANA business data—including archived data—from an S/4HANA Cloud Public Edition tenant to a local machine. It is available under all S/4HANA Cloud Public Edition versions.

The main differentiator is its ability to export all customer business data in a single operation with a straightforward interface. This is the appropriate tool for tenant decommissioning or complete data dumps for compliance. SAP also provides it for post-contract-termination data retrieval under the terms of the data processing agreement.

Documented limitations:

• Performance degrades with large datasets—this is a browser-initiated download, not a streaming API; very large tenants may time out
• Attachments may hit payload size limits through the underlying Attachments API (500 MB maximum per request)
• The output format is not directly importable into another SAP system—data preparation and transformation are required before loading via Migration Cockpit
• There is currently no automated tenant-to-tenant transfer between two S/4HANA Cloud Public Edition instances; SAP has not published a supported migration path that bypasses this manual step

For object-by-object extraction, the Customer Data Browser app is simpler. It lets you view and export data from whitelisted CDS views to .xlsx format. It is not designed for mass extraction but works for validating specific datasets or exporting individual business objects.

On-premise extraction: SE16, RFC, SLT, and direct access

If you're running S/4HANA On-Premise, you have the broadest extraction surface:

SE16 / SE16N is the table data browser transaction in SAP GUI. It is fast for ad-hoc data exports but impractical for automated or large-scale extraction—there is no API equivalent, and output is limited to SAP GUI list formats or local file export.

RFC/BAPI calls remain available for on-premise systems and are the traditional workhorse for SAP integration. In S/4HANA Cloud Public Edition, only a limited set of whitelisted BAPIs are available via Communication Scenarios (e.g., SAP_COM_0636 for RFC Metadata Integration). SAP's long-term direction is moving away from RFC/BAPI toward OData and CDS views, formalized in the SAP Clean Core initiative.

SLT (SAP Landscape Transformation Replication Server) enables real-time data replication from S/4HANA to external targets using change data capture at the database level. SLT operates independently of the ABAP application layer and can replicate any table, including custom Z-tables.

SAP licensing matters for SLT. SLT is included in the SAP Product Availability Matrix (PAM) under separate licensing. With a RISE with SAP subscription, CDS view-based extraction via ODP is the recommended and typically only supported approach for replication scenarios. With an SAP S/4HANA Enterprise license and a separately licensed SLT installation, direct table extraction is available. Verify your specific license entitlements against the SAP Product Availability Matrix before building an SLT-dependent architecture. If in doubt, raise an SAP licensing inquiry before committing to an architecture that depends on SLT.

How do you handle attachments and documents?

Extracting structured data (master data, transactional data) is well-supported across all methods. Attachments and documents (PDFs, images, scanned invoices) require a separate pipeline.

In S/4HANA Cloud Public Edition, attachments are accessed via the Attachments API (OData-based). Key documented constraints:

• Each attachment must be fetched individually via a separate API call—there is no bulk download endpoint
• Large attachment volumes create significant API call overhead; plan for one HTTP round-trip per attachment
• Binary content is returned as base64-encoded stream; decode on the client side before writing to storage
• Payload size limit of 500 MB applies per request, not per attachment

For on-premise, attachments stored in SAP's Generic Object Services (GOS) or ArchiveLink are accessible via:

• Table SRGBTBREL for object-relationship links (identifies which documents are attached to which business objects)
• ArchiveLink HTTP interface for content retrieval (SAP Note 1946781 covers the ArchiveLink HTTP Content Server interface)
• BAPI ARCHIV_GET_CONNECTIONS for reading document connections programmatically

Attachment extraction consistently produces the highest project risk in S/4HANA data migration engagements. The root cause is architectural: structured transactional data flows through uniform channels (ODP, OData) with well-defined schemas, while attachments are distributed across multiple storage backends (GOS, ArchiveLink, DMS, third-party content servers) with inconsistent retrieval APIs. Identify attachment storage backends at project start, not midway through extraction development.

GDPR and data portability considerations

SAP complies with GDPR and holds third-party certifications (ISO 27001, SOC 1/2/3) validating its security and privacy practices. S/4HANA includes several data protection features relevant to extraction:

Information Retrieval Framework (IRF): implemented in S/4HANA Cloud for responding to data subject access requests under GDPR Article 15. The IRF searches across S/4HANA business objects for records related to a specific data subject (identified by business partner ID or similar key), and generates a structured report in PDF or XML format. To invoke IRF: navigate to the "Data Protection" Fiori app group, select "Manage Data Subject Information Retrieval," enter the data subject identifier, and trigger the retrieval job. Output includes person-identifiable fields across all configured business objects.

Consent Administration: built into S/4HANA for tracking processing consent per business partner and purpose. Consent records are extractable via OData API /sap/opu/odata/SAP/CA_BUPR_CONSENT_SRV.

Read Access Logging (RAL): tracks who accessed what personal data and when. RAL logs are configurable per field and are accessible via transaction SRALMANAGER (on-premise) or the corresponding Fiori app in Cloud editions.

When extracting data containing personal information (customer records, employee data, business partner details):

1. Confirm the extraction has a lawful basis under applicable privacy law (GDPR Article 6 or equivalent)
2. Ensure personal data is handled under your current Data Processing Agreement (DPA) with SAP—available via the SAP One Trust portal for RISE customers
3. For cross-border transfers outside the EEA: SAP uses Standard Contractual Clauses (SCCs) issued by the European Commission (2021/914/EU); RISE customers can access and sign DPA amendments via the SAP self-service portal
4. Apply encryption at rest and in transit to extracted datasets; SAP's shared responsibility model places encryption of extracted data outside SAP's control boundary

Choosing the right extraction method: a decision framework

Pick the extraction method based on three variables: deployment model, volume, and pattern (one-time vs. continuous).

START
│
├─ Cloud Public Edition?
│   ├─ One-time full dump → Customer Data Return app
│   ├─ Ongoing delta to BW/Datasphere → CDS views + ODP (SOAP) or CDI API
│   ├─ Real-time API access → OData V4 (with pagination + retry)
│   └─ Middleware orchestration → SAP Integration Suite iFlows
│
├─ Cloud Private Edition?
│   ├─ Ongoing delta to BW/Datasphere → CDS views + ODP (RFC or SOAP)
│   ├─ Real-time API access → OData V4
│   └─ Legacy integration → RFC/BAPI (verify whitelist with SAP)
│
└─ On-Premise?
    ├─ Volume > 1M records, ongoing → SLT (verify license) or ODP
    ├─ Volume > 1M records, one-time → ODP full extraction
    ├─ Volume < 50K records, real-time → OData
    ├─ Ad-hoc / debugging → SE16/SE16N
    └─ Legacy systems → RFC/BAPI

Volume thresholds as decision inputs:

• < 5,000 records per call: OData $top without pagination complexity
• 5,000–50,000 records: OData with $skip/$top pagination or nextLink following
• 50,000–1,000,000 records: ODP with scheduled jobs

• 1,000,000 records: ODP with CDC delta, SLT (on-premise with license), or Datasphere ingestion pipelines

Common failure modes in S/4HANA extractions

These are the patterns that most frequently derail S/4HANA extraction projects:

1. Assuming Cloud Public works like On-Premise. Teams design RFC-based extraction, then discover it's blocked at the Cloud Connector level. Validate the extraction interface against your specific edition before architecture sign-off.

2. Ignoring pagination limits. Requesting 100,000+ records in a single OData call without implementing $skip/$top or following nextLink tokens produces timeouts or silently truncated results. The API returns HTTP 200 with partial data—no error is raised.

3. No exponential backoff on HTTP 503. S/4HANA Cloud returns HTTP 503 (not 429) on throttling. Without retry logic, extraction jobs fail silently or lock out the integration user. Implement backoff starting at 2 seconds, doubling to 60 seconds maximum, with jitter.

4. Treating attachments as an afterthought. Structured data and binary attachments require completely different extraction pipelines. Identify attachment storage backends (GOS, ArchiveLink, DMS, third-party) at project start.

5. Not verifying CDS view extraction enablement. A CDS view existing in the system does not mean it has @Analytics.dataExtraction.enabled: true. Check the annotation before building a pipeline around any view.

6. Exceeding Custom CDS View app limits. The 50-view and 100-field-per-view constraints are hard limits. Projects that require more than 50 custom extraction views must either consolidate views or engage SAP via the Customer Influence Portal for a limit increase.

7. SLT architecture without license verification. Discovering mid-project that RISE licensing does not include SLT can force a full re-architecture. Verify against the SAP Product Availability Matrix before committing.

8. Missing the HTTP error payload x-vcap-request-id. When reporting throttling or failures to SAP support, this response header is required for log correlation. If your extraction framework does not capture response headers, SAP support cannot diagnose the incident.

When to bring in help

Extracting data from S/4HANA is technically well-documented but operationally complex. The intersection of deployment-model restrictions, API limits, licensing constraints, data privacy requirements, and attachment handling creates a surface area where practical experience with each layer reduces project risk materially.

If you're planning a one-time extraction for a migration, a continuous sync to a data warehouse, or an integration that needs to reliably move data out of S/4HANA into another system, that's work our team at ClonePartner handles across all three S/4HANA deployment models.