Apigee Edge provides a range of out-of-the-box policy capabilities that address common API management requirements. However, there are some cases where your API requires custom behavior that is not implemented in the out-of-the-box policy palette. In these cases, Apigee provides several options that enable developers to script or code customized API behavior. One approach is to implement the desired behavior in the Java programming language.

For lightweight operations, such as API calls to remote services, the ServiceCallout policy is recommended. See Call services or APIs using ServiceCallout.

For relatively simple interaction with message content, such as modifying or extracting HTTP headers, parameters, or message content, you can use JavaScript or Python languages.


To get started writing Java for Apigee Edge, refer to the JavaCallout Javadocs.

JavaCallout Samples

For commented sample code, see the JavaCallout samples repository.

Compiling, deploying, testing

JavaCallouts depend on two JAR files that are available in Apigee Edge samples repository on Github. For instructions on compiling and deploying, see the instructions provided in the JavaCallout overview.

Configuring a JavaCallout policy

A JavaCallout policy references a main JAR file. The referenced JAR file contains compiled Java code written to the Java API exposed by the API Platform processing pipeline. This JAR must be placed in an API proxy under /resources/java. 

If your JavaCallout code relies on additional third-party libraries packaged as independent JAR files, then place those JAR files in the /resources/java directory as well, to ensure that they are loaded correctly at runtime. If you are using the management UI to create or modify the proxy, you can add a new resource and specify an additional dependent JAR file. If there are multiple JARs, simply add them as additional resources. You do not need to modify the policy configuration to refer to additional JAR files. Putting them in /resources/java is sufficient. 

System calls, for example network I/O, filesystem read/writes, current user info, process list, and CPU/memory utilization are not permitted by the security model. Although some such calls may be functional, they are unsupported and liable to be actively disabled at any time. For forward compatibility, you should avoid making such calls in your JavaCallout.

Configure the JavaCallout policy using the following elements.

The name attribute for this policy is restricted to these characters: A-Z0-9._\-$ %. However, the Management UI enforces additional restrictions, such as automatically removing characters that are not alphanumeric.

Field Name Description
ResourceURL Specifies the Java resource that is the name of the JAR file). Note that only resource of type java is allowed
ClassName Specifies the name of the Java class that executes the callout

Example - Java Callout policy

In the example below, the element, ResourceURL specifies the name of the relevant JAR file.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<JavaCallout name="MyJavaCalloutPolicy">

Policy-specific error codes

The default format for error codes returned by Policies is:

  "code" : " {ErrorCode} ",
  "message" : " {Error message} ",
  "contexts" : [ ]

The JavaCallout Policy type defines the following error codes:

Error Code Message
JavaCalloutInstantiationFailed Failed to instantiate the JavaCallout Class {0}
NoResourceForURL Could not locate a resource with URL {0}
NoAppropriateConstructor No appropriate constructor found in JavaCallout class {0}
JavaClassNotFoundInJavaResource Failed to find the ClassName in java resource {0} - {1}
JavaClassDefinitionNotFound Failed to load java class {0} definition

Policy schema

Each policy type is defined by an XML schema (.xsd). For reference, policy schemas are available on GitHub.

Help or comments?

  • Something's not working: See Apigee Support
  • Something's wrong with the docs: Click Send Feedback in the lower right.
    (Incorrect? Unclear? Broken link? Typo?)