SAP AI Agent API: Options and Integration Patterns

What "SAP AI agent API" actually refers to

There isn't a single product called "the SAP AI agent API." The phrase covers two different things people search for: SAP's own AI agent infrastructure (SAP AI Core, the Generative AI Hub, and Joule agents built on SAP Business Technology Platform), and the more common real-world need — building a custom AI agent that reads from and writes to SAP systems via API calls.

If you're evaluating SAP's native stack, the short answer is: SAP AI Core provides the runtime for training and deploying models, the Generative AI Hub gives you a consistent way to call foundation models (including Anthropic, OpenAI, and others) from inside SAP, and Joule is SAP's packaged conversational agent layered on top. If instead you're trying to build your own agent that talks to SAP data — inventory, orders, HR records, whatever your S/4HANA or SuccessFactors instance exposes — you're really solving two separate problems: getting reliable API access to an LLM, and giving that LLM tools that call SAP's OData or REST endpoints. This article covers both, with more weight on the second since that's where most engineering teams actually spend their time.

SAP's native AI agent stack, briefly

SAP AI Core is the managed execution environment for AI workloads inside SAP BTP. It handles model deployment, scaling, and lifecycle for both SAP-trained models and third-party foundation models accessed through the Generative AI Hub. If your organization already runs on BTP and wants agents embedded directly into Fiori apps or CAP-based services, this is the supported path — you get SAP's authentication, logging, and compliance tooling for free, at the cost of being locked into SAP's deployment model and pricing.

Joule sits above that as SAP's branded assistant, with agent-like behavior for specific business processes (approvals, data lookups, guided workflows). It's not a general-purpose API you call from your own product — it's a feature inside SAP's UI layer.

For most teams the friction isn't SAP AI Core itself, it's that building anything custom on top of it means committing to SAP's tooling, contracts, and release cycles. That's why a lot of engineering teams build the agent layer outside SAP entirely, and just call SAP's existing OData/REST APIs as tools from a normal LLM API.

The more common pattern: an external agent calling SAP as a tool

A practical SAP-connected agent usually looks like this:

1. A backend service (Node, Python, whatever you already run) holds the agent logic.
2. That service calls an LLM API with tool definitions that map to SAP's OData services — for example, reading purchase orders, checking stock levels, or updating a customer record.
3. When the model decides it needs data, it emits a tool call; your service executes the actual HTTP request against SAP, and returns the result back to the model.
4. The model uses that result to keep reasoning or to produce a final answer.

This keeps your SAP integration code in your own stack, where you can test and version it normally, instead of inside SAP's AI runtime.

Here's what defining an SAP-backed tool looks like when you're using SubToAPI to call Claude with tool use:

{
  "model": "claude-sonnet-4-5",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_purchase_order",
      "description": "Fetch a purchase order from SAP by PO number",
      "input_schema": {
        "type": "object",
        "properties": {
          "po_number": { "type": "string" }
        },
        "required": ["po_number"]
      }
    }
  ],
  "messages": [
    { "role": "user", "content": "What's the status of PO 4500001234?" }
  ]
}

You send that to SubToAPI's messages endpoint:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d @request.json

When Claude returns a tool_use block asking for get_purchase_order, your backend calls the actual SAP OData endpoint:

async function getPurchaseOrder(poNumber) {
  const res = await fetch(
    `${SAP_BASE_URL}/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrder('${poNumber}')`,
    { headers: { Authorization: `Bearer ${sapToken}` } }
  );
  return res.json();
}

You then send that result back to the model in the next turn, and it composes the final answer. This pattern works the same whether the underlying SAP data is purchase orders, HR leave requests, or inventory levels — the SAP call is just another tool in the loop.

Why keep the LLM call and the SAP call separate

Mixing SAP authentication with LLM API keys inside the same service is where most integrations get messy. A cleaner separation:

• SAP side: OAuth2 client credentials against your SAP BTP destination, scoped narrowly to the OData services the agent actually needs.
• LLM side: a dedicated API key with usage tracking, since agent loops can burn through tokens fast when a task requires several tool calls before it resolves.

If your agent runs on Claude, SubToAPI gives you an application API key (sub_live_...) with per-key usage metadata, so you can see exactly how much a given SAP-connected agent workflow costs before it hits production traffic. That matters more with agentic loops than with single-turn chat, because a poorly scoped tool can cause the model to retry calls repeatedly.

When SAP's native stack makes more sense

If your agent needs to run entirely inside SAP's security boundary — no data leaving BTP, embedded directly in Fiori — the native AI Core / Generative AI Hub path is the right one, even with its constraints. If your agent is one component of a broader product that happens to read SAP data, building it outside SAP with normal API calls is usually faster to iterate on and easier to debug. Most teams end up doing exactly that: SAP stays the system of record, the agent logic and LLM calls live in application code they control.

Start with the quickstart if you're setting up the LLM side of this, and check the tools documentation for the full tool-use request/response format.

questions

Does SAP provide a public API specifically for building AI agents? SAP AI Core and the Generative AI Hub let you deploy and call foundation models within SAP BTP, but they're infrastructure for SAP-hosted workloads, not a general-purpose external agent API. Most custom agents call SAP's existing OData/REST services as tools instead.

Can I connect Claude to SAP data without using SAP's AI Core? Yes. You call an LLM API directly, define tools that map to SAP's OData endpoints, and handle the tool-execution loop in your own backend. This is the more common pattern for teams building product features outside SAP's UI.

Is Joule the same as an AI agent API? No. Joule is SAP's packaged conversational assistant embedded in SAP applications. It isn't a general API you integrate into your own product — for that you'd build a custom agent using an LLM API and SAP's data endpoints as tools.