Rate This Article
Send Docs Feedback

Resource files

Many policy types defined by Apigee Edge rely on 'resources'. Resources are the files that implement the code or configuration to be executed by a policy when attached to an API proxy. In some cases, as with JavaScript and JavaCallout, a policy simply defines an attachment point in an API proxy where some code should execute. A JavaScript or JavaCallout policy is a pointer to a resource.

In the management UI, resources specific to the API proxy are listed in the Scripts section of the Navigation pane.

These resources can be stored in any of three locations in an organization.

  • API proxy: When stored in an API proxy, resources are available only to that API proxy
  • Environment: When stored in an environment (for example, test or prod), the resource is available to any API proxy deployed in the same environment.
  • Organization: When stored in an organization, the resource is available to any API proxy deployed in any environment.

Although all the the examples in the Build APIs topics store resources and policies in the API proxy package, API Services also provides repositories for these resources at the organization and the environment level. By storing resources at the organization or the environment level, you enable re-use and sharing of code and configuration across the API proxies deployed in your organization and across different environments.

The example API calls in this topic use cURL. You can also use the SmartDocs management API reference topics to make the same calls. See the Resource files API.

Resource types

Resource repositories support the following resource types:

  • jsc: compiled JavaScript, referenced by policies of type Javascript
  • java: Java classes, referenced by policies of type JavaCallout
    (Available in Apigee Edge plans only. See Apigee Developer vs. Apigee Edge.)
  • py: Python scripts, referenced by policies of type Python 
    (Available in Apigee Edge plans only. See Apigee Developer vs. Apigee Edge.)
  • node: Node.js files, including the main Node.js file, related source files, and module dependencies
  • wsdl: WSDL files, referenced by policies of type MessageValidation
  • xsd: XML schemas, referenced by policies of type MessageValidation
  • xsl: XSLT transformations, referenced by policies of type XSL

The repositories are available at the following URIs, as described in the Resource files API:


You can also add resources at the API proxy scope in the Edge management UI. In the proxy editor Develop view, select New > New Script.

For example, all JavaScript files available across an organization are stored under:


JavaScript stored in the /organizations collection is available to any API proxy running in any environment.

You can list all available resources by calling GET on the collection:

$ curl https://api.enterprise.apigee.com/v1/organizations/{org_name}/resourcefiles/{resource_type}

The following request lists all JavaScript resources at the organization level:

$ curl https://api.enterprise.apigee.com/v1/organizations/myorg/resourcefiles/jsc

The following request lists all JavaScript resources at the environment level, in the environment called prod:

$ curl https://api.enterprise.apigee.com/v1/organizations/myorg/environments/prod/resourcefiles/jsc

The following request lists all JavaScript resources in an API proxy revision (the most specific level):

$ curl https://api.enterprise.apigee.com/v1/organizations/myorg/apis/weatherapi/revisions/6/resourcefiles/jsc

Each request returns a list of resource names.

Sample response:


Populating resource repositories

When updating an existing resource in a deployed API proxy, you must redeploy the API proxy after to ensure the resource changes are picked up. Newly added resources do not require API proxy redeployment.

Let's assume that you have a simple snippet of JavaScript that you need to make available to API proxies across your organization. The following sample JavaScript sets the HTTP request path to the value of the proxy.basepath variable. It's just one example of a resource that you might need to put in the repository.

request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));

To create a resource, you call the POST method, submitting the body of the resource file, and identifying the resource's name and type as query parameters.

To make the JavaScript available to API proxies running in any environment in your organization:

$ curl -X POST -H "Content-type:application/octet-stream" -d \
'request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));' \
https://api.enterprise.apigee.com/v1/organizations/myorg/resourcefiles?"name=pathSetter&type=jsc" \
-u email:password

Sample response:

  "name" : "pathSetter",
  "type" : "jsc"

You can also upload resources as files from your local machine as follows:

$ curl -X POST -H "Content-type:application/octet-stream" -d @pathSetter.js \
https://api.enterprise.apigee.com/v1/organizations/myorg/resourcefiles?"name=pathSetter&type=jsc" \
-u email:password

The JavaScript resource named pathSetter is now available to be referenced by policies of type JavaScript running in any environment.

For example, to attach the JavaScript to the Request PostFlow, create a policy called PathSetterPolicy.xml that references the file pathSetter.js:

<Javascript name='PathSetterPolicy' timeLimit='200'>

Then reference the policy in the Endpoint configuration:



Adding Java resources

Add compiled Java resources as JAR files. When uploading with cURL, be sure to use the -T or --data-binary option (not the -d option), as shown in the following examples.

curl -v -u {user}:{password} -H "Content-Type: application/octet-stream" \
-X POST --data-binary @{jar_file} \
curl -v -u {user}:{password} -H "Content-Type: application/octet-stream" \
-X POST -T "{jar_file}" \

See also

Resource name resolution

Apigee Edge resolves resource names from the most specific to the most general scope. Resource names are resolved "up the chain", from the API proxy level, to the environment level, to the organization level.

Let's say that you have populated the same resource in two different repositories — the organization and the environment:

$ curl -X POST -H "Content-type:application/octet-stream" -d \
'request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));' \
https://api.enterprise.apigee.com/v1/organizations/myorg/resourcefiles?"name=pathSetter&type=jsc" \
-u email:password
$ curl -X POST -H "Content-type:application/octet-stream" -d \
'request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));' \
https://api.enterprise.apigee.com/v1/organizations/myorg/environments/prod/resourcefiles?"name=pathSetter&type=jsc" \
-u email:password

Let's take a scenario where the same resource is available in two repositories, at the organization level and at the environment level:


Now imagine that an API proxy is configured with the following Policy:

<Javascript name='PathSetterPolicy' timeLimit='200'>

The policy reference cannot explicitly resolve to a repository. The first resource whose name matches the resource name in the policy is resolved.

So, when the API proxy is deployed in the environment prod, the Policy will resolve the pathSetter.js resource:

When deployed in the environment test, the Policy will resolve:

Retrieving resources

You can view a resource body by calling the GET method on it:

$ curl -X GET -H "Accept:application/json"
https://api.enterprise.apigee.com/v1/organizations/myorg/resourcefiles/jsc/pathSetter" \
-u email:password

Sample response:

request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));

Help or comments?

  • Something's not working: Ask the Apigee Community or see Apigee Support
  • Something's wrong with the docs: Click Send Docs Feedback on this page.
    (Incorrect? Unclear? Broken link? Typo?)