Developer ToolsFree generatorPDF, Excel, Word exportOracle E-Business SuiteAll Oracle E-Business Suite tools

Oracle EBS REST API Example Generator: Integrated SOA Gateway Calls with curl

This generator produces curl commands that call a PL/SQL API exposed as a REST service through Oracle E-Business Suite 12.2 Integrated SOA Gateway (ISG), using either a login session cookie or HTTP Basic authentication. It fills the RESTHeader that sets responsibility, application, security group, language and org, so the API runs with the right EBS context.

Fill in

The payload root is <ROOT>_Input.

Lower-case product short code of the interface, e.g. fnd, ar, ont.

Generated code
Download:

1. Log in and keep the session cookie

# Creates an EBS session; the session cookie is stored in ebs_cookies.txt
curl -s -u 'OPERATIONS:YOUR_PASSWORD' \
     -H 'Accept: application/json' \
     -c ebs_cookies.txt \
     https://ebs.example.com:4443/webservices/rest/login

# The response returns accessTokenName and accessToken, and the same token is set as a
# cookie. Keeping the cookie jar means later calls do not need to parse the body.

2. Invoke the operation with the session (token-based)

curl -s -X POST https://ebs.example.com:4443/webservices/rest/fndUserSvc/testusername/ \
     -b ebs_cookies.txt \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
     -d '{
  "TESTUSERNAME_Input": {
    "@xmlns": "http://xmlns.oracle.com/apps/fnd/rest/fndUserSvc/testusername/",
    "RESTHeader": {
      "@xmlns": "http://xmlns.oracle.com/apps/fnd/rest/fndUserSvc/header",
      "Responsibility": "SYSTEM_ADMINISTRATOR",
      "RespApplication": "SYSADMIN",
      "SecurityGroup": "STANDARD",
      "NLSLanguage": "AMERICAN",
      "Org_Id": "204"
    },
    "InputParameters": { "X_USER_NAME": "OPERATIONS" }
  }
}'

3. Same call with an explicit Cookie header

# Use the accessTokenName and accessToken values returned by the login call
curl -s -X POST https://ebs.example.com:4443/webservices/rest/fndUserSvc/testusername/ \
     -H 'Cookie: ACCESS_TOKEN_NAME=ACCESS_TOKEN_VALUE' \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
     -d @payload.json

4. Same call with HTTP Basic authentication

curl -s -X POST https://ebs.example.com:4443/webservices/rest/fndUserSvc/testusername/ \
     -u 'OPERATIONS:YOUR_PASSWORD' \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
     -d @payload.json

# payload.json holds the same JSON body as block 2

Payload structure, namespaces and RESTHeader keys follow the Oracle E-Business Suite Integrated SOA Gateway Developer's Guide 12.2 examples. Confirm the exact operation path, root element and namespace from the deployed service's WADL (View WADL in the REST Web Service tab), and that the user has a grant on the operation. Never store real passwords in scripts; use a dedicated integration user.

Get your ISG REST setup checked

Send us the WADL and the error you see and we will tell you whether it is the grant, the header or the ISG setup.

Optional. The tool and every export work without this. No spam.

Was this tool useful?

How to use it

Deploy the interface first: in the Integration Repository, find the PL/SQL API (custom APIs must be annotated and loaded into the repository), open the REST Web Service tab, enter a service alias, select the operations and HTTP verb, and deploy. Then add a grant on the operations for the integration user or group. Copy the alias, the operation name and root element from View WADL into the fields, along with the responsibility key and application short name the API needs. Run block 1 to log in, then block 2. A successful response contains an OutputParameters object with the API's OUT values; a failure returns an error with an ISG message code.

  • Responsibility is the responsibility key, not its display name.
  • Org_Id is needed for APIs that read multi-org secured data.
  • Leave optional RESTHeader values empty rather than removing the keys.

How ISG REST requests are structured

Every PL/SQL REST operation is a POST to /webservices/rest/<alias>/<operation>/ with a root object named <OPERATION>_Input. The root carries the operation namespace http://xmlns.oracle.com/apps/<product>/rest/<alias>/<operation>/, the RESTHeader object with its own header namespace, and InputParameters whose keys are the PL/SQL parameter names in upper case. The same structure works as XML with Content-Type application/xml. The login service at /webservices/rest/login creates an EBS session for the user and returns it as a cookie; later calls send that cookie instead of the password, which is why block 2 uses a cookie jar.

Version differences and gotchas

REST services in ISG are a 12.2 feature and need the ISG setup completed for your AD and TXK level, as described in the ISG installation note for Release 12.2 on My Oracle Support. Clients that parse accessToken from the login body are more fragile than clients that keep the returned cookie, so the generated calls use a cookie jar. A 401 usually means bad credentials, a 403 a missing grant on the operation, and an error about responsibility means the key or application short name does not match an assignment of that user.

How to check the result in EBS

If the call reached the API, its effect is visible in the base tables of the product, and ISG logging (enabled for the service in the Integration Repository) records the request. For a test, the default TESTUSERNAME operation on FND_USER_PKG checks a user name, which proves login, grants and the header without changing data. When moving to a write API, test in a clone with a dedicated integration user and check FND_LOG_MESSAGES or the service log for errors returned by the PL/SQL layer.

Frequently Asked Questions

Does Oracle EBS have a REST API?

Yes. In 12.2, Integrated SOA Gateway can deploy PL/SQL APIs, Java bean and application module services and, at later 12.2 code levels, concurrent programs from the Integration Repository as REST services. There is no fixed public catalogue of endpoints; you choose which interfaces to deploy, give each an alias, and grant operations to users.

How do I create a custom REST API in Oracle EBS?

Write a PL/SQL package with Integration Repository annotations in the specification, load it into the repository with the irep parser and FNDLOAD, then deploy it as a REST service with an alias from the Integration Repository and grant the operations. The service is then callable at /webservices/rest/<alias>/<operation>/ as shown here.

What goes in the RESTHeader of an EBS REST call?

Responsibility (key), RespApplication (application short name), SecurityGroup (usually STANDARD), NLSLanguage (for example AMERICAN) and Org_Id. ISG uses these to initialise the EBS session context before calling the API, the same way FND_GLOBAL.APPS_INITIALIZE and MO_GLOBAL do in PL/SQL.

Can I use Basic authentication instead of the login token?

Yes, ISG REST services accept HTTP Basic credentials on each call, as block 4 shows. Token-based login is preferred for many calls in a row because it creates one session and avoids sending the password repeatedly. In both cases use HTTPS and a dedicated integration user with only the grants it needs.

If you want an AI agent on your own servers to call these EBS REST services on behalf of users, with read-only defaults and approval before any write, we can set that up.

ArchRay builder
Design the on-prem AI stack for Oracle E-Business Suite: model, GPUs, RAG pipeline, guardrails
See memory, speed and cost as you swap parts, then export the diagram. Free, in your browser.
Open the builder

Keep exploring

Free tools

ERP fixes and how-tos

Runs with your ERP

AI on your ERP

Integrations

Software