How to Connect Oracle Fusion Cloud Financials to Apideck

This guide is for the Oracle Fusion administrator at the customer who needs to prepare an Oracle Fusion Cloud Financials environment and connect it to Apideck for the Accounting API.

The connector serves seven resources: journal entries (create, read, and delete while unposted), Receivables invoices (create and read), and read-only ledger accounts, tracking categories, invoice items, company info and subsidiaries.

Each step lists the exact value or choice to enter. Follow the steps that apply to the resources you intend to use — journal entries and invoices need different Oracle roles and different data access, and skipping the parts for a resource you do use is the most common reason a connection validates but returns nothing.

Application owners (teams building on Apideck): the capability matrix, the settings inventory and the full API behaviour contract live in the Configuration Guide. This document is the Oracle-side setup, and it is the one to hand to the administrator doing it.

Which path applies to you?

Your situation	What to do
You already run Oracle Fusion GL (you have at least one ledger with open periods and post journals today) — the common case	Do Steps 1–8 below. You do not need to build any accounting structures.
Your environment has no General Ledger yet (a bare/greenfield instance or a fresh test pod)	Do Steps 1–2 first (the greenfield build needs the integration user to exist), then build a minimal GL with the companion Greenfield GL setup guide, then return here and do Steps 4–8 (Section D of that guide already completes Step 3's General Ledger data-access grant; if you will use `invoices`, still add the Business Unit row from Step 3.3).
You want the `invoices` / `invoice-items` resources	Do everything below, plus the companion Receivables setup guide. Receivables needs its own role, its own data access and its own configuration — none of it comes with General Ledger.

Prerequisites

Before you begin, make sure you have:

The Fusion Applications URL of the instance you want to connect (e.g. https://abcd1234.fa.us2.oraclecloud.com).
Security Console access (or an Oracle administrator who can create users and assign roles for you).
Access to the OCI IAM / Identity Cloud Service (IDCS) console for the tenant — required: this connector authenticates with OAuth 2.0 client-credentials tokens issued by the identity domain (Step 5).
An Apideck account with a Vault connection for the oracle-fusion service.

Step 1 — Create a dedicated integration user

Create a dedicated Fusion Applications user for the integration rather than reusing a person's account. This keeps the integration's activity auditable and independent of any employee's password rotation or MFA.

In Fusion, open Navigator → Tools → Security Console → Users.
Click Add User Account and complete the form:
- User Name — the login name Oracle authorizes API calls under. It must be exactly the OAuth Client ID of the confidential application from Step 5: Oracle maps a client-credentials token to the Fusion user named after the Client ID. Register the application first (Step 5.1–5.2) to get the Client ID, then create the user with that name. Record it.
- Password — never sent by Apideck. The connection holds no Fusion password; it authenticates with the client secret. Nothing in this guide uses it either — do not use it for the curl checks in Step 5, which run with a separate account. Set a strong password and store it securely, or disable password sign-in for the user if your policy allows.
- Associate it with a person/party record if your policy requires one.
Save.

Two traps on this form, both worth knowing before you hit Save:

Under Oracle's DEFAULT user category, the User Name is auto-generated from the Email field and will silently overwrite what you typed. Enter the Email first, then overwrite the User Name, then save without touching Email again.

Saving can fail with a PasswordManagementException and still create the user — without its roles. Search for the user before retrying: a blind retry reports the name as already taken. If it exists, re-open it and add the missing roles.

Do not use an OCI/IDCS tenant-administrator email login (for example admin@yourco.com) for the optional curl checks in Step 5 either. Those accounts are subject to interactive MFA sign-on and often live in a different identity domain, so HTTP Basic Auth against them returns 401. Run those checks with a separate plain Fusion Applications User Name account — never the integration user.

Step 2 — Assign the required roles

In Security Console → Users, open the user you just created and click Edit → Add Role.
Add General Accounting Manager (ORA_GL_GENERAL_ACCOUNTING_MANAGER_JOB) for the journal-entry and ledger resources.
Check the user can reach the REST API at all. Every call returns 403 without the Access FSCM Integration Rest Service privilege (FUN_FSCM_REST_SERVICE_ACCESS_INTEGRATION_PRIV), however many accounting roles the user holds. General Accounting Manager already carries it, under its FSCM Load Interface Administration duty, so a user with the role from Step 2.2 normally needs nothing extra here. You only need to act if you are building a least-privilege custom role instead (see the alternative at the end of this step), or if your tenant has customised the seeded role: then add the privilege to your custom role through Security Console → Roles → your role → Function Security Policies.
To use the invoices and invoice-items resources, also add Accounts Receivable Manager (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB), and follow the Receivables setup guide. On the verification pod used to build this connector, the invoice list stayed empty for the integration user until it also held Application Implementation Consultant (ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB) — see that guide's Section I.
Save, then run both of these scheduled processes, in this order (Navigator → Tools → Scheduled Processes), waiting for each to reach Succeeded before starting the next: Send Pending LDAP Requests, then Import User and Role Application Security Data.

⚠️ A role change is not live for a REST caller until Send Pending LDAP Requests has completed. Oracle documents it as the process that manages role provisioning, and documents Import User and Role Application Security Data as the step after it — run both, in that order. In live verification against a verification pod, a role added to or removed from the integration user took effect on REST reads within a minute of Send Pending LDAP Requests finishing. Re-run both after every subsequent role or data-access change, including Step 3.

Two things to expect afterwards: the change is normally live for REST calls within a few minutes of Send Pending LDAP Requests completing, but Oracle gives no signal, so verify with an API read rather than with the Security Console (Users with Data Access can show a grant that is not yet live). If a read still shows the old permissions well after both processes reached Succeeded, re-run both again in order and, if the grant still isn't live, raise it with Oracle Support rather than continuing to wait. Separately, and unrelated to grants: if creating a journal entry returns 503 while every read succeeds and nothing was changed, Oracle's scheduler is refusing the connection's client-credentials token at the moment — retry later.

To use the ledger-accounts and tracking-categories resources: both read Oracle's enterprise-structures data (account combinations and value sets), which returns 403 for a pure accounting role. Grant the integration user the Get Enterprise Structures Using REST Service privilege (FUN_GET_ENTERPRISE_STRUCTURES_REST_SERVICE_PRIV):

Security Console → Roles → Create Role, of type Duty or Job.

On the Function Security Policies step, search for Get Enterprise Structures Using REST Service and add it.

Assign the new role to the integration user and re-run both scheduled processes from Step 2.5 — Send Pending LDAP Requests first, then Import User and Role Application Security Data. The second one is the one that materialises this grant.

⚠️ Search for it by that exact name. Oracle's documentation page is titled "Get Enterprise Structures Using REST API", but Security Console lists the privilege as "...REST Service". Searching for the doc-page wording, or for the privilege code, returns nothing — which reads as "this privilege does not exist here", and is the single reason this route is usually abandoned. Oracle also calls it an orphan privilege, meaning it belongs to no seeded role — not that it cannot be assigned.

Journal-entry read and write do NOT require this — each journal line carries its own account combination — so both resources are optional for a journal-only integration.

If the privilege route is blocked in your tenant, the Enterprise Structures Administration duty (ORA_FUN_ENTERPRISE_STRUCTURES_ADMINISTRATION_DUTY, added on a custom role's Role Hierarchy step) is sometimes suggested instead. Treat it as unverified: adding that duty alone was observed not to clear the 403, and it is a setup-level duty carrying broad authority over chart-of-accounts structures, ledgers and legal entities — review it with your security team before granting it, and prefer the single privilege above.

Least-privilege alternative: if your security policy forbids the broad manager role, work with your Oracle security team to grant a custom role carrying at minimum: read access to Journals, Ledgers and Account Combinations; the Access FSCM Integration Rest Service privilege (FUN_FSCM_REST_SERVICE_ACCESS_INTEGRATION_PRIV); and the privilege to submit the journal-import process. Validate it against Steps 6–8 before relying on it.

Step 3 — Grant the integration user data access

A role alone does not grant access to a specific ledger's or business unit's data — data access grants do. This is the single most common cause of "connection works but returns nothing".

The Ledger and Data Access Set dropdowns in Step 6 are populated by live reads made as the integration user, so they stay empty until this step is done.

Open the task Manage Data Access for Users (Setup and Maintenance, or Navigator → My Enterprise → Setup and Maintenance → Search → Manage Data Access for Users).
Click Create (＋) and add the General Ledger row:
- User Name — the integration user the connector authenticates as (the Step 1 user, named after the Client ID). Data access granted to any other user has no effect on the connection.
- Role — General Accounting Manager (the role you assigned in Step 2). If the Role list comes up empty, or the role is missing from it, the assignment has not propagated yet: run Retrieve Latest LDAP Changes once, then re-open this task. It is a different process from the two in Step 2.5 and is what refreshes this list of values.
- Security Context — Data Access Set.
- Security Context Value — the Data Access Set that grants Read and Write access to the ledger you want to integrate. (Each ledger has an auto-created Data Access Set named after the ledger; Oracle documents it as full-ledger access — confirm with your administrator that it grants Read and Write.)
If you will use the invoices or invoice-items resources, add a second row:
- User Name — the same integration user.
- Role — Accounts Receivable Manager (the Receivables role from Step 2.4), not the General Ledger role used in the row above. Receivables data access is granted per Receivables role.
- Security Context — Business Unit.
- Security Context Value — the business unit you will enter in the invoices settings (Step 7).
Receivables visibility is secured by business unit, entirely separately from the General Ledger Data Access Set. Without this row, invoice lists come back empty even though every General Ledger resource works.

The Receivables setup guide's Section I covers this same row in full, including a role the grant needed on the environment this connector was verified against (Step 2.4). If invoice reads come back empty after this step, read that section before changing anything here.
Save, then re-run both scheduled processes from Step 2.5 — Send Pending LDAP Requests first, then Import User and Role Application Security Data.

⏱️ Grants are applied asynchronously, so empty dropdowns or empty lists in the first minutes after granting are expected — allow a few minutes after both processes have succeeded. Beyond that, more time will not change the outcome: re-check the grant itself and that both processes ran to Succeeded, and escalate to Oracle Support if it is still not visible after that.

⚠️ Read-Write is required for journal creation. A Read-Only Data Access Set will not be caught at connection time — validation only performs a read — and is expected to surface later as a journal-import security failure. Confirm the Read-Write grant with your Oracle administrator; there is no way to verify it from the connection itself.

Step 4 — Find your Host and Data Center

Every request the connector makes goes to:

https://{host}.fa.{datacenter}.oraclecloud.com/fscmRestApi/resources/11.13.18.05

Both values come from your Fusion Applications instance URL. For https://abcd1234.fa.us2.oraclecloud.com:

Host = abcd1234
Data Center = us2

Enter each exactly as it appears — a wrong value here prevents every request from reaching your instance.

Step 5 — Configure OAuth 2.0 authentication

This connector authenticates with OAuth 2.0 tokens issued by the identity domain that fronts your Fusion instance, following Oracle's documented procedure (Oracle: Configure OAuth Using the Fusion Applications Identity Domain). It is never tied to a human password. The grant is client credentials: Oracle authorizes the calls as the Fusion user whose User Name is exactly the Client ID (Step 1). Reads and invoice creation work normally; on some tenants Oracle's scheduler intermittently refuses these tokens, so journal-entry creation can fail with 503 for stretches of up to about thirty minutes while every read keeps working — retry later without changing anything.

In the OCI console, open Identity & Security → Domains → the identity domain associated with Fusion (not "Default") → Integrated applications, and register (or reuse) a confidential application for server-to-server access.
Client ID / Client Secret — copy from the application's OAuth configuration page. The connector authenticates the token request with them.
Token URL — the OAuth 2.0 token endpoint of that identity domain, e.g. https://idcs-<tenant-guid>.identity.oraclecloud.com/oauth2/v1/token. This is a different host from your Fusion URL — copy it from the same page.
Authorized resources — before a Scope value exists to copy, the application has to be given one. On the same OAuth configuration page, under Resources, set Authorized resources to Specific, tick Add resources, click Add scope, and select the Oracle-provided Fusion resource for this pod. Until you do, the Resources section is empty and there is nothing to copy in the next step.
Scope — per-tenant; there is no universal value. On the application's OAuth configuration → Resources section, copy the full concatenated string shown (of the form urn:opc:resource:faaas:fa:<POD>urn:opc:resource:consumer::all). Any other value is rejected with invalid_scope — that error means the value is not on the application's authorized-resources list, not that it is malformed. Do not guess it or reuse another tenant's value.
On the application's OAuth configuration, make sure Client credentials is an allowed grant type, then Save and make sure the application is Active.
Check the Fusion user named after the Client ID. Oracle authorizes REST calls under a Fusion user's roles, not the OAuth client itself, so the Step 1 user's User Name must be exactly the Client ID, with the roles and data access from Steps 2–3.
In the Apideck connection, fill in Client ID, Client Secret, Token URL and Scope.

Common OAuth pitfall: obtaining a token succeeds (HTTP 200) but REST calls return 403. This means no Security Console user exists whose User Name exactly matches the Client ID, the user lacks its roles, or the security-data import (Step 2.5) has not run. Fix the user/roles per Steps 1–3 — do not try to map roles through the Security Console's "API Authentication / External Client Application" page; that configures trust for tokens issued by an external identity provider and is not needed when the tokens come from the Fusion identity domain itself.

Verifying credentials with curl: HTTP Basic auth is handy for checking roles and connectivity outside Apideck (e.g. curl -u user:pass .../ledgersLOV), but run these checks with a separate human or administrator account, never with the integration user: repeated failed Basic sign-ins can lock that user, breaking every connector call while token requests continue to succeed. Basic Auth is not a supported connection method — connections authenticate with OAuth 2.0 only.

Step 6 — Configure the connection in Apideck (Ledger and Data Access Set)

Each connection is scoped to a single Oracle Fusion General Ledger. After Host/Data Center and authentication are saved, two dropdowns become available:

Ledger — select the ledger this connection reads and creates journal entries in. For more than one ledger, create a separate connection per ledger.
Data Access Set — select the Read-Write Data Access Set for the ledger you chose (the one you granted in Step 3).

If either dropdown is empty, the integration user has no data access yet, or the two scheduled processes in Step 2.5 have not run since the grant — see Step 3.

Step 7 — Configure resource settings

Journal Entries

Default Journal Source — the journal source recorded on entries created through this connection. This is a dropdown with a fixed list, currently Manual and Accruals — not a free-text field, so a source your GL uses under any other name cannot be selected yet.
Default Journal Category — the journal category recorded on those entries. Also a fixed list: Manual, Accrual and Adjustment.

Choose Manual for both unless you have verified otherwise. Manual exists in every Oracle Fusion GL out of the box and is the only combination verified end to end for this connector.

⚠️ The source you pick must be one your General Ledger accepts for journal import, and Oracle does not tell you when it is not. A source it cannot use is accepted by the create call exactly like a good one — same 201, same ess-group: receipt — and then no journal is ever created. If creates return an id but no journal appears in the list afterwards, this setting is the first thing to check. Accruals in particular is offered in the list but did not produce journals on the environment this connector was verified against; treat it as unverified.

Tracking Categories

Tracking Segment Value Set Code — the value set backing the chart-of-accounts segment you want exposed as tracking categories (typically your cost centre or department segment). Find it under Manage Chart of Accounts Value Sets, or on the segment's row under Manage Chart of Accounts Structures. A chart of accounts has several segments; a connection exposes exactly one of them, so that tracking-category ids stay unambiguous.

Invoices (required if you use the invoices resource)

Receivables Business Unit — the business unit invoices are created against, exactly as it appears in Oracle. It only affects invoices you create; keep it within the business unit granted in the Step 3 data-access row, or invoices created through the connection will not be visible to it afterwards. Find it under Manage Business Units.
Receivables Transaction Source — the batch source invoices are entered under. Use a source of type Manual (see the Receivables setup guide, Section D); an Imported source has not been verified. Its Automatic transaction numbering flag decides who numbers the invoice: enabled, Oracle assigns the number and ignores any number sent on a create; disabled, the number sent is kept and every create must supply one. Find it under Manage Transaction Sources.
Invoice Transaction Type — the Receivables transaction type applied to invoices created through Apideck. Enter Invoice (the name Oracle seeds) unless your tenant renamed or replaced it; the name must match Manage Transaction Types exactly. Leave it blank to let Oracle apply its own default. Credit memos are a different document type and cannot be created through this connector.
Invoice Flexfield Context (optional) — only if your custom fields live under a context of the Transactions descriptive flexfield: enter that context code. Leave it empty when the segments are global. Either way, custom_fields[].id must be a deployed segment's API Name (see the Receivables setup guide, Section K).

Step 8 — Test your connection

Save and test the connection. Validation calls the Ledgers list endpoint (a lightweight GET) — success confirms Host, Data Center and authentication are correct.

It does not confirm the Data Access Set is Read-Write (see Step 3), and it does not prove the user can see any data: validation also succeeds for a user with no data access at all, because Oracle returns an empty list rather than an error. If General Ledger resources work but invoice lists come back empty, check the Business Unit data access in Step 3 and confirm both scheduled processes in Step 2.5 have run since that grant.
Tell the team that asked you to set this up that the connection is ready. The first API call is made with their Apideck application id and API key, which they hold — the Configuration Guide has the request.

What to expect once connected

The full behaviour contract — every supported operation, filter, and limitation — lives in the Configuration Guide. Five things are worth knowing while you test, because each can be mistaken for a fault in the connector:

Journal creation is asynchronous. The call returns before the journal exists, and the id it returns is a submission receipt (ess-group:...), not a journal id. Ask for that receipt again a minute later and it answers with the journal itself; until then it answers "not found". Account and period errors never come back from the create call — they surface only in the import, under Navigator → Tools → Scheduled Processes.
Journals are created Unposted, and cannot be updated at any status. Posting stays a step your team performs in Oracle.
A journal create that fails is reported as a failure, even though Oracle's own response for a refused submission carries a success status. Two different failures are worth telling apart:
- The submission was refused — Oracle would not accept it at all, so no import request exists to look at and Oracle gives no reason. The connector reports 503 (the scheduler is refusing the connection's token — see the 503 row in Troubleshooting), 403 (most likely the integration user cannot submit the journal-import process) or 502 (undetermined; retry).
- The submission was accepted but the import produced no journal — this is where a closed accounting period or an account the ledger rejects shows up. Nothing is returned to the caller at all, because the create already succeeded; the reason is in the import request under Navigator → Tools → Scheduled Processes.
A 400 or 422 is a third thing entirely and never reaches Oracle: the connector refused the request itself — 422 when the connection is missing a required setting, 400 when the journal is unbalanced, has fewer than two lines, carries a line without ledger_account.code, or breaks one of the payload rules in the API reference.
Invoices can be created but not updated or deleted. Oracle only creates completed invoices, and a completed invoice is not editable or deletable — correct one with a credit memo or an adjustment, exactly as you would in Oracle directly.
tracking-categories is refused with a 400 until the Tracking Segment Value Set Code setting is filled in. It needs a tracking (cost centre or department) segment in your chart of accounts to point at; a value set with no values returns an empty list.

Troubleshooting

Symptom	Likely cause	Fix
Every request fails to reach Oracle	Wrong Host or Data Center	Re-derive both from the instance URL (Step 4).
`403` on every REST call, with an empty response body	The user lacks the Access FSCM Integration Rest Service privilege, or the two scheduled processes have not run since the role was assigned	General Accounting Manager already carries the privilege (Step 2.3); if you built a custom role, add it there. Then run both processes in order (Step 2.5).
`401 Unauthorized` on REST while token requests still succeed	The Fusion integration user is locked (often by repeated failed Basic-auth checks) or broken	Unlock or repair the integration user in the Security Console. Never run curl Basic-auth checks against it.
`401 Unauthorized` on a curl Basic-auth check	Using an admin email login (MFA / wrong identity domain)	Run the check with a separate plain Fusion User Name account — not an email login, and never the integration user.
OAuth token succeeds but REST calls `403`	No Security Console user's User Name equals the Client ID, or that user lacks its roles	Fix the user and its roles (Steps 1–3, Step 5.7), then re-run both scheduled processes.
Creating a journal entry returns `503` while reads and invoices work	Oracle's scheduler is refusing the connection's client-credentials token at the moment	Retry later without changing anything; on some tenants this lasts up to about thirty minutes.
`200` with an empty list right after granting access	The grant has not been finalized	Run both scheduled processes in order (Step 2.5), then re-test. Waiting alone does not finalize a grant.
Every GL resource works but invoice lists are empty	No Business Unit data-access row for the integration user	Add the Business Unit row (Step 3.3).
Connection validates, but journal creation fails with a security/authorization error	Data Access Set is Read-Only	Grant / select a Read-Write Data Access Set (Step 3).
Journal creates return an id but no journal ever appears	The Default Journal Source (Step 7) is not one this GL accepts for import — Oracle accepts the submission and creates nothing, with no error anywhere	Set the source to one your GL uses for imported journals; `Manual` is the verified default. Check this before the period below: it produces no import request at all, so there is nothing to find under Scheduled Processes.
Journal import runs but silently produces no journal	Target accounting period is not open, or account/segment invalid	Open the period with the Open General Ledger Periods scheduled process (or Navigator → General Accounting → Period Close); check the request under Tools → Scheduled Processes.
Ledger / Data Access Set dropdowns are empty	The integration user has no data access to any ledger, or no ledger exists	Complete Step 3; if there is genuinely no GL, see the Greenfield GL setup guide.
`GET /accounting/ledger-accounts` returns `403`	Integration user lacks the `Get Enterprise Structures Using REST Service` privilege	Grant it on a custom role (Step 2, enterprise-structures callout) and re-run both scheduled processes. Search Security Console for "REST Service", not "REST API".
`GET /accounting/tracking-categories` returns `403`	Integration user lacks the `Get Enterprise Structures Using REST Service` privilege	Same fix as the row above.
`GET /accounting/tracking-categories` returns an empty list	The Tracking Segment Value Set Code setting points at a value set with no values, or at the wrong segment	Check the code against Manage Chart of Accounts Value Sets; it must be the value set backing your cost-centre / department segment.
Creating an invoice fails: the accounting date isn't in an open or future-enterable period (`AR-855397`)	No Receivables period is open — GL periods are separate	Open the Receivables period; see the Receivables setup guide.
Creating an invoice fails: the customer bill-to site you entered doesn't exist (`AR-857620`), or a date-effectivity error (`AR-855322`)	The customer's site is not visible to the business unit, or its effective dates do not cover the transaction date	Check the business unit's set assignments and the site's effective dates; see the Receivables setup guide.
Creating an invoice fails on the memo line (`AR-857629`)	The line referenced a memo line by id or with the wrong case, or referenced one reserved for another document type	Send the memo line's exact, case-sensitive name in `item.code`; prefer `Goods and Services`.

Your Oracle Fusion Cloud Financials connection is now configured.