ariba v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-ariba-oauth2-access-token

Custody

customer_vault

Injection

header (Authorization)

An OAuth access token for the customer's SAP Ariba developer portal application, held in the client's own secret manager. The stored material must be the complete Authorization header value (scheme included): 'Bearer', one separating space, then the access token — 'Bearer <token>'. An external deployment process obtains and renews the token using the OAuth client ID and client secret issued when the application is created on the SAP Ariba developer portal (the authentication-instruction pages sit behind the portal's registration gate; developer.ariba.com/api renders only that gate to an unauthenticated reader, so this pack cites it for the gating fact, not for the auth instructions); the client secret stays with that external process. Access is per application per API, and the two API families are enabled differently. For the Supplier Data API with Pagination (SAP Ariba Supplier Management), SAP's guide documents that the application requests API access in the developer portal, that the SAP Ariba APIs administration approves the application for OAuth, that SAP Customer Support must enable API access for the site, and that each call carries the realm query parameter. For the two SAP Business Network APIs (Purchase Orders, Invoice Header Data Extraction), the guides document that the application's client ID must be linked to the buyer's or supplier's ANID through API Client ID Configuration in SAP Business Network — and, for suppliers, the Invoice guide documents supplier portal access as restricted to Enterprise accounts. One token can legitimately cover all three capabilities only if ONE developer-portal application has been granted access to each of the three APIs AND its client ID is linked to the ANID: that is a deployment configuration fact to verify in the customer's own portal, not an assumption this pack makes. The executor injects the stored value verbatim and performs no token lifecycle itself. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Expiry and revocation: SAP's Supplier Data API with Pagination guide documents that OAuth tokens are short-lived and expire 24 minutes (1440 seconds) after issue and must be refreshed — the external process owns that refresh cadence. The application's API access can be withdrawn in the developer portal, and API Client ID Configuration in SAP Business Network can remove the linked client ID at any time: those steps disable future issuance and future linkage; disabling issuance and removing linkage are different events from invalidating an already-issued token, and the guides do not document either step as invalidating a token already issued before its 24-minute expiry. An expired value fails closed. Least privilege: request API access only for the three APIs this pack registers (Supplier Data API with Pagination, Ariba Network Purchase Orders API, Ariba Network Invoice Header Data Extraction API) and no approval, update or sourcing API — SAP documents that each API invocation retrieves data for a single site, and that API access must be enabled for the site by Customer Support. The further headers the APIs require (apikey on all three, X-ARIBA-NETWORK-ID on the two Business Network APIs) are outside this pack's single injection point; see the pack notes for the wiring reality, including the custody bar for the secret apikey. Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• ariba-suppliers (api, pii): https://ariba-runtime.invalid/supplierdatapagination/v4/prod/vendorDataRequests
• ariba-purchaseorders (api, financial): https://ariba-runtime.invalid/orders
• ariba-invoices (api, financial): https://ariba-runtime.invalid/invoices

The endpoint host 'ariba-runtime.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD), and it stands for the ENTIRE per-API runtime base URL — host plus any API, version and environment path prefix — not a bare hostname whose authority alone gets replaced. SAP's own guides write every sample URL as {{runtime_url}} and instruct the reader to take the runtime URL from the Environment Details table on the SAP Ariba developer portal discovery page for each API; that discovery page requires a developer portal account (developer.ariba.com/api renders only its registration and terms-of-use gate to an unauthenticated reader), so this review could not verify the public runtime host, and the pack registers fewer capabilities as a result. Path-shape precision, per API: the Supplier Data API with Pagination guide spells out its full path as {{runtime_url}}/supplierdatapagination/v4/prod/vendorDataRequests, so the /supplierdatapagination/v4/prod prefix after the runtime base is guide-verified; the Ariba Network Purchase Orders API guide shows GET {{runtime_url}}/orders and the Invoice Header Data Extraction API guide shows GET {{runtime_url}}/invoices — operation suffixes only, with any API/version/environment prefix carried inside the portal-provided runtime URL itself (third-party integration documentation shows a default Open API base of https://openapi.ariba.com/api, which itself carries an /api path prefix, corroborating that the runtime base is base-URL-plus-prefix, not a bare host). Whether the runtime URL for the two Business Network APIs contains such a prefix is a portal registration fact this review could not verify, and the pack does not guess it. Substitute the complete runtime URL for the customer's realm and data center for EACH of the three APIs — the three may differ — before enabling, in every endpoint, in every resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. This pack registers only endpoints SAP's public help.sap.com guides document: the Supplier Data API with Pagination vendorDataRequests endpoint (POST /supplierdatapagination/v4/prod/vendorDataRequests — SAP documents retrieval using the POST method with filters and output format in the request body, so the HTTP method is POST while the effect is a read), the Ariba Network Purchase Orders API GET /orders (order header data), and the Ariba Network Invoice Header Data Extraction API GET /invoices (invoice header data). All reads are collection reads only. Documented exclusions, framed as what this pack does not register: the Document Approval API's state-changing endpoint PATCH /{approvableType}/{approvableId} (SAP documents it approving or denying requisitions and invoices — an approval is the IRREVERSIBLE ACTION approve and this pack deliberately registers no approval capability), every other Document Approval API endpoint, the Supplier Data API with Pagination update endpoints (answers, vendors status updates, questionnaire updates), the purchase order item detail endpoint GET /items, the External Approval API for Sourcing and Supplier Management, and every sourcing, contract and invoicing write API. Header wiring reality, stated honestly: the two SAP Business Network API guides (Purchase Orders, Invoice Header Data Extraction) each document three required headers — Authorization (Bearer token), apikey (the application key generated in the developer portal) and X-ARIBA-NETWORK-ID (the SAP Business Network ANID); the Supplier Data API with Pagination guide documents the OAuth client credentials and application key issued at application registration and the realm query parameter on each call (its full request-header table did not render in this review, so its exact header set is taken from the portal at enablement, not guessed here). This pack format declares one injection point, which covers the Authorization header only; the apikey (and X-ARIBA-NETWORK-ID where required) must be attached by the deployment outside the pack's credential wiring. The apikey is secret application material from the developer portal and needs the same custody bar as the token: resolved from the deployment's own secret manager, injected into the apikey header by the trusted executor, held in memory only for the lifetime of a call, and kept out of logs, traces, diagnostics and crash dumps — not executor code or config that ships to a repository.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://help.sap.com/doc/63527aca54584ec19ae53a5b28d4b8f1/cloud/en-US/6e56c0b1fd1c49eb8e87befeae6c4ff2.pdf (retrieved 2026-09-21)
• https://help.sap.com/doc/b82f21c697404b65a64689cb947ec42f/cloud/en-US/25d6aca0a7ca49ee80db56b47ae976f7.pdf (retrieved 2026-09-21)
• https://help.sap.com/doc/e8fe19f0f06043e289ceffa47e2b8592/cloud/en-US/e8fe19f0f06043e289ceffa47e2b8592.pdf (retrieved 2026-09-21)
• https://developer.ariba.com/api/ (retrieved 2026-09-21)
• https://docs.nexla.com/user-guides/connectors/sap_ariba_api/sap_ariba_api_auth (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.