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

> Source: https://netray.co/tools/oracle-ebs-isg-rest-service-curl-generator
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Generate working curl commands for a PL/SQL API deployed as a REST service through Oracle EBS 12.2 Integrated SOA Gateway, with the RESTHeader context.

## Category

developer

## Erp

Oracle E-Business Suite

## Audience

- Oracle EBS developer
- Integration developer
- Apps DBA

## Tool

**Kind:** template

**Output:** code

**Language:** text

**Fields:**

#### Base URL

**Key:** base_url

**Type:** text

**Default:** https://ebs.example.com:4443

#### Service alias (as deployed)

**Key:** alias

**Type:** text

**Default:** fndUserSvc

#### Operation (lower case, as in WADL)

**Key:** method

**Type:** text

**Default:** testusername

#### Operation root name (upper case)

**Key:** root

**Type:** text

**Default:** TESTUSERNAME

**Help:** The payload root is <ROOT>_Input.

#### Product code in namespace

**Key:** product

**Type:** text

**Default:** fnd

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

#### EBS user name

**Key:** user

**Type:** text

**Default:** OPERATIONS

#### Responsibility key

**Key:** resp

**Type:** text

**Default:** SYSTEM_ADMINISTRATOR

#### Responsibility application short name

**Key:** resp_app

**Type:** text

**Default:** SYSADMIN

#### Security group

**Key:** sec_group

**Type:** text

**Default:** STANDARD

#### NLS language

**Key:** nls

**Type:** text

**Default:** AMERICAN

#### Org ID

**Key:** org_id

**Type:** text

**Default:** 204

#### InputParameters JSON

**Key:** input

**Type:** textarea

**Default:** { "X_USER_NAME": "OPERATIONS" }

**Blocks:**

#### 1. Log in and keep the session cookie

**Body:** # Creates an EBS session; the session cookie is stored in ebs_cookies.txt
curl -s -u '{{user}}:YOUR_PASSWORD' \
     -H 'Accept: application/json' \
     -c ebs_cookies.txt \
     {{base_url}}/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)

**Body:** curl -s -X POST {{base_url}}/webservices/rest/{{alias}}/{{method}}/ \
     -b ebs_cookies.txt \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
     -d '{
  "{{root}}_Input": {
    "@xmlns": "http://xmlns.oracle.com/apps/{{product}}/rest/{{alias}}/{{method}}/",
    "RESTHeader": {
      "@xmlns": "http://xmlns.oracle.com/apps/{{product}}/rest/{{alias}}/header",
      "Responsibility": "{{resp}}",
      "RespApplication": "{{resp_app}}",
      "SecurityGroup": "{{sec_group}}",
      "NLSLanguage": "{{nls}}",
      "Org_Id": "{{org_id}}"
    },
    "InputParameters": {{input}}
  }
}'

#### 3. Same call with an explicit Cookie header

**Body:** # Use the accessTokenName and accessToken values returned by the login call
curl -s -X POST {{base_url}}/webservices/rest/{{alias}}/{{method}}/ \
     -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

**Body:** curl -s -X POST {{base_url}}/webservices/rest/{{alias}}/{{method}}/ \
     -u '{{user}}:YOUR_PASSWORD' \
     -H 'Content-Type: application/json' \
     -H 'Accept: application/json' \
     -d @payload.json

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

**Notes:** 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.

## Content

**Intro:** 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.

**Sections:**

#### How to use it

**Body:** 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.

**Bullets:**

- 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

**Body:** 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

**Body:** 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

**Body:** 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.

**Cta:** 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.

**Faq:**

#### Does Oracle EBS have a REST API?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

oracle ebs rest api, rest api for oracle ebs, oracle ebs rest api example, how to create backend rest api in ebs oracle, oracle ebs api web service, integrated soa gateway rest service, ebs isg restheader json payload, webservices rest login ebs

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json