In-context decoy APIs consist of decoy paths within existing APIs supporting legitimate traffic to backend servers. Any traffic accessing a decoy path receives a preconfigured response. For example, in the shopping API, /root and /admin are decoy APIs; /shoes is a legitimate API path. Traffic accessing /shoes is redirected to the backend API server, while the traffic that accesses /root or /admin receives a preconfigured response.

The following snippet of an API JSON file shows an in-context decoy API:

 "api_metadata": {
 "protocol": "http",
 "url": "/shop",
 "hostname": "*",
 "cookie": "",
 "cookie_idle_timeout": "200m",
 "logout_api_enabled": false,
 "cookie_persistence_enabled": false,
 "login_url": "",
 "api_mapping": {
 "internal_url": ""
; Note – other configuration parameters removed
 "decoy_enabled": true, 
 "response_code" : 200, decoy API Configuration 
 "response_def" : "OK", 
 "response_message" : "OK", 
 "decoy_subpaths": [

The API JSON file defines normal API paths consisting of the path /shop. The decoy configuration is enabled for “/shop/root” and “/shop/admin” with the following parameters:

  • decoy_enabled parameter is set to true. If set to false, no decoy paths are configured.
  • response_code is set to 200. When a decoy sub-path is accessed, return a 200 response.
  • response_def is set to OK. When a decoy sub-path is accessed, return OK as the response.

An in-context decoy API can have a maximum of 32 sub-paths configured for an API.

Warning: When configuring in-Context decoy APIs, do not leave empty sub-paths which makes your business API into an out-of-context API. No traffic will be forwarded to backend application servers.