anchor.diff:  * *Rate Limit & quota policies*
   * *Spike arrest*
   * *Cache* - cache policy will not be testable through debug mode with in memory cache since it is created and destroyed with the api
  -* *IPFiltering* - Since calls are being executed by the gateway, you won't be able to IPFiltering your IPs directly in the debug session (IP used for the call would be 127.0.0.1 if you want to validate behavior)
  +* *IPFiltering* - Since calls are emited by the gateway itself, you will not be able to emulate a call from another IP with the debug mode (IP used to issue requests is 127.0.0.1)
   * *Health-check*
  -* *Virtual hosts* - the first host is selected
  +* *Virtual hosts* - the first host is always selected
  
positive.code: 
  Debug mode is a tool for troubleshooting your API proxies running on APIM. It provides detailed information about the behavior of each policy in your flows as well as the overall execution order at runtime. With debug, you can:
  
  * Understand which flows are triggered by a specific request (including Platform-level policies).
  * Visualise which exact Policies are executed or skipped (conditional policy).
  * Understand the order of execution of your policies.
  * Trace transformations and changes made to headers, body and execution context.
  * Easily troubleshoot and find root cause of errors, misbehaviors or performance issues.
  
negative.code: == How to Get Started With Debug Mode
  
  . link:{{ '/apim/3.x/apim_publisherguide_design_studio_create.html' | relative_url }}[Design your API^].
  . Select *Debug* tab.
  . Configure your request.
  . Select *Send*.
  
  == How To Test Your API Concept with Debug Mode
  
  You can send a request to your *API* endpoint through the embedded HTTP client available under the *Debug* tab.
  
  NOTE: You don't need to save or redeploy the API to test your changes when using the Debug Mode.
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-example-empty.png %}[Debug Mode empty example]
  
  The embedded HTTP client, let's you can configure different attributes of your request:
  
  * *HTTP method* to select the HTTP verb (e.g., `GET`, `POST`, `PUT`, etc.).
  * *Path* to test a specific subpath and provide query parameters. 
  
  NOTE: The context-path of the API your are debugging is already taken into account. Path refers to the subpath: myapi-context-path/*path*?queryparam=value
  
  * *Headers* to provide a custom list of HTTP request headers.
  * *Request body* to configure a custom request body. 
  
  Since debug mode emulates an external call to your API, it will resolve the flow as the gateway would do, so if you want to debug a specific flow you must configure your request (path, headers) to replicate the conditions at which the flow is triggered.
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-example.png %}[Debug Mode example]
  
  The debug mode displays all policies in a vertical timeline so you can easily visualize the exact order of execution.
  
  === Different state for policies :
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-legend.png %}[Debug Mode legend]
  
  * *executed* - the policy has been executed properly
  * *skipped* - the policy is contains a condition that has been fulfilled. Refer to the information panel for more details on the evaluation of the condition.
  * *error* - an error occurred during policy execution. Refer to the information panel for more details on the error.
  
  By selecting a specific policy in the timeline, you have access to additional information regarding the input/output of the policy:
  
  * header
  * context attributes
  * body
  
  The inspector relies on 3 colors to indicate the nature of the change:
  
  * *green* color indicates a addition
  * *orange* color indicates a edition
  * *red* color indicates a deletion
  
  image:{% link images/apim/3.x/api-publisher-guide/design-studio/debug-mode/debug-mode-inspector.png %}[Debug Mode inspector]
  
  