Oracle package v1.0.0

Credentials of an integration user on the customer's own Oracle Fusion pod, held in the client's own secret manager. Oracle's documented examples authenticate with HTTP Basic (curl -u username:password), and the stored material must be the complete Authorization header value (scheme included): 'Basic', one separating space, then the base64 of 'user:password' — 'Basic <base64>'.

An external deployment process provisions the integration user, rotates the password and stores the renewed header value; the executor injects the stored value verbatim and performs no credential 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.

Passwords expire under the pod's password policy and the user can be locked or have its roles removed at any time, which revokes access; an expired or revoked value fails closed.

Least privilege: grant the integration user only the duty roles that make the registered capabilities work (supplier and purchase order inquiry, payables invoice inquiry and invoice entry) and nothing more — the same user must not be authorized for invoice cancellation, invoice deletion or any payments function this pack deliberately does not register.

Where the deployment prefers OAuth 2.0 against the pod's identity domain, the complete stored value becomes 'Bearer <token>' and token obtain/renew ownership sits with the external process: OAuth access tokens carry their own expiry (the token response's expires_in) and the external process must obtain a replacement before expiry and store the new complete header value; revoking the identity-domain OAuth client, disabling the user or removing its roles stops future token issuance but does not invalidate an already-issued token, which remains usable until it expires.

Review rotation and role assignments before enabling.

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 'oracle-fusion.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Oracle Fusion pod host (the documented examples use the form servername.fa.us2.oraclecloud.com) 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.

The path version segment 11.13.18.05 is the version Oracle's REST references document for these resources; Oracle also accepts 'latest' in the version position, but this pack pins the documented version so the registration names what was reviewed. This pack registers only endpoints Oracle's REST API for Oracle Fusion Cloud Financials and REST API for Oracle Fusion Cloud Procurement document: the Suppliers List of Values collection read (suppliersLOV), the payables invoices collection read and invoice create, and the purchase orders collection read.

The supplier read registers the suppliersLOV list-of-values resource because that is the collection read Oracle's procurement reference documents in full; the Suppliers management resource with its create, update and child resources is deliberately not registered. All reads are collection reads only: single-record reads (GET /invoices/{invoicesUniqID}, GET /purchaseOrders/{purchaseOrdersUniqID}, GET /suppliersLOV/{SupplierId}) exist in the APIs and are deliberately not registered.

Documented exclusions, framed as what this pack does not register: invoice update (PATCH), invoice delete (DELETE /invoices/{invoicesUniqID}), invoice cancel (POST /invoices/action/cancelInvoice), prepayment apply/unapply and distribution generate/reverse actions, every child resource (invoiceLines, invoiceInstallments, attachments, descriptive flexfields), draft purchase orders and their actions, and every payments, payees and disbursement resource — nothing in this pack pays anyone, and a created invoice is a payables document subject to the pod's own validation and approval workflows, not a payment.

Oracle enforces the calling user's function and data security, so a capability works only if the integration user's roles permit the operation; the registration records the endpoint, not the pod's authorization decision.