Coupa package v1.0.0

An OAuth 2.0 access token for the customer's own Coupa instance, 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>'. The token is obtained with the client credentials grant: an integrations-enabled administrator creates an OAuth2/OIDC client (Setup > Oauth2/OpenID Connect Clients) with grant type Client credentials, and an external deployment process POSTs client_id, client_secret, grant_type=client_credentials and the selected scopes to https://<instance>/oauth2/token and stores the returned access token; the client secret is itself secret material and 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: Coupa documents the access token as lasting 24 hours (expires_in 86399 seconds) and recommends renewing it every 20 hours; if the token lapses the external process must make a new token call — the executor must not attempt renewal itself. The OAuth client can be deactivated, deleted or rescoped by an administrator at any time (Coupa documents activate/deactivate per client on the OpenID Connect Clients page), which stops future token issuance for that client and changes what subsequently issued tokens may do; disabling issuance and changing scopes are different events from invalidating an already-issued token, and Coupa's documentation does not describe client deactivation, deletion or rescoping as invalidating a 24-hour access token already issued before its natural expiry.

An expired value fails closed.

Least privilege: Coupa scopes take the documented form service.object.right (for example core.accounting.read), and the authoritative list of scopes and their underlying permissions is the Scope management page on the customer's own instance (/oauth2/scopes) — verify membership there before enabling, because published third-party enumerations may lag Coupa's own list. Grant the client only the read scopes for suppliers, invoices, purchase orders, requisitions and approvals, plus the approval write scope for the approve capability, and nothing more.

Residual-authority disclosure: third-party integration documentation that enumerates the Coupa scopes (Rossum's Coupa OAuth scopes documentation, retrieved 2026-09-21; the ServiceNow Coupa integration-profile reference yielded only a JavaScript shell, so it did not corroborate that scope mapping) shows the approval write scope core.approval.write covering the Approve, Create, Hold, Reject and Update approval operations together — approve, reject and hold share one write scope — so a client holding the approval write scope necessarily holds provider-side permission for the reject, hold, create and update approval actions this pack deliberately does not register.

That residual authority is a provider permission on the client, distinct from what AAES registers (only PUT /api/approvals/{id}/approve is registered); AAES non-registration does not reduce the client's Coupa-side grant.

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.

The endpoint host 'coupa-instance.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Coupa instance host, whose documented form is {customer_name}.coupahost.com ({organization_name}.coupacloud.com for partner and demo instances), 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 the Coupa Compass documentation for the Coupa core API documents: the index (collection) reads on /api/suppliers, /api/invoices, /api/purchase_orders, /api/requisitions and /api/approvals, and the documented approval action PUT /api/approvals/{id}/approve. All reads are collection reads only: single-record show reads (GET /api/suppliers/{id} and the equivalent for the other resources) exist in the API and are deliberately not registered.

Excluded operations: every create, update and delete on suppliers, invoices, purchase orders and requisitions; requisition submission (POST /api/requisitions/submit_for_approval and PUT /api/requisitions/{id}/update_and_submit_for_approval); the approval reject and hold actions (PUT /api/approvals/{id}/reject, PUT /api/approvals/{id}/hold); approval update (PUT /api/approvals/{id}); purchase order transmission and Coupa Pay functions; and every other Coupa API. The approve capability is registered as approve at the minimum R3 tier — approve is one of the designated actions requiring human approval.

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. Effect-level precision for the approve call: Coupa documents it as performing the approve action on an approval that must be pending, and a successful call records the approver's judgement and advances the document's approval chain.

The call itself moves no money, but completing a document's approval chain can trigger the customer's configured downstream procurement and payment workflows (an approved requisition can become purchase orders; an approved invoice can become payable and be paid, including through Coupa Pay where configured): HTTP 200 confirms the approval was recorded, and this pack not registering payment endpoints does not prove those configured workflows cannot schedule payment.

Coupa's older X-COUPA-API-KEY scheme is documented in older Compass pages alongside the OAuth transition guide; this pack registers only the current OAuth 2.0 client-credentials scheme, whose documented injection point is the Authorization header.