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 scoped to an 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.

In addition to storing resources at the proxy level, 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 reuse 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.

Resource types

Resource repositories support the following resource types:

  • jsc: compiled JavaScript, referenced by policies of type Javascript
  • java: Java classes in a JAR file, 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 API:


You can also add resources at the API proxy scope in the Edge management UI, in the proxy editor Develop view.

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{org_name}/resourcefiles/{resource_type}

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

$ curl

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

$ curl

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

$ curl

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"));' \ \
-u email:password

Sample response:

  "name" : "pathSetter.js",
  "type" : "jsc"

You can also upload resources as files from your local machine as follows. It's important to use -F for the binary upload in cURL in order for the environment- and organization-scoped JavaScript files to be accessible by the JavaScript policy.

$ curl -X POST -H "Content-type:multipart/form-data" -F file=@pathSetter.js \ \
-u email:password

When using a REST client, such as Postman:

  • Set the Content-Type to multipart/form-data.
  • Attach the script as a file.

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

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:


Node.js resource guidelines

When you reference a Node.js script in an API proxy, you do so with the <ResourceURL> element in the API proxy's TargetEndpoint configuration, as described in Adding Node.js to an existing API proxy. For example:


That Node.js script and all supporting modules must reside at the API proxy scope (in the proxy bundle's /resources/node directory). In the management UI API proxy editor, adding the Node.js resource to the Scripts section accomplilshes this. So does using the management API to store the resource at the API proxy scope.

Adding Java resources

You can add compiled Java resources as JAR files using multiple options in cURL, such as -T, --data-binary, or -F option (not the -d option). For example:

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}" \
curl -v -u {user}:{password} -H "Content-Type: multipart/form-data" \
-X POST -F "file=@{jar_file}" \

Package naming: Don't use 'io.apigee' or 'com.apigee' as package names in Java Callouts. Those are reserved and used by other Apigee modules.

See also

Updating and deleting resource files

For API proxy-scoped resources, you can modify and delete them in the management UI's proxy editor.

To update and delete API resources at the environment and organization scopes (as well as the API proxy scope), see:

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.

Node.js: One exception to the following information is Node.js, which requires the scripts to be stored at the API proxy scope. See Node.js resource guidelines

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"));' \ \
-u email:password
$ curl -X POST -H "Content-type:application/octet-stream" -d \
'request.setHeader("RequestPath", flow.getVariable("proxy.basepath"));' \ \
-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 at the most granular scope 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 environment-scoped pathSetter.js resource:

When deployed in the environment test, the Policy will resolve to the org-scoped resource, because the environment-scoped resource is in the prod environment, not the test environment:

Retrieving resources

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

$ curl -X GET -H "Accept: application/json"" \
-u email

Sample response (which displays the contents of the resource file):

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

For more information on listing and getting resource files, see Resource files API in the management API.

Help or comments?