---
title: "How to Export Data from SAP S/4HANA: Extraction Methods, API Limits, Portability"
slug: how-to-export-data-from-sap-s4hana-extraction-methods-api-limits-portability
date: 2026-09-18
author: Roopendra Talekar
categories: [SAP S/4HANA]
excerpt: "Complete guide to SAP S/4HANA data extraction: OData API limits, CDS views, ODP framework, Customer Data Return, and how to choose the right method for your deployment model."
tldr: "SAP S/4HANA extraction methods vary by deployment model. Cloud Public restricts you to OData APIs, CDS views, and Fiori apps. On-Premise gives full table, RFC, and ODP access. There's no universal rate limit—plan per API."
canonical: https://clonepartner.com/blog/how-to-export-data-from-sap-s4hana-extraction-methods-api-limits-portability
---

# 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](https://clonepartner.com/blog/blog/sap-ecc-vs-s4hana-architecture-tco-and-migration) 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.

> [!WARNING]
> Do not assume extraction methods work identically across deployment models. S/4HANA Cloud and On-Premise have different API catalogs—not all Cloud APIs exist On-Premise and vice versa. Always verify on [api.sap.com](https://api.sap.com) before building an integration.

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

| Capability | First Available | Edition | Reference |
|---|---|---|---|
| CDS-based DataSources (ODP_CDS) | S/4HANA 1809 On-Premise | On-Premise | SAP Note 2232584 |
| Date/Timestamp-based delta extraction | S/4HANA 2018 | On-Premise, Cloud Private | SAP Help: CDS Delta Extraction |
| CDC-based delta (trigger-based) | S/4HANA 2019 | On-Premise, Cloud Private | SAP Note 2890171 |
| Custom CDS Views app (extraction-enabled) | S/4HANA Cloud 2302 | Cloud Public | SAP Help: Custom CDS Views |
| Cloud Data Integration (CDI) API | S/4HANA Cloud 2020 | Cloud Public | SAP Note 2873666 |
| OData V4 as default for new APIs | 2025 (new APIs only) | All editions | SAP API Strategy Blog, api.sap.com |
| Customer Data Return app | All Cloud Public versions | Cloud Public | SAP Help: Customer Data Return |

## 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:

| Method | Cloud Public | Cloud Private | On-Premise | Best for |
|---|---|---|---|---|
| OData APIs (V2/V4) | ✅ | ✅ | ✅ | Real-time reads, individual records, API-driven integrations |
| CDS views (extraction-enabled) | ✅ | ✅ | ✅ | Mass data extraction to BW/Datasphere |
| Custom CDS views | ✅ (since 2302) | ✅ | ✅ | Tailored extraction when standard views don't cover your fields |
| Customer Data Return app | ✅ | ❌ | ❌ | Full bulk download of all customer data |
| Customer Data Browser | ✅ | ✅ | ❌ | Object-by-object data browsing and .xlsx export |
| ODP (via RFC or SOAP) | ✅ (SOAP) | ✅ | ✅ (RFC) | Delta extraction to BW/4HANA or Datasphere |
| SAP Integration Suite (Cloud Integration) | ✅ | ✅ | ✅ | Middleware-orchestrated extraction, event-driven pipelines |
| SE16 / direct table access | ❌ | ❌ | ✅ | Quick ad-hoc exports, debugging |
| RFC / BAPI | ❌ (limited whitelisted) | ✅ | ✅ | Legacy integrations, batch processing |

## 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](https://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](https://help.sap.com))
- **Purchase Order OData API**: default page size 1,000 records, maximum 5,000 with `$top` ([SAP Help: Purchase Order API](https://help.sap.com))
- **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](https://help.sap.com)). 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:

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

OData V2 error responses use a different envelope:

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

> [!TIP]
> If you need a hard numeric throughput limit for architecture documentation, open an SAP incident for the specific API(s) and tenant context. SAP support can provide tenant-specific guidance that is not published in general documentation.

## 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:

```abap
@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

> [!NOTE]
> Always use the view preview within the Custom CDS View app to confirm the expected result set and check performance before deploying to production. Production environments with larger datasets will have longer runtimes.

## 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:**

| Criterion | Use ODP | Use OData |
|---|---|---|
| Target system | BW/4HANA, Datasphere, Data Services | External apps, middleware, custom integrations |
| Volume | Millions of records | Thousands of records |
| Sync pattern | Full + delta (CDC) | Real-time, record-level |
| Delta support | Native (timestamp + CDC) | Manual (filter by timestamp field) |
| Connection type | RFC (on-premise), SOAP (cloud) | HTTP/HTTPS |

## 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](https://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](https://clonepartner.com/blog/blog/why-erp-migrations-fail-at-the-data-layer-9-core-patterns):

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](https://clonepartner.com/blog/blog/what-data-should-you-actually-migrate-to-your-new-erp), 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.

> Need to extract data from SAP S/4HANA for a migration or integration? Our engineers have built extraction pipelines across Cloud Public, Private, and On-Premise deployments. Book a 30-minute call to scope your extraction.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

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

SAP does not publish a universal rate limit. Throughput is approximately 100 requests/second per endpoint with burst to 200 rps in Cloud Public Edition. Specific APIs like Journal Entry Post recommend no more than 15 parallel synchronous calls. The max payload size is 500 MB, and OData V4 URL length is limited to 8,000 characters. Open an SAP incident for tenant-specific hard limits.

### How do I export all data from SAP S/4HANA Cloud Public Edition?

Use the Customer Data Return app to download all customer business data (including archived data) to a local machine. For selective extraction, use CDS views via the Customer Data Browser or ODP-based extraction to BW/4HANA. Direct database access and RFC/BAPI calls are not supported in Cloud Public Edition.

### What is the best way to extract large volumes of data from S/4HANA?

For datasets exceeding 50,000 records, use CDS views with ODP-based extraction (supporting both full and delta modes) rather than OData APIs. OData is designed for real-time, record-level access and has page size caps of 5,000 records per request. For on-premise systems, SLT replication with CDC is also available.

### Can I use RFC or BAPI to extract data from S/4HANA Cloud?

Direct RFC/BAPI access is not supported in S/4HANA Cloud Public Edition. Only a limited set of whitelisted BAPIs are available through SAP Communication Scenarios. SAP's strategic direction is OData APIs and CDS views. RFC/BAPI remain fully available on S/4HANA On-Premise.

### What is the difference between CDS views and OData APIs for S/4HANA extraction?

CDS views are virtual data models optimized for mass data extraction and analytics, supporting delta/CDC extraction via the ODP framework. OData APIs are RESTful endpoints suited for real-time, record-level CRUD operations. Use CDS views for data warehousing and bulk extraction; use OData for custom integrations and real-time access.