Data & schema semantics

x-sap-shortText

`x-sap-shortText` appears in the info block and at the root of the document. Its value is a string. Used by 5 providers across 13 OpenAPI documents. It sits in the `x-sap-` namespace, so its meaning is defined by sap tooling rather than by OpenAPI. Observed values include `Procurement API for purchase orders, invoices, and suppliers`, `Email reporting related API endpoint. It is used to collect reporting informatio`, `Email reporting related API endpoint. It is used to collect delivery results for`, `Process Partner service callbacks for the Emarsys SMS Partner API. Expected call`. Consistent with data & schema semantics — this is inferred from where the key appears and what it carries, not from any published definition.

Data & schema semantics x-sap- namespace derived description
How this description was produced. It is assembled from what was measured in the corpus — where this key appears in a document, what shape its value takes, the values observed, and how many providers use it. It is not taken from a published definition, because for most extensions none exists. Read it as evidence, not as a specification. If you own this extension and want it described properly, tell us.
13 occurrences
13 documents
5 providers
vendor-named

Where it appears

Location in the documentOccurrences
info 8
root 5

What its value looks like

Value shapeOccurrences
string13

Observed values

Sampled from the specifications, most frequent first.

Procurement API for purchase orders, invoices, and suppliersEmail reporting related API endpoint. It is used to collect reporting informatioEmail reporting related API endpoint. It is used to collect delivery results forProcess Partner service callbacks for the Emarsys SMS Partner API. Expected callConfigure, test client setup and sends SMS messages.Enables you to approve or reject SAP Fieldglass work items.Manage sales orders in SAP S/4HANA

Providers publishing it

All 5.

aribaemarsyssap-aribasap-fieldglasssap-s4hana

Why this is not in OpenAPI

Extensions exist because a provider needed something the specification would not carry. Most of what they hold is not the API contract at all — it is operational metadata about the contract: documentation, lifecycle, policy, provenance, and now agents. That metadata is usually better placed alongside the contract, in an Overlay or an APIs.json index, than crammed inside it. See everything else doing the data & schema semantics job.