generated: '2026-08-29' method: searched source: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/c61ddbd093c1498aae76e42ffaf37e21.html docs: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/99ef1f190ff647df8cffd681264c24d0.html provider: Ariba providerId: ariba description: >- Authentication profile for the SAP Ariba API gateway, read from SAP's own developer-portal help set. There is no OpenAPI to derive securitySchemes from - SAP does not publish a machine-readable contract for these APIs anonymously - so every scheme below is transcribed from a cited documentation page rather than from a spec. summary: >- Two credentials are required on every call, not one: an application key (apiKey header) that identifies the registered client application, AND an OAuth 2.0 bearer access token obtained with the client-credentials (two-legged) grant. Access tokens are short-lived - 1,440 seconds (24 minutes). A separate set of older SAP Business Network APIs use HTTP Basic with an ANID and shared secret. Mutual-TLS client certificates are supported for applications that require them. schemes: - id: application_key type: apiKey in: header name: apiKey required: true description: >- The application key issued when the client application is registered and approved on the SAP Ariba Developer Portal. Sent on every request alongside the bearer token. The gateway validates that the apiKey in the header matches the apiKey bound to the OAuth token - a mismatch is a documented 401. docs: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/eb84c80e00324dbe972cd3078bab0e32.html - id: oauth2_client_credentials type: oauth2 flow: clientCredentials required: true description: >- SAP's help text: "The APIs on the SAP Ariba Developer Portal are protected by the API Gateway and OAuth authentication... We further support the two-legged OAuth protocol or Client Credentials authorization flow." The OAuth client ID is generated when the application is approved for production; the client secret is generated by the developer and used Base64-encoded as Basic on the token request. token_endpoint: '{oauth_server_url_prefix}/v2/oauth/token' token_endpoint_note: >- SAP documents the path but not the host: the oauth_server_url_prefix is data-centre specific and is shown on the API's discovery page on the developer portal, which requires a login. Recorded as a template rather than guessed. token_lifetime_seconds: 1440 token_lifetime_note: >- "OAuth tokens are short-lived and expire 24 minutes (1440 seconds) after they are issued. Tokens must be refreshed." A refresh token is issued with the original access token and is exchanged at the same /v2/oauth/token endpoint. docs: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/51a7e3fc0cd44df48cb48f4fd23896a9.html - id: basic_anid type: http scheme: basic required: false applies_to: >- A subset of SAP Business Network APIs (for example the Contract Compliance API and the Flow Extension API error tables reference it). description: >- HTTP Basic using the SAP Business Network ID (ANID) and a shared secret. SAP's error tables read "Confirm your ANID and shared secret and make sure you are using basic authentication." A related header, X-ARIBA-NETWORK-ID, carries the ANID on some Business Network endpoints. docs: https://help.sap.com/docs/ARIBA_APIS/3ef7b70c268149288e4d59f43a94b68b/4311b0869b6845c2a405e20309bae853.html - id: mutual_tls type: mutualTLS required: false description: >- SAP publishes a "Managing Security Certificates for Mutual Authentication" procedure in the developer-portal authentication help set, so client-certificate mutual authentication is an available option for registered applications. docs: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/c61ddbd093c1498aae76e42ffaf37e21.html request_shape: example: >- curl -X GET 'https://openapi.ariba.com/api/approval/{version}/{environment}/...?realm=myRealm&limit=5&offset=0&needTotal=false' -H 'accept: application/json' -H 'apiKey: ' -H 'Authorization: Bearer ' source: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/583fd26833af47f4b38cfe7d5443f243.html required_query_parameter: name: realm description: >- Nearly every SAP Ariba API requires a realm (site name) query parameter identifying the customer tenant. It is part of authorization, not just routing - SAP documents a 401 reading "This client id: {ID} is not authorized to access the realm: {realm} for this API". scopes: published: false note: >- SAP's error catalogue proves OAuth scopes exist - "The token scopes are not supported by the API - Your client application is not authorized to use the API endpoints associated with this scope" (401) - but SAP does not publish a scope reference anonymously. Scopes are bound to an application when an administrator approves its API-access request on the developer portal. No scopes/ artifact is written rather than an empty one; see the Conventions artifact. evidence: https://help.sap.com/docs/ARIBA_APIS/c1aedced5c044a41b84be5312db93fc1/0607784ed86d45eeb137aab8470c096e.html onboarding: gate: >- "Only applications approved by the SAP Ariba APIs administration can execute OAuth authentication." Registration on the developer portal creates an application; an Organization admin then requests API access, and production credentials are issued only after approval. This is a human approval gate on the credential path, not a self-serve key. docs: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/5124973951a54a05a6cfaab3243e9a47.html credential_handling_guidance: source: https://help.sap.com/docs/ARIBA_APIS/b61dd8c7e22c4fe489f191f66b4c48d6/88e991ccca584d93ba4d4d2951e409fa.html note: >- SAP publishes an explicit credential-storage page telling integrators not to store the OAuth client secret or the Base64-encoded client-and-secret in a database, and warning that regulatory compliance may require stronger key storage. maintainers: - FN: Kin Lane email: kin@apievangelist.com url: https://apievangelist.com