What SAP’s changing API Policy Actually Requires of Utilities
The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.
Buried in section 1.2 of SAP’s new API Policy is a sentence that converts years of good advice into an obligation: customers and partners are “required to verify that each endpoint … is a Published API.” Read that again. Not encouraged. Not recommended as a best practice. Required. The integration inventory your architecture team has been deferring since the last rate case is now, formally, part of the Documentation that governs your SAP solution. The audit is no longer something a consultant sells you. It is something you already owe.
Some context for anyone who missed Sapphire and the changes that AI has brought to our community. In late April, SAP published API Policy v.4.2026a—two pages that standardize how APIs, extensions, and data transmission interfaces may be used across the portfolio, cloud and on-premise alike. The policy now has a permanent home on the SAP Help Portal, under the Business Accelerator Hub documentation, alongside an official FAQ. The initial reaction was loud and mostly unhelpful. Then something this series cares about happened: the user groups went to work. DSAG published a public call for clarification, ASUG briefed its members, both sat down with SAP—and the FAQ has been revised repeatedly with their input: version 1.1 by Sapphire, version 1.3 by June, now answering fifty-six questions. Last month this column documented the agreement between SAP, DSAG, and our own community lists; the FAQ’s revision history is that agreement operating in real time. This month is the follow-through: what does a utility actually do with the policy now that the shouting has died down?
Listen to the questions our community keeps asking—in the DSAG clarification process, in ASUG briefings, in the threads on our own community sites—and they sort themselves into three: Which of our integrations sit on the wrong side of the published-API line? Which of our AI experiments are driving in an endorsed lane? And what happens to our limits when agents multiply the traffic? Those are the right questions, and our industry carries specific exposure the generic enterprise versions of them miss. So let us build the utility audit around them—three layers, each with a name you can carry into your next architecture review.
Layer One: The Glue We Forgot We Poured
No utility runs IS-U or S/4HANA Utilities alone. The core sits inside a mesh: the AMI head-end, the meter data management system, OMS and ADMS, GIS, workforce management, bill print and payment vendors, credit agencies, regulatory reporting, and the analytics landscape fed from our own data lakes or BW. Much of that mesh was poured ten or twenty years ago as RFC calls, BAPIs, and IDoc flows—some of it by integration partners who no longer exist, documented in binders that no longer exist either. That glue is what the policy now sorts into three piles.
Pile one is Published APIs: anything listed on the SAP Business Accelerator Hub, the Help Portal, or a dedicated product portal. These remain available for their documented purposes within the limits SAP maintains per API. MDUS for Meter data management integration as an example.
Pile two is non-published interfaces: SAP-internal or private APIs, and anything bound to SAP-reserved clients. The policy now says customer and third-party applications must not touch these, and that they may change or be removed without notice. The FAQ softens the cliff without removing it: SAP says it will not retroactively invalidate existing integrations, and commits to advance notice and migration support where it identifies a genuine security risk—but the operative phrase for pile two is “at your own risk.” No stability guarantees, no support obligations.
Pile three is the interfaces SAP has explicitly shut by SAP Note, with ODP-RFC as the poster child—a mechanism built for SAP-to-SAP communication that a generation of third-party extraction tools quietly adopted, and which many utility analytics landscapes depend on today. If your BW feeds run on it, the FAQ names the supported alternatives: SLT under its documented use cases, analytical CDS views, and Business Data Cloud with Delta Sharing. (See below Section 4 of the policy states it does NOT limit SAP’s legal obligations on data export and egress).
Notice what the policy does not say. Commentary this spring spoke of a single published-API-only requirement with an enforcement date. The reality is now a three-way sort with very different consequences per pile—and one carve-out that matters enormously to this community: custom-developed ABAP interfaces in private cloud and on-premise deployments are expressly permitted. The FAQ goes out of its way to say the policy does not reach into the Z namespace and condemn two decades of legitimate ABAP engineering. For a membership still heavy on ECC and RISE private cloud, that is significant relief. But “not prohibited” is not the same as “supported,” and utilities run mission-critical processes—billing, settlement, outage response—across exactly the seams where pile two lives.
The audit deliverable for this layer is concrete, and the FAQ essentially hands you the template: an internal API inventory per system—namespace, interface type, purpose, owning team—with each interface classified into the three piles and the business process it carries written next to it. The ABAP Test Cockpit’s cloud readiness checks will find dependencies in your own code, and SAP says explicitly prohibited APIs will soon be auto-flagged in ATC runs and the S/4HANA Simplification Item Catalog. Nothing finds the dependencies hiding in your vendors’ code except asking them—in writing, before your next upgrade window.
Layer Two: The Lane AI Agents Must Drive In
Section 2.2.2 is the clause that generated the headlines, and for once the headlines were pointed at the right paragraph. Paraphrased: except through SAP-endorsed architectures, data services, or service-specific pathways, API use is prohibited for interaction with autonomous or generative AI systems that plan, select, or execute sequences of API calls—and likewise for scraping, harvesting, or large-scale extraction and replication. In plain terms: agents get a lane, and they are required to drive in it.
The endorsed lane is wider than the early coverage suggested. The FAQ names three production pathways: the MCP Gateway on SAP Integration Suite as a governed, customer-managed entry point; SAP-provided MCP servers generated via Joule Studio for SAP-centric agents on BTP; and the Agent2Agent protocol, via the SAP Agent Gateway, for orchestrating SAP-managed agents from outside. Two clarifications matter for utility architects. First, Integration Suite is not mandatory—the compliance criterion is the API surface and the usage pattern, not the integration platform, so third-party middleware consuming Published APIs within the controls is aligned. Second, custom and third-party MCP servers are not banned: the FAQ permits them provided they use Published APIs, enforce authentication and authorization on every connection, and respect the documented limits—but you own their design, operation, and maintenance. If your innovation team has wrapped a homegrown MCP server around a stack of RFC calls so a language model can query customer accounts—and in this community, someone has—that architecture is now inside the policy’s scope: not forbidden, but formally yours to govern and yours to fix.
For utilities the exposure is not hypothetical. The storm-response copilot that reads outage data, the contact-center assistant summarizing an IS-U account, the vegetation-management agent cross-referencing work orders—every one is an AI system executing sequences of API calls against SAP data. One useful boundary the FAQ draws: rule-based RPA running pre-defined, deterministic call sequences—of which utility back offices have plenty—is outside section 2.2.2’s scope, though still subject to the broader policy. The audit deliverable here is an inventory of every AI experiment, pilot, and production workload that touches SAP, classified by pathway: endorsed, arguably endorsed, or unsanctioned.
One correction to the commentary circulating since April, because precision matters when the stakes are contractual. You will hear that agent interaction must route through SAP channels unless “substitutability rights” have been secured in writing. That language appears nowhere in the policy or the FAQ; there is no such clause to invoke. The real negotiating surface is the word “endorsed”—what qualifies, who decides, and how fast the list grows. It is already growing: SAP’s CTO confirmed to diginomica that a partner’s MCP solution built on BTP Cloud Foundry with SAP’s own security is valid, and the FAQ commits to expanding endorsed pathways as the MCP specification hardens. The right question for your account team is not about rights you will not find in the document; it is whether the architecture you intend to run is on the validated list, and what it takes to get it there.
Layer Three: The Ceiling Set by Yesterday’s Traffic
The quietest layer is the one with the numbers. The policy’s specific controls—maintained per API in the documentation—include rate limits, throttling, data ingress and egress quotas, preconditions for bulk extraction, and deprecation schedules. The FAQ now documents the methodology: where new rate limits are introduced, they will generally be informed by observed usage patterns such as 99th-percentile traffic levels, with thresholds set above the vast majority of real-world usage. It also commits to sequence: for existing integrations, the stated intent is not to throttle without prior engagement—SAP says it will make contact, review the use case, and work jointly on optimization or an alternative pattern first.
Here is the utility problem. The 99th percentile of yesterday’s workloads was measured on pre-agentic traffic. Utility API consumption is already lumpy in ways generic SaaS traffic is not: interval-data loads that spike with weather, month-end billing runs, settlement windows, storm events that multiply transaction volume precisely when the system matters most. Now add agents. SAP’s own FAQ explains the rationale with an arresting observation—a single prompt to an AI orchestration harness can fan out into thousands of API calls, in patterns transactional APIs were never designed to absorb. The ceiling calibrated to your pre-agent baseline arrives much earlier than the language suggests once agents are in production. And an agent that hits a throttle mid-storm is not a licensing inconvenience; it is an operational event.
The audit deliverable for this layer: model your 2027 API consumption under your actual agent roadmap—calls per prompt, prompts per user, users per process—and compare it against the documented limits for the APIs you depend on. The utilities that walk into renewal with modeled numbers will get a conversation. Those that do not will inherit the defaults.
One more item belongs in this layer’s file. Section 4 of the policy states it does not limit SAP’s legal obligations on data export and egress, including portability and switching, and Christian Klein has said publicly, twice, that SAP will not charge customers for access to their own data. Between the legal floor and the CEO’s promise, the data-toll-road fear has a stated boundary. But file this FAQ sentence next to it: as new pathways for large-scale data and agentic access evolve, so too will SAP’s technical options and commercial models. Keep watching.
Honest Caveats
First, I am not a lawyer, and neither is this column. Whether a policy posted to a help portal actually binds you depends on your contract—how it defines Documentation, what its amendment clauses permit, whether portal terms can impose new obligations at all. Legal analyses published since April make exactly this point: the contract review comes before the technical audit. Do both. And note the asymmetry between the two documents: the policy states it forms part of the Documentation; the FAQ opens by disclaiming any contractual force. The reassurances live disproportionately in the non-binding document. When a FAQ commitment matters to you—advance notice, engagement before throttling, the 99th-percentile practice—the durable move is to get it into your agreement or the product documentation, not to bookmark the PDF.
Second, this is a moving document—verify everything here against the current versions before it drives a decision. The FAQ went from version 1.0 to 1.3 between April and June, the ODP guidance lives in its own Notes, and definitions will keep being clarified through individual customer conversations. That velocity is mostly good news: it is the user-group influence loop working. But it means any article, this one included, is a snapshot.
Third, SAP’s stated rationale deserves to be taken at face value. Unidentified agents probing production systems, static credentials in community-built MCP servers, supply-chain attacks on SAP-ecosystem packages—these are real, and a utility should want its ERP vendor closing those doors. This is not a toll-road accusation. But auditable control is also monetizable control, and the FAQ itself notes that commercial models will evolve alongside the new access pathways. The line Klein drew—no charging customers for their own data—is the line this community should hold him to, publicly and often.
Fourth, the relief in the carve-outs is provisional. An ECC utility running mostly custom ABAP may find less immediate exposure than the spring headlines implied. But every one of those utilities is facing a migration, and the migration converts today’s tolerated interfaces into tomorrow’s audit findings. The FAQ is explicit that remediation of integrations relying on non-published APIs is not automatically included in standard RISE scope—it is the customer’s responsibility unless specific contractual provisions are agreed. The inventory you build now is the remediation scope you will negotiate into your RISE contract. Ask before you sign.
Where Are You in the Inventory?
The question this community keeps asking one another is where everyone actually is in this process—so let us make it specific. Have you run the three-pile sort on your integration landscape? What fraction of your interfaces landed in pile two—and did any of your mission-critical flows turn out to be standing on ODP-RFC? Has anyone inventoried the AI experiments touching SAP data, or modeled agent-era API consumption against the published limits? If you have numbers, bring them—even rough ones. The utilities that compare inventories before renewal season will negotiate from evidence rather than anecdote. That is a working-group conversation waiting to happen, and this community is the table it belongs at. What are you seeing?