Skip to content
SAP Datasphere

Datasphere custom REST API connections are now generally available

SAP Datasphere custom connections to REST APIs are now GA in all landscapes. What your API must offer, how delta works and the limits that matter.

By 6 min read
Cover about SAP Datasphere custom REST API connections loading JSON into the object store with replication flows
Table of contents

How many times have you built an integration flow just to get data from a SaaS application with no standard connector into Datasphere? Since wave 2026.22 (What’s New entry dated 20 October 2026), SAP Datasphere lets you define custom connection types for any REST API and load its JSON into the object store with replication flows. Here is what it expects from the API, how delta works and its limits.

What changed and its status

The feature is not brand new. In the July 2026 SAP Business Data Cloud highlights it was listed as a restricted release, only in EU10 landscapes and subject to an activation request (SAP Note 3696110). In the October highlights, SAP declares it generally available across all landscapes: the EU10-only restriction is gone. The SAP Datasphere What’s New lists it as new in version 2026.22.

How it works: connection type, connection and replication flow

There are three pieces:

  1. Custom connection type (Custom Connection Types tab in Connections). This is the blueprint. You define resources (endpoints, always GET), their parameters, the response schemas and, per resource, pagination, requests-per-second limits and retryable status codes. You also define actions: which resource to call, with which parameter values, where the records are (records locator) and which attributes are keys. Resources can be imported from an OpenAPI-based JSON file, but only while the type has none yet.
  2. Connection. Created from the type: base URL, authentication and which actions are offered to replication flows.
  3. Replication flow. You pick an action as the source container and SAP Datasphere (HDL_Files) as the target. Each entity of the action becomes a replication object and its target table is generated automatically.

Each nested level of the JSON with a key becomes a child entity, linked to its parent by a foreign key. An example with a made-up API:

GET /orders response
{
  "orders": [
    {
      "orderId": "P-1001",
      "updatedAt": "2026-10-28T09:15:00Z",
      "lines": [{ "lineNo": 1, "sku": "A-01", "qty": 3 }]
    }
  ],
  "next": "https://api.example.com/orders?page=2"
}

Here the records locator would be $.orders, keyed by orderId. If you set lineNo as a key inside lines, you get a second entity for the lines. Keys are defined from the outermost level inwards. And next fits the Next URL pagination method.

Checklist: is your API compatible?

Before committing to dates, I would go through this with the team that owns the API:

Requirement What the documentation asks for
Base URL Reachable HTTPS that resolves to a real public IP address
Format JSON only. No XML, CSV or binary
Records location An array of objects at a fixed, predictable path
Schema Stable and expressible as a schema; fully dynamic responses are not supported
Pagination Page, Offset, Next URL or Cursor. If the API does not paginate or uses its own mechanism that doesn’t fit those four, it can’t be used
Keys At least one attribute that uniquely identifies elements in every nested array you want as an entity
Authentication Basic, mTLS, OAuth 2.0 (authorization code or client credentials) or custom. Nothing interactive or browser-based

SAP advises against custom authentication with query parameters, because those values can end up in the external system’s logs.

Delta and the limits you need to know

The only load type is Initial and Delta, and loading is an upsert (insert and update). Real delta depends on the API: you need a filter parameter the API supports, filled with the ${lastRunTime:<format>} placeholder, for example updatedSince=${lastRunTime:ISO}. On the first run the placeholder resolves to a date in the year 2000, to fetch history; afterwards, to the last successful run. Without it, every delta run processes all records again.

The limits, according to the documentation:

  • Deletions are not propagated: records deleted in the API are not deleted in Datasphere.
  • You cannot rename target tables or map to an existing one. The name is <connection>_<action>_<entity>, with at most 15, 45 and 40 characters per part. If truncation produces duplicate names, deployment fails.
  • No filters, mappings or source settings; no schema changes after deployment; and no pausing, resuming or retrying individual objects.
  • No primary key, no replication. Unsupported types (time, timeofday, geometries, strings over 5,000 characters) are skipped, and arrays of simple types are not replicated.
  • If you enable format or allowed-value validation on an attribute and a value fails, the whole row is dropped.
  • No connection validation, and no management via the CLI or the Connections API.
  • If the file space already existed, you must redeploy it before creating and using a connection of this kind.

How I would use it in a project

To me it fits as a landing layer for SaaS data: the replication flow lands flattened JSON in local tables (file) and a transformation flow prepares it for the model. It does not replace Integration Suite when you need orchestration or write-back, but it removes a middle component in the most common case: read and load.

Three tips:

  • Short names by design: technical names cannot be changed later.
  • Plan for deletions: if the API deletes records, schedule a periodic full reload or ask the API team for a soft-delete flag.
  • Permissions: creating types and connections needs the Data Warehouse Connection (CRUD) and Space Files (CRUD) privileges in the space. The DW Space Administrator and DW Integrator role templates include them.

On cost: the documentation requires resources allocated to the object store, but I have not found commercial information specific to this feature. If volumes are significant, ask SAP before sizing.

Conclusion

This is one of those unflashy features that saves infrastructure. If you have SaaS sources in the backlog that today arrive as files or through read-only integration flows, run the checklist on one of them and try a connection type in a development file space. Validate delta and deletions above all before going to production.

Sources

Keep reading