{
  "schema": "aaes/capability-pack/1",
  "provider": "concur",
  "version": "1.0.0",
  "description": "SAP Concur Expense on the shared regional API host: read users, read expense reports and reports pending approval, submit a report for approval, and approve a report.",
  "notes": "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.\n\nThe 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).\n\nExcluded 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.\n\nApproval 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.\n\nThe approve capability is declared approve at the minimum R3 tier.\n\nOutcome: 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.\n\nOn supported AAES-mediated execution paths, irreversible actions require approval by an authorized person; this does not prevent calls through bypass or observation-only paths.",
  "credential": {
    "secret_ref_id": "secret-ref-concur-company-access-token",
    "custody": "customer_vault",
    "inject": "header",
    "inject_name": "Authorization",
    "note": "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).\n\nThat 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.\n\nThe 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.\n\nExpiry 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.\n\nStopping 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.\n\nLeast 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.\n\nExecutor 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."
  },
  "capabilities": [
    {
      "capability_id": "concur.users.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "pii",
      "egress_allowlist": [
        "us.api.concursolutions.com"
      ],
      "endpoint": "https://us.api.concursolutions.com/profile/identity/v4/Users",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-concur-company-access-token",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "concur-identity-users",
      "description": "Read the Identity v4 users collection: user names, emails, employee numbers and enterprise attributes, which are personal data. SAP Concur documents filter, attributes, startIndex and count parameters (maximum count 100) and states this API supports company level access tokens only.\n\nThe registered path covers the collection read only — single-user reads (GET /profile/identity/v4/Users/{UUID}) are not registered by this pack. Substitute the deployment's geolocation host if it is not the US data center before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "concur.reports.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "financial",
      "egress_allowlist": [
        "us.api.concursolutions.com"
      ],
      "endpoint": "https://us.api.concursolutions.com/expensereports/v4/users/USER_ID/context/CONTEXT_TYPE/reports/REPORT_ID",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-concur-company-access-token",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "concur-expense-reports",
      "description": "Read one expense report header: approval and payment statuses, claimed, approved and due amounts, currencies, policy and business purpose, classified as financial data; the report also identifies its owner, an individual employee. This is a record read on a registered record path, not a collection read. USER_ID, CONTEXT_TYPE (SAP Concur documents TRAVELER, MANAGER, PROCESSOR and PROXY) and REPORT_ID are placeholders the deployment binds to concrete values before enabling.\n\nExpense entries, itemizations and receipt images are not registered by this pack. Substitute the deployment's geolocation host if it is not the US data center before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "concur.reports.toapprove.read",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R0",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "financial",
      "egress_allowlist": [
        "us.api.concursolutions.com"
      ],
      "endpoint": "https://us.api.concursolutions.com/expensereports/v4/users/USER_ID/context/MANAGER/reportsToApprove",
      "method": "GET",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-concur-company-access-token",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "read"
      ],
      "resource_id": "concur-expense-reports",
      "description": "Read the collection of expense reports a manager (or their delegate, when includeDelegateApprovals is set) can approve: report names, numbers, submit dates, employee and approver identities, and claimed, approved and due amounts, classified as financial data. SAP Concur documents the contextType MANAGER for this endpoint.\n\nThe registered path covers the collection read only. USER_ID is a placeholder the deployment binds to a concrete approver before enabling.\n\nSubstitute the deployment's geolocation host if it is not the US data center before enabling.",
      "requires_review": true
    },
    {
      "capability_id": "concur.reports.submit",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "financial",
      "egress_allowlist": [
        "us.api.concursolutions.com"
      ],
      "endpoint": "https://us.api.concursolutions.com/expensereports/v4/users/USER_ID/reports/REPORT_ID/submit",
      "method": "PATCH",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-concur-company-access-token",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "send"
      ],
      "resource_id": "concur-expense-reports",
      "description": "Submit an expense report for approval. A successful request returns 204 No Content and changes the report from un-submitted to submitted. It records no approval and creates no payment object itself.\n\nWorkflow effect: the report enters the customer’s configured approval workflow. After approval, extraction and reimbursement may follow, including Expense Pay where configured. A 204 response does not rule out later automatic approval or payment scheduling. Recall is a separate operation available only while the report can be recalled.\n\nClassification: send, minimum R3, because the report is transmitted into a workflow where approvers act on it.\n\nOn supported AAES-mediated execution paths, an authorized person must approve the action. This cannot stop observation-only or bypass calls.\n\nSetup: bind USER_ID and REPORT_ID before enabling. Substitute the deployment’s geolocation host if it is outside the US data center.",
      "requires_review": true
    },
    {
      "capability_id": "concur.reports.approve",
      "version": "1.0.0",
      "kind": "tool",
      "risk_tier": "R3",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN",
      "data_class": "financial",
      "egress_allowlist": [
        "us.api.concursolutions.com"
      ],
      "endpoint": "https://us.api.concursolutions.com/expensereports/v4/reports/REPORT_ID/approve",
      "method": "PATCH",
      "connector": "http",
      "custody": "customer_vault",
      "secret_ref_id": "secret-ref-concur-company-access-token",
      "inject": "header",
      "inject_name": "Authorization",
      "actions": [
        "approve"
      ],
      "resource_id": "concur-expense-reports",
      "description": "Approve an expense report and advance it to the next workflow step. This registered short-URL form requires a company-level access token and returns 204 No Content on success. It records an approval judgement; it does not itself create a payment object.\n\nRequest limits: the body may include a comment, expectedStepCode/expectedStepSequence, and optional statusId, defaulting to A_APPR. SAP Concur does not publish all permitted statusId values or their effects. The registration does not constrain the body: review which workflow statuses the customer’s configuration accepts and which the integration may assign.\n\nProvider permission: expense.report.workflowstatus.write covers both Approve and Send Back. The token therefore has provider-side authority for Send Back even though this pack excludes it. Send Back and Recall are excluded sibling operations.\n\nDownstream effect: configured extraction and reimbursement, including Expense Pay, may follow the approval. A 204 response does not rule out automatic payment scheduling.\n\nClassification: approve, minimum R3.\n\nOn supported AAES-mediated execution paths, an authorized person must approve the action. This cannot stop observation-only or bypass calls. Bind REPORT_ID and substitute the deployment’s geolocation host if outside the US data center before enabling.",
      "requires_review": true
    }
  ],
  "resources": [
    {
      "resource_id": "concur-identity-users",
      "kind": "api",
      "locator": "https://us.api.concursolutions.com/profile/identity/v4/Users",
      "data_class": "pii",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    },
    {
      "resource_id": "concur-expense-reports",
      "kind": "api",
      "locator": "https://us.api.concursolutions.com/expensereports/v4/reports",
      "data_class": "financial",
      "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN"
    }
  ],
  "review": {
    "state": "library",
    "date": "2026-09-22",
    "sources": [
      "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)"
    ],
    "reviewer_id": "aaes-eng"
  }
}
