Apigee has a powerful utility called the Apigee API which offers services such as:
Deploying or undeploying API proxies
Configuring virtual hosts, keystores and truststores, and so on
Creating, deleting and updating entities such as key value maps (KVMs), API products, developer
apps, developers, consumer keys, and so on
Retrieving information about these entities
These services are made accessible through a component called Management Server in the
Apigee platform. These services can be invoked easily with the help of simple API
calls.
Sometimes we may need to use one or more of these services from API proxies at runtime. This is
because the entities such as KVMs, OAuth access tokens, API products, developer apps,
developers, consumer keys, and so on contain useful information in the form of key-value pairs, custom
attributes or as part of its profile.
For instance, you can store the following information in a KVM to make it more secure and
accessible at runtime:
Back-end target URLs
Environment properties
Security credentials of backend or third party systems
Similarly, you may want to get the list of API products or the developer's email address at runtime.
This information will be available as part of the developer apps profile.
All this information can be effectively used at runtime to enable dynamic behaviour in policies
or custom code within Apigee.
Antipattern
The Apigee APIs are preferred and useful for administrative tasks and should not be used for
performing any runtime logic in API proxies flow. This is because:
Using Apigee APIs to access information about the entities such as KVMs, OAuth
access tokens or for any other purpose from API proxies leads to dependency on Management
Servers.
Management Servers are not a part of Apigee runtime components and therefore, they may not be
highly available.
Management Servers also may not be provisioned within the same network or data center and may
therefore introduce network latencies at runtime.
The entries in the Management Servers are cached for a longer period of time, so you may not be
able to see the latest data immediately in the API proxies if you perform writes and reads in a
short period of time.
Increases network hops at runtime.
In the code sample below, the Apigee API call is made via the custom JavaScript code to
retrieve the information from the KVM:
If the Management Server is unavailable, then the JavaScript code invoking the Apigee API
call fails. This subsequently causes the API request to fail.
Impact
Introduces additional dependency on Management Servers during runtime. Any failure in
Management Servers will affect the API calls.
User credentials for Apigee APIs need to be stored either locally or in some secure store
such as an encrypted KVM.
Performance implications owing to invoking the management service over the network.
May not see the updated values immediately due to longer cache expiration in Management
Servers.
Best practice
There are more effective ways of retrieving information from entities such as KVMs, API
products, developer apps, developers, consumer keys, and so on at runtime. Here are a few examples:
Use a KeyValueMapOperations policy to access information from KVMs. Here's sample code
that shows how to retrieve information from the KVM:
To access information about API products, developer apps, developers, consumer keys, and so on
in the API proxy, you can do either of the following:
If your API Proxy flow has a VerifyAPIKey policy, then you can access the information
using the flow variables populated as part of this policy. Here is sample code that shows
how to retrieve the name and created_by information of a Developer App using JavaScript:
<!--/antipatterns/examples/2-7.xml-->
print("Application Name ",context.getVariable(""verifyapikey.VerifyAPIKey.app.name"));print("Createdby:", context.getVariable("verifyapikey.VerifyAPIKey.app.created_by"));
If your API Proxy flow doesn't have a VerifyAPIKey policy, then you can access the
profiles of API products, developer apps, and so on using the AccessEntity and ExtractVariables
policies:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-26 UTC."],[[["\u003cp\u003eThe Apigee API is designed for administrative tasks and should not be used for runtime logic within API proxies, as it creates dependency on the Management Servers.\u003c/p\u003e\n"],["\u003cp\u003eRelying on Apigee APIs at runtime can cause performance issues and introduce network latencies because Management Servers are not part of the runtime components and may not be in the same network or data center.\u003c/p\u003e\n"],["\u003cp\u003eDirect calls to Management Servers can lead to outdated data being retrieved by API proxies due to longer caching periods, affecting data accuracy.\u003c/p\u003e\n"],["\u003cp\u003eFor accessing information at runtime, it is more effective to use policies like \u003ccode\u003eKeyValueMapOperations\u003c/code\u003e for KVM data or flow variables from the \u003ccode\u003eVerifyAPIKey\u003c/code\u003e policy for API products and developer app information, instead of calling the Apigee API.\u003c/p\u003e\n"],["\u003cp\u003eIf \u003ccode\u003eVerifyAPIKey\u003c/code\u003e policy is not in use, \u003ccode\u003eAccessEntity\u003c/code\u003e and \u003ccode\u003eExtractVariables\u003c/code\u003e policies are preferred for retrieving profiles of entities like developer apps during runtime, ensuring efficient access to needed information.\u003c/p\u003e\n"]]],[],null,["*You're viewing **Apigee** and **Apigee hybrid** documentation.\nView [Apigee Edge](https://docs.apigee.com/api-platform/antipatterns/invoking-management) documentation.*\n\nApigee has a powerful utility called the [Apigee API](/apigee/docs/reference/apis/apigee/rest) which offers services such as:\n\n- Deploying or undeploying API proxies\n- Configuring virtual hosts, keystores and truststores, and so on\n- Creating, deleting and updating entities such as key value maps (KVMs), API products, developer apps, developers, consumer keys, and so on\n- Retrieving information about these entities\n\nThese services are made accessible through a component called *Management Server* in the\nApigee platform. These services can be invoked easily with the help of simple API\ncalls.\n\nSometimes we may need to use one or more of these services from API proxies at runtime. This is\nbecause the entities such as KVMs, OAuth access tokens, API products, developer apps,\ndevelopers, consumer keys, and so on contain useful information in the form of key-value pairs, custom\nattributes or as part of its profile.\n\nFor instance, you can store the following information in a KVM to make it more secure and\naccessible at runtime:\n\n- Back-end target URLs\n- Environment properties\n- Security credentials of backend or third party systems\n\nSimilarly, you may want to get the list of API products or the developer's email address at runtime.\nThis information will be available as part of the developer apps profile.\n\nAll this information can be effectively used at runtime to enable dynamic behaviour in policies\nor custom code within Apigee.\n\nAntipattern\n\nThe Apigee APIs are preferred and useful for administrative tasks and should not be used for\nperforming any runtime logic in API proxies flow. This is because:\n\n- Using Apigee APIs to access information about the entities such as KVMs, OAuth access tokens or for any other purpose from API proxies leads to dependency on Management Servers.\n- Management Servers are not a part of Apigee runtime components and therefore, they may not be highly available.\n- Management Servers also may not be provisioned within the same network or data center and may therefore introduce network latencies at runtime.\n- The entries in the Management Servers are cached for a longer period of time, so you may not be able to see the latest data immediately in the API proxies if you perform writes and reads in a short period of time.\n- Increases network hops at runtime.\n\nIn the code sample below, the Apigee API call is made via the custom JavaScript code to\nretrieve the information from the KVM: \n\n```gdscript\nvar response = httpClient.send('https://apigee.googleapis.com/v1/organizations/$ORG/environments/$ENV/keyvaluemaps')\n```\n\nIf the Management Server is unavailable, then the JavaScript code invoking the Apigee API\ncall fails. This subsequently causes the API request to fail.\n\nImpact\n\n- Introduces additional dependency on Management Servers during runtime. Any failure in Management Servers will affect the API calls.\n- User credentials for Apigee APIs need to be stored either locally or in some secure store such as an encrypted KVM.\n- Performance implications owing to invoking the management service over the network.\n- May not see the updated values immediately due to longer cache expiration in Management Servers.\n\nBest practice\n\nThere are more effective ways of retrieving information from entities such as KVMs, API\nproducts, developer apps, developers, consumer keys, and so on at runtime. Here are a few examples:\n\n- Use a [KeyValueMapOperations policy](/apigee/docs/api-platform/reference/policies/key-value-map-operations-policy) to access information from KVMs. Here's sample code that shows how to retrieve information from the KVM: \n\n ```verilog\n \u003c!-- /antipatterns/examples/2-6.xml --\u003e\n \u003cKeyValueMapOperations mapIdentifier=\"urlMap\" async=\"false\"\n continueOnError=\"false\" enabled=\"true\" name=\"GetURLKVM\"\u003e\n \u003cDisplayName\u003eGetURLKVM\u003c/DisplayName\u003e\n \u003cExpiryTimeInSecs\u003e86400\u003c/ExpiryTimeInSecs\u003e\n \u003cScope\u003eenvironment\u003c/Scope\u003e\n \u003cGet assignTo=\"urlHosti\" index=\"2\"\u003e\n \u003cKey\u003e\n \u003cParameter\u003eurlHost_1\u003c/Parameter\u003e\n \u003c/Key\u003e\n \u003c/Get\u003e\n \u003c/KeyValueMapOperations\u003e\n ```\n- To access information about API products, developer apps, developers, consumer keys, and so on in the API proxy, you can do either of the following:\n - If your API Proxy flow has a [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy), then you can access the information using the flow variables populated as part of this policy. Here is sample code that shows how to retrieve the name and created_by information of a Developer App using JavaScript: \n\n ```css+lasso\n \u003c!-- /antipatterns/examples/2-7.xml --\u003e\n print(\"Application Name \", context.getVariable(\"\"verifyapikey. VerifyAPIKey.app.name\"));\n print(\"Created by:\", context.getVariable(\"verifyapikey. VerifyAPIKey.app.created_by\"));\n ```\n - If your API Proxy flow doesn't have a [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy), then you can access the profiles of API products, developer apps, and so on using the `AccessEntity` and `ExtractVariables` policies:\n 1. Retrieve the profile of developer app with the [AccessEntity policy](/apigee/docs/api-platform/reference/policies/access-entity-policy): \n\n ```carbon\n \u003c!-- /antipatterns/examples/2-8.xml --\u003e\n \u003c?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?\u003e\n \u003cAccessEntity async=\"false\" continueOnError=\"false\" enabled=\"true\" name=\"GetDeveloperApp\"\u003e\n \u003cDisplayName\u003eGetDeveloperApp\u003c/DisplayName\u003e\n \u003cEntityType value=\"app\"\u003e\u003c/EntityType\u003e\n \u003cEntityIdentifier ref=\"developer.app.name\" type=\"appname\"/\u003e\n \u003cSecondaryIdentifier ref=\"developer.id\" type=\"developerid\"/\u003e\n \u003c/AccessEntity\u003e\n ```\n 2. Extract the `appId` from developer app with the [ExtractVariables policy](/apigee/docs/api-platform/reference/policies/extract-variables-policy): \n\n ```gdscript\n \u003c!-- /antipatterns/examples/2-9.xml --\u003e\n \u003cExtractVariables name=\"Extract-Developer App-Info\"\u003e\n \u003c!--\n The source element points to the variable populated by AccessEntity policy.\n The format is \u003cpolicy-type\u003e.\u003cpolicy-name\u003e\n In this case, the variable contains the whole developer profile.\n --\u003e\n \u003cSource\u003eAccessEntity.GetDeveloperApp\"\u003c/Source\u003e\n \u003cVariablePrefix\u003edeveloperapp\u003c/VariablePrefix\u003e\n \u003cXMLPayload\u003e\n \u003cVariable name=\"appld\" type=\"string\"\u003e\n \u003c!-- You parse elements from the developer profile using XPath. --\u003e\n \u003cXPath\u003e/App/AppId\u003c/XPath\u003e\n \u003c/Variable\u003e\n \u003c/XMLPayload\u003e\n \u003c/ExtractVariables\u003e\n ```\n\nFurther reading\n\n- [KeyValueMapOperations policy](/apigee/docs/api-platform/reference/policies/key-value-map-operations-policy)\n- [VerifyAPIKey policy](/apigee/docs/api-platform/reference/policies/verify-api-key-policy)\n- [AccessEntity policy](/apigee/docs/api-platform/reference/policies/access-entity-policy)"]]