SAP Concur package v1.0.0

A company-level OAuth 2.0 access token for the customer's SAP Concur 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. Client ID and secret alone do not produce the company-level token these operations require: SAP Concur documents that for Enterprise Business Applications only the password grant obtains company-level tokens, and the bootstrap is an App Center connection — an SAP Concur administrator clicks Connect for the application in the App Center, SAP Concur redirects with the Company UUID and a 24-hour request token, and the external process exchanges them at the token endpoint POST {geolocation}/oauth2/v0/token using the password grant (username = Company UUID, password = request token) with the application client_id and client_secret issued at application registration (via Partner Enablement or the Account Manager).

That exchange returns an access token and a refresh token, and the external process renews with the refresh grant, which returns a new access-and-refresh pair. SAP Concur also documents a client-credentials grant, but it yields an application-level token with no refresh token — not the company-level token the registered operations take — and the documented error 53 ('company is not enabled for this client') is the failure when the App Center connection has not been completed.

The client secret stays with that external process. 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 Concur documents a default one-hour access token lifetime and a default six-month refresh token lifetime; the external process must refresh on that cadence. SAP Concur documents revocation through DELETE /app-mgmt/v0/connections, which revokes the refresh tokens associated with a user for an application: that stops renewal, so the in-flight access token dies within its one-hour lifetime. Rescoping the application's grants changes what subsequently issued tokens carry.

Stopping renewal and changing scopes are different events from invalidating an already-issued access token, which SAP Concur does not document as immediately invalidated; an expired value fails closed. Note the submit endpoint supports user-level as well as company-level tokens: the stored token must be a company-level token whose scopes cover every registered capability.

Least privilege: request only the scopes the registered capabilities need — expense.report.read for the report reads, expense.report.readwrite for submit, expense.report.workflowstatus.write for approve, and the identity read scopes (identity.user.ids.read, identity.user.core.read) for the users read — and nothing more; the same application must not hold delete or provisioning write scopes this pack deliberately does not register.

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.

SAP Concur serves its APIs from shared regional hosts: the registered endpoints use us.api.concursolutions.com, the US data center host SAP Concur's own examples use. SAP Concur issues each application a geolocation, and the access token's base URI must match it — a deployment whose geolocation is another data center (the documentation names emea.api.concursolutions.com, and the Identity v4 page shows us2/emea2 forms) must substitute that host in every endpoint, in every resource locator and in every egress allowlist entry before enabling.

The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step when the customer's geolocation differs — allowlisting the US host does not make a token for another region safe to aim there. This pack registers only endpoints the SAP Concur developer portal documents: the Identity v4 users collection read (GET /profile/identity/v4/Users), the Reports v4 report read (GET /expensereports/v4/users/{userID}/context/{contextType}/reports/{reportId}) and reports-to-approve collection read (GET /expensereports/v4/users/{userId}/context/MANAGER/reportsToApprove), and the Workflows v4 submit (PATCH /expensereports/v4/users/{userId}/reports/{reportId}/submit) and approve (PATCH /expensereports/v4/reports/{reportId}/approve, the company-token short URL).

Excluded operations: report creation (POST) and report header updates (PATCH on the report resource, including the submitted-report variant), sendBack and recall, cost objects for approver, expense entries and receipt images, every Identity v4 write (user POST, PUT, PATCH and the hard-delete SAP Concur itself marks not recommended), and every Travel, Invoice and Request API.

Approval classification: the submit capability is declared send at the minimum R3 tier — submitting moves the report into the approval workflow where approvers act on it, and SAP Concur documents recall as a separate operation available only while the report can be recalled, so the submission is treated as a message that cannot be recalled after delivery; send is one of the designated actions requiring human approval.

The approve capability is declared approve at the minimum R3 tier.

Outcome: submit is request-accepted (the report transitions to submitted; the call itself records no approval and creates no payment object); approve is approval-recorded (SAP Concur documents that it advances the report to the next workflow step and defaults the status to A_APPR, without publishing the permitted statusId values — see the capability description). Neither call itself moves money, but downstream of both transitions the customer's configured workflow can extract and reimburse the report, including through Expense Pay where configured: the 204 responses and this pack's non-registration of payment endpoints do not prove no payment scheduling can follow automatically under the customer's own configuration.

On supported execution paths mediated by AAES Govern, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths.