Consider a scenario where a route has a parameter in it. Let’s take a look at an example:<id>/details Each individual rest run for this route will produce a new line in the metrics view: … This sort of reporting will quickly turn our dashboard into a disorganized mess. To produce a single endpoint for reporting from each one of these calls, you can use what we call a ‘footprint.’ How is this accomplished? In the test, you need to add a Config component to the I/O component as seen below: configFootprint The Config component has two fields: Name: the name you want to assign. In this case, you MUST to enter ‘footprint’ Value: The value for the configuration component. To set up a footprint, you must enter the same URL that’s in the I/O Component. Any parameterized portion of the URL must be wrapped in square brackets. Based upon our example, the value in this case would be:[id]/details In the project dashboard, after every run of the test instead of … you will find only one endpoint, displayed as:[id]/details For each endpoint you can use more square brackets, one for each variable that could assume multiple values. For example:[whatever]/[id]/details/[colors]/whatever When you write the value of the config, for the ‘static’ part of the endpoint you can also call a variable as in any I/O operation. Example: ${protocol}/${domain}/[whatever]/[id]/details/[colors]/whatever is valid syntax.