concur 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-concur-company-access-token

Custody

customer_vault

Injection

header (Authorization)

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.

• concur-identity-users (api, pii): https://us.api.concursolutions.com/profile/identity/v4/Users
• concur-expense-reports (api, financial): https://us.api.concursolutions.com/expensereports/v4/reports

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). Documented exclusions, framed as what this pack does not register: 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. Tiering rationale: the submit capability is declared send at the R3 floor — 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 unsent; send is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The approve capability is declared approve at the R3 floor. Effect-level precision: 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. An irreversible action cannot be taken without a person.

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

• https://developer.concur.com/api-reference/expense/expense-report/v4.reports.html (retrieved 2026-09-21)
• https://developer.concur.com/api-reference/expense/expense-report/v4.workflows.html (retrieved 2026-09-21)
• https://developer.concur.com/api-reference/profile/v4.identity.html (retrieved 2026-09-21)
• https://developer.concur.com/api-reference/authentication/getting-started.html (retrieved 2026-09-21)
• https://developer.concur.com/api-reference/authentication/apidoc.html (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.