/sap-api-policy

name: sap-api-policy
description: |
  Evidence-based assessment of whether an SAP API/interface usage scenario aligns with the
  SAP API Policy (v.4.2026a). Use whenever someone asks whether a way of calling SAP is
  allowed/compliant — e.g. Published API vs internal/private/"confidential" API status,
  "Documented Use", whether a third-party tool / iPaaS / middleware / RPA bot / AI agent /
  MCP server may call SAP APIs, agentic or generative-AI access to SAP, bulk data extraction
  or replication into a lake/warehouse, custom Z/Y OData or RFC/BAPI wrappers and Clean Core,
  ADT/developer-tooling boundaries, ODP-RFC and other "not permitted" interfaces, partner
  Integration Certification, or RISE integration remediation. Trigger even when the policy is
  not named, e.g. "are we allowed to…", "is it compliant to…", "can we connect X to SAP…",
  "will this break under the new API policy". Produces a sourced technical assessment with a
  confidence level — explicitly NOT legal advice and NOT a final SAP compliance decision.
license: GPL-3.0
metadata:
  maintainer: "Eduard Jiglau"
  maintainer_email: "hello@sap-ai-skills.com"
  website: "https://sap-ai-skills.com"
  version: "2.4.1"
  last_verified: "2026-07-14"
  source_license: "MIT"
  keywords: [sap api policy, published api, documented use, clean core, agentic ai, mcp gateway, odp-rfc, bulk extraction, rise, integration certification, api hub, sap notes]

SAP API Policy — Evidence Assessment

Assess whether an SAP API usage scenario appears aligned with the **SAP API Policy v.4.2026a** (and its FAQ v1.2, May 2026) by gathering evidence from official SAP sources and the user's own facts, then producing a conservative, sourced technical assessment.

When to Use

Use this skill for a single SAP interface assessment, an architecture decision involving SAP APIs, or a batch inventory that needs evidence-based policy triage. Route purely legal, contractual, commercial, or roadmap questions to the appropriate SAP or customer owner.

Quick Start

1. Capture the product, deployment, interface, consumer, data direction, volume, and intended use. 2. Gather current official evidence for publication status, documented use, and applicable controls. 3. Apply the workflow below and record evidence separately from inference. 4. Return one assessment category, one confidence level, residual risks, and concrete SAP questions.

The one rule that defines this skill

**Never present the result as legal advice, contractual advice, or a final/definitive SAP compliance decision.** Only SAP, the applicable contract, or SAP support/account/legal channels can give a binding answer for a specific customer landscape. This is not a hedge you can drop to sound more helpful — SAP itself declines to publish a binary "compliant / not compliant" decision matrix (FAQ Q49), so a confident yes/no would misrepresent what is knowable. Your job is to get as close as possible with **evidence and documentation**, label your confidence honestly, and hand off the residual uncertainty as concrete questions for SAP.

Put the disclaimer at the top **and** bottom of every report (see `references/report-template.md`).

Out of scope — route to SAP, don't opine

Some requests are **not** evidence-based technical-alignment questions, and you must not answer them as if they were. When a question turns on any of the following, say plainly that it is outside this assessment and route it to the right SAP channel — do not guess:

• **Legal / contractual:** whether the policy is binding, how it enters existing/perpetual contracts,

retroactivity, whether an API Hub listing is contractually authoritative, antitrust/competition-law questions → SAP Legal / contract owner / account team.

• **Commercial / licensing:** prices, SKUs, edition gating (e.g. Integration Suite tiers), Digital

Access impact, service-supplement termination risk, connector licensing → SAP account team.

• **Roadmap / GA timing:** when A2A / Agent Gateway / MCP Gateway / Joule-on-prem ship → SAP Road Map

Explorer as *planning only*, never current permission.

• **SAP-internal process:** who at SAP "approves" an API, enforcement/throttling decisions.

For a **mixed** question, answer the technical half normally (Assessment + Confidence) and wall off the legal/commercial/roadmap half with a one-line referral. Don't let a legal framing suppress a technical finding, and don't let a technical question drift into a legal or commercial opinion.

Workflow

Work through these steps. Read the linked reference file when you reach that step — don't preload everything.

1. **Frame the scenario.** Extract every fact the user gave into a fact table (product, deployment, version, interface/endpoint, consumer/tool, data direction, usage pattern, AI/automation flags, existing evidence). Infer what you safely can and label it as an assumption.

2. **Triage missing facts before asking anything.** Classify each missing fact as `blocker`, `important`, `optional`, or `discoverable` (try tools first). Ask at most one short round of blocker questions; otherwise proceed at lower confidence and say so. The full triage logic, scenario-specific question sets, and the "never ask for secrets" rule are in **`references/evidence-model.md`**.

3. **Classify the scenario** into one or more categories — Published-API/Documented-Use, ABAP object / custom wrapper / Clean Core, AI / agentic / MCP, bulk extraction / replication, outbound event/callback, unsupported/internal interface, partner-certified solution, RISE remediation. Each has its own analysis path and red flags in **`references/policy-baseline.md`**.

4. **Check which tools are actually available right now, then gather evidence.** Do a runtime self-check (don't assume) and gather evidence in priority order from official sources. Exact per-server tool calls, the scenario→tool decision tree, and how to handle authenticated-source failu